Bug#841294: Overrule maintainer of "global" to package a new upstream version
Package: tech-ctte Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, GNU Global is currently "freezed" in Debian at version 5.7.1 which is 8+ years old. Many improvements and bugs were fixed in more recent versions. Also, many frontends now expect a newer versions of global (new flags for the command-line tools) and therefore the version currently in Debian is difficult to use. Ron Lee is the current maintainer and disagrees on some issues with upstream and therefore don't want to update to a more recent version. See bug #574947: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947 The main issue seem to be around the CGI scripts. I believe that most users don't care about those. Upstreams is OK to not have the scripts packaged in Debian. There seems to be other issues but it is quite unclear what they are. Bug #816924 is about the same thing but Ron didn't participate at all: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924 I suppose that Ron may not accept to update the package even if the tech committee overrules him. In this case, Punit Agrawal accepts to take over the maintainance of the package and already produced some packages for newer versions. Those packages would remove the CGI scripts. Could the technical committee: 1. Mediate this issue with Ron to get him to accept package a newer upstream version. 2. If unsucessful, overrule Ron on the decision to package a new upstream version. 3. If Ron doesn't want to package himself a new upstream version, transfer the ownership of the package to Punit. I'll sponsor the uploads and assist him in this task. There are other possibilities like a different package "global6". However, it is unsure if Ron would accept to collaborate on this (notably with the alternative system): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166 "global6" could also conflict/replace global instead of using alternatives. However, it is unclear if global6 can be considered as replacing global. We don't know if Ron would agree to that. If he doesn't, another possibility for the technical committee would be to overrule him and allowing global6 to conflict/replace global. Thanks. - -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQIvBAEBCAAZBQJYB2qfEhxiZXJuYXRAZGViaWFuLm9yZwAKCRCVpC/oNTUl+QPX D/9qr7DxEERMZP5Pz1tKnf5KrW8Ko94edmvYXs5Iw7qamUUlX+M+4HSCW6K4toUr /R2SPRMmUgl85t88BgEfxCKo+j01ZIgcdCvvq3k4ZMmejXqvn/gl9YEkq7FmqS53 cBQJTUGERwHBkIBU3+gikUc77ORW+qVBg8+5gMY3lwWhQe8o+zBmRW2519AHWLVa Pcs+Xgk2ortnxFj+En4zz7fTooRoZDD1gvGhmmXEWaQ2wjbE2g4R6mMaDQ6JByBR QnF/AdwfDODrMD1wpW2EhpYSMwmDVCsPYneSpbNl2CMnVsA/CiPIiqpHuAkKq4cZ GgRhdGY+lCFzkXeI759gCY6gmMvsXLRyTBYSnUwHwRiSgHxyR9TlEaFPzG8k8wz7 b88XcKMrQek7uWVhlCoKm1bdaoiHFcGjwKc+cjTnGmKHVcpiXQuZI8mTv9B34nsJ 2LHcE9GxU3FOOkWmOLBtI4tkfJlmXxGdUzD/8a4kIZibpbIvC/qrCyaQQsp33/U1 UdXJOqsaB7ghGKlsHbw+ZGK8a9lqaxqtR3Tm+Wu/kB6/h+zZ9miRUfRrAygIMgJd aRKkNZ8FCC6VnkBdn2WKGoxrRo2ZohCNkZ0Ls7ed9RenwXU1eJvzvTrrWUpwyL1K wrSB5i0RRLkLQzUB/fmKbaPjU2OzuH4qsc1xLU9AqRfgcw== =lWow -END PGP SIGNATURE-
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Vincent Bernat writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > Ron Lee is the current maintainer and disagrees on some issues with > upstream and therefore don't want to update to a more recent > version. See bug #574947: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947 Looking at the bug logs, Ron has failed in the one non-delegatable, non-negotiable task for the Debian maintainer of a package: namely, to make appropriate decisions with respect to the package and then to communicate those decisions. Even if the decision to keep the new upstream version out of Debian is correct, Ron has failed to provide a coherent explanation. He has failed to engage with those who were willing and ready to do the work. I think the package would be best served by having a new maintainer. (Sadly I don't think the TC is likely to agree with me. Historically the TC has very very slow to act against maintainers who block other people's work and who do not communicate properly.) Anyway, good luck. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-10-19 14:26 +0100, Ian Jackson wrote: > Vincent Bernat writes ("Bug#841294: Overrule maintainer of "global" to > package a new upstream version"): > > Ron Lee is the current maintainer and disagrees on some issues with > > upstream and therefore don't want to update to a more recent > > version. See bug #574947: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947 > > Looking at the bug logs, Ron has failed in the one non-delegatable, > non-negotiable task for the Debian maintainer of a package: namely, to > make appropriate decisions with respect to the package and then to > communicate those decisions. > > Even if the decision to keep the new upstream version out of Debian is > correct, Ron has failed to provide a coherent explanation. He has > failed to engage with those who were willing and ready to do the work. > > I think the package would be best served by having a new maintainer. > > (Sadly I don't think the TC is likely to agree with me. Historically > the TC has very very slow to act against maintainers who block other > people's work and who do not communicate properly.) Indeed. The current situation is that the existing version is so old that it doesn't work properly with modern code any more, but the maintainer has refused to do any of: 1) upload a new package, 2) allow an upload which removes the offending CGI bit (which users don't really care about anyway) 3) write something to change the local behaviour to be satisfactory. Upstream has been clear that they are not going to change how it works, but they don't care if debian omits that bit or changes it locally, so it seems to me that a maintainer has to do one of the above three things. 5 years of this is more than long enough to conclude that they are not doing their job adequately, and because of our strong maintainership culture, are preventing other people from doing that job. It could just be NMUed, or a global6 uploaded so at least people would have something to work with, but asking the TC to rule seems like a more correct way to try and unbung this situation. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Wed, 19 Oct 2016 16:12:51 +0100, Wookey wrote: > Indeed. The current situation is that the existing version is so old > that it doesn't work properly with modern code any more, but the > maintainer has refused to do any of: > 1) upload a new package, I'm not "refusing to upload a new package", I'm asserting that trading one set of problems for a worse set of problems is not a solution to a problem. The crux of the problem is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131 And I don't think it's contentious to suggest that upstream's proposed 'solution' of using chmod 777 on a privileged directory is not something that's acceptable for a distro package. Shigio contacted me privately in 2010, proposing this mechanism as a replacement for the interface that he and I first worked out in 1999 to do this securely in a way that was suitable for packaged software, and I gave him a detailed review of that, explaining why that wasn't a suitable answer, and what we'd need to do one way or another to make it one. But he then simply ignored that (and later feigned ignorance that we'd even discussed it - despite his own upstream changelog acknowledging that we had), and made a series of incompatible changes to do this anyway. At around the same time, Taisuke Yamada had also expressed an interest in this and tried to reason with him about sane ways to do this, but his comments were similarly ignored as well. I'd persisted with trying to find a common understanding that we could base a real solution on, well past the point where the discussion had become circular and repetitive, before ultimately becoming resigned to the horrible stalemate which occurs when what you're arguing against has devolved to a stubborn insistence that "your suggestion is not simpler than chmod 777". Until the discussion can move beyond that to recognise the problem, our options were always going to be limited. > 2) allow an upload which removes the offending CGI bit (which users >don't really care about anyway) If it was actually true that "users don't care about it", then it shouldn't be a problem to get upstream to remove it. But obviously that hasn't happened (or we wouldn't be having this discussion), and when I last floated that option in one of the re-runs of this, upstream outright rejected it too: https://lists.debian.org/debian-project/2013/06/msg00174.html The only thing he was interested in getting rid of was the option to actually run this securely, with an audited system-wide script. Not the parts where his own documentation and code comments say things like "if you put this on the public internet, you lose", or the part where he expects the CGI script must be installed in the same tree as the rest of the generated page content. It is true (in my opinion) that doxygen now does a much better job of this than htags does, and that it would be no great loss (again to me) for htags to just be killed completely if it can't be made sane and safe. But I think it's a big stretch to claim that is some sort of universal consensus, and that if we removed it, then we wouldn't just end up right back here again with someone seeking to override the maintainer to put it back, because it is essential functionality to them, even if the people pleading here now don't care about it. htags is essentially useless without the CGI support, since that is how it accesses the global tags to provide search and indexing. You really would be far better off just using doxygen and its search facility that doesn't require a CGI. But someone cares about this, because doxygen itself got a patch to let it use htags instead of its own source browser ... (whether anyone actually uses that I'll leave as an exercise for someone to research and report back to us on). So if what you really want to do is kill htags completely, then that's a discussion I'm willing to listen to, but it's going to take some evidence of a genuinely stronger consensus than an off the cuff "I don't care if we do that" - since you haven't so far told us which bits you _do_ use and care about, so it's a bit arbitrary to declare you, or some subset of what global currently includes, more important than anyone else in a "rob peter to pay paul" decision scenario. > 3) write something to change the local behaviour to be satisfactory. I wrote something to do this in 1999. The fundamental problem is itself nearly old enough to drink in pubs. And I've maintained it for as long as doing that was possible - but upstream has now gratuitously broken the interfaces that we added back then (with his agreement and collaboration and blessing) which enabled this to be done in a sane and secure way - so the only alternative to nuking htags if upstream is actively hostile to that now is to fork completely from upstream ... which is essentially what has happened by sitting on the stable version we currently have. Yes, it sucks. But unless somebody else can convince Shigio
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 22 octobre 2016 14:44 +1030, Ron : > It seems fair to assume that you aren't seriously asking them to > endorse the idea of chmod 777 as an acceptable interface for > distro software - but that's what "force the new version into > the distro one way or another" actually means. Yes, I am not. > So are you asking if we should package a version that has htags > removed instead of what we currently have? Because that's the > essential implication of "remove the offending CGI bit". Yes. I have asked first here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#161 You politely said that you would rather not take this solution. > Or are you asking if we should somehow fix the incompatibility > with "many frontends", that nobody has explicitly detailed or > reported yet. Because that's a possibility too, though arguably > it's actually a bug in the "many frontends" and/or another fatal > flaw in the upstream maintenance of this software that it keeps > breaking compatibility by changing the meaning of existing options > and renaming them gratuitously. I am using ggtags (a frontend for Emacs). I tried to quickly show how many options were added: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171 Upstream doesn't break backward compatibility gratuitously, they are adding new options and frontends use them. You proposed to "fix" the frontend to be compatible with obsolete (upstream's word) versions. Not something that I can really find useful. > When all you ask me is "upload global6 or else", there's not much > I can usefully discuss except to repeat facts I've repeated many > times before that still haven't changed. If you can acknowledge > the problems with that, including the ones it would make for other > people which you don't personally care about, then we can try to > find some consensus on what a good way forward might be ... and > point to that the next time someone asks "what needs to be done > to fix this?". But that's hard to do when people are just tugging > hard in some direction solely on their own self interest. > > I want a good solution to this at least as much as anyone else does, > but the path of least resistance is what makes a river crooked, so if > we don't want this to end up as some sort of bug infested billabong > spreading disease to the people who use it, then we will need some > better answers than just "blindly package and upload a new upstream > version" - because the minimal work needed to do just that is not the > actual problem here. If you want to keep the CGI stuff, a solution would be to let somebody else create a global6 package (or yourself, as you prefer) and let this package break/conflict/replace with global. Use of alternatives could be a solution but this is quite more difficult as paths are not versioned. -- Keep it right when you make it faster. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sat, Oct 22, 2016 at 05:41:54PM +0200, Vincent Bernat wrote: > ❦ 22 octobre 2016 14:44 +1030, Ron : > > > It seems fair to assume that you aren't seriously asking them to > > endorse the idea of chmod 777 as an acceptable interface for > > distro software - but that's what "force the new version into > > the distro one way or another" actually means. > > Yes, I am not. > > > So are you asking if we should package a version that has htags > > removed instead of what we currently have? Because that's the > > essential implication of "remove the offending CGI bit". > > Yes. I have asked first here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#161 > > You politely said that you would rather not take this solution. Did you mean to point to some other message? Because what you asked there was actually: will you agree if someone packaged global6 without the CGI stuff and use of the alternative system to let people choose between global and global6 for gtags and other commands? Which is not at all the same as the question I asked above. I think we could pretty quickly get a consensus that creating a confusing mess with multiple versions and incompatible alternatives is not what the alternatives system was designed for, and about the worst possible option for how to ship something like global in Debian. If you're saying yes to the question I put above, then what I'm asking is: what real evidence can you show to back up your assertion that "nobody cares about htags", and/or what compelling case can you make that breaking things for anyone who does use it is a lesser evil than the problem(s) you are experiencing, and actually a necessary evil to fix your problem. Because one way or the other, _somebody's_ toys are going to be broken here in the absence of sanity from upstream. And if we're going to make a consensus decision here about whose toys that should be, then we need to be able to explain that to them in some better way than "Vincent said 'better you than me'". And preferably we also need to be able to explain to them what actions they could take to try to improve the situation in their favour again too. And that if they don't take them (or something materially similar) then the decision we make here will stand as the consensus for as long as these options remain in conflict. Otherwise we're just going to be back here again with someone asking the -ctte to override the maintainer to revert this change. > > Or are you asking if we should somehow fix the incompatibility > > with "many frontends", that nobody has explicitly detailed or > > reported yet. Because that's a possibility too, though arguably > > it's actually a bug in the "many frontends" and/or another fatal > > flaw in the upstream maintenance of this software that it keeps > > breaking compatibility by changing the meaning of existing options > > and renaming them gratuitously. > > I am using ggtags (a frontend for Emacs). I tried to quickly show how > many options were added: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171 A dump of --help showing different options does nothing to explain why ggtags is actually broken. And both you and Punit said you weren't interested in actually investigating that when I asked what the actual problem was. If ggtags is broken, that's a bug in ggtags. AFAICS, it's not even in Debian - and it's not hard to find random software on the internet that doesn't work with the versions of things in any particular Debian release. Lots of packaged software has patches to fix things like that. That might be a bug that's easier and better to fix with a trivial patch to global than it is to fix ggtags - but we don't know because you haven't told us what the bug you experienced is. And if that's your only problem then it might be a better solution overall than "break things for other people instead". > Upstream doesn't break backward compatibility gratuitously, Then I guess I must have imagined this conversation (quoted text is my queries about him doing exactly that in changes he approached me to review): From shi...@tamacom.com Mon Jul 26 09:55:44 2010 > As a side question to this, how will changing the current meaning of -S > affect existing users? At present it takes a parameter of the path to > the cgi-bin dir, won't changing this break things for people? Yes. But many incompatible changes have been done up to now. They are written clearly as '[INCOMPATIBLE CHANGES]' in NEWS files. From shi...@tamacom.com Mon Aug 02 10:55:03 2010 > Indeed there are times when such changes are unavoidable, but we should > always avoid them when we can. In this particular case I worry because > the -S option has been around for quite a while and is included in the > current stable releases of all distros that include global. Changing > its meaning without it obviously failing when the old meaning was intended > will surprise people who update the
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 23 octobre 2016 17:19 +1030, Ron : >> > So are you asking if we should package a version that has htags >> > removed instead of what we currently have? Because that's the >> > essential implication of "remove the offending CGI bit". >> >> Yes. I have asked first here: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#161 >> >> You politely said that you would rather not take this solution. > > Did you mean to point to some other message? Because what you > asked there was actually: > > will you agree if someone packaged global6 without the CGI stuff > and use of the alternative system to let people choose between > global and global6 for gtags and other commands? > > Which is not at all the same as the question I asked above. > I think we could pretty quickly get a consensus that creating a > confusing mess with multiple versions and incompatible alternatives > is not what the alternatives system was designed for, and about the > worst possible option for how to ship something like global in Debian. OK, so no alternative packaging. > If you're saying yes to the question I put above, then what I'm asking > is: what real evidence can you show to back up your assertion that > "nobody cares about htags", and/or what compelling case can you make > that breaking things for anyone who does use it is a lesser evil than > the problem(s) you are experiencing, and actually a necessary evil to > fix your problem. I don't have any evidence. > If ggtags is broken, that's a bug in ggtags. ggtags relies on contemporary versions of its dependencies. Not something that most people will call a bug. But I don't have evidence on this either. People in the bug report don't complain just to have a new shiny number in "global --version". They have actual problems with the version currently in Debian. > Without repeating what I already said above about this option, we do > already have some evidence about how well it might be implemented in > practice ... > > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176 > Punit (who you were proposing to take this over if the TC agreed with > you about that being the best option) said: > > While there doesn't seem to be any motivation to resolve the issues > blocking the package upgrade, I'd like to point you to a package > repository containing an upgrade to recent upstream release (6.2.12) - > > http://anonscm.debian.org/gitweb/?p=collab-maint/global.git. > > The package is also updated to follow more recent packaging standards. > > It would be ideal if the official package got upgraded (or maybe > replaced by another package), but in the meanwhile I'd like to keep > the above repo in-sync with upstream releases. Please let me know if > you face any issues using that version. > > > Anyone want to take a bet on guessing the last time that repo was > "in-sync with upstream releases"? [...] I don't think this is reasonable to expect someone to maintain a non-official repository of the package while still being ignored by the official maintainer. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#101 I asked Punit to resume his work only a few days ago. I can't expect him to have already do the work: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924#30 > So if that's what we're going to do, I'd like to see some sort of > evidence put on the record here by the people asserting "nobody uses > it" to show those assertions do have some real basis in fact that's > stronger than a thinly veiled "I don't use it". And some stronger > explanation for why we have no other practical choice to do that than > "I couldn't be bothered investigating bugs in other code that effect > me, it's easier to just break it for you instead". > > If we have that, and a good consensus on it, and nobody has any better > options we could opt for instead - then at least we have something to > point at as being a properly considered consensus decision, which I > don't have to worry about being dragged back here to defend because > somebody else doesn't like what problems your preferred option inflicts > upon them, if I arbitrarily pick you over them. > > > Until we can do that, all I can really do is what I've already been > doing, namely stick with the current status quo, and see what we can > do to address any specific individual problems that people care enough > about to report in some actually actionable way. So, nothing will move on your side until I bring some proof that "nobody is interested in htags". Well, I won't bring any such proof either. Your mail should show the TC you don't intend on bringing any solution other than the status quo. -- The lunatic, the lover, and the poet, Are of imagination all compact... -- Wm. Shakespeare, "A Midsummer Night's Dream" signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sun, Oct 23, 2016 at 09:55:43AM +0200, Vincent Bernat wrote: > ❦ 23 octobre 2016 17:19 +1030, Ron : > > If you're saying yes to the question I put above, then what I'm asking > > is: what real evidence can you show to back up your assertion that > > "nobody cares about htags", and/or what compelling case can you make > > that breaking things for anyone who does use it is a lesser evil than > > the problem(s) you are experiencing, and actually a necessary evil to > > fix your problem. > > I don't have any evidence. > > > If ggtags is broken, that's a bug in ggtags. > > ggtags relies on contemporary versions of its dependencies. Not > something that most people will call a bug. But I don't have evidence on > this either. People in the bug report don't complain just to have a new > shiny number in "global --version". They have actual problems with the > version currently in Debian. That actually effectively _is_ what you are saying if all you can say about this is "ggtags relies on a new shiny number" and not tell us anything at all about why. > > Without repeating what I already said above about this option, we do > > already have some evidence about how well it might be implemented in > > practice ... > > > > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176 > > Punit (who you were proposing to take this over if the TC agreed with > > you about that being the best option) said: > > > > While there doesn't seem to be any motivation to resolve the issues > > blocking the package upgrade, I'd like to point you to a package > > repository containing an upgrade to recent upstream release (6.2.12) - > > > > http://anonscm.debian.org/gitweb/?p=collab-maint/global.git. > > > > The package is also updated to follow more recent packaging standards. > > > > It would be ideal if the official package got upgraded (or maybe > > replaced by another package), but in the meanwhile I'd like to keep > > the above repo in-sync with upstream releases. Please let me know if > > you face any issues using that version. > > > > > > Anyone want to take a bet on guessing the last time that repo was > > "in-sync with upstream releases"? > [...] > > I don't think this is reasonable to expect someone to maintain a > non-official repository of the package while still being ignored by the > official maintainer. See: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#101 He wasn't ignored, he got an immediate explanation, which he said he didn't understand, and that was followed by more detailed explanations in the following days after he moved the private mail to discussion in the BTS. And I'm not expecting him to do anything. He said of his own volition a couple of months after that discussion that this is what he was going to do. And then just never did what he publicly volunteered to do. And it appears he doesn't even know what he did anymore, since he claims that he had already patched out the CGI code in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924#40 so either I'm missing something, or there's simply no evidence at all that he ever did that in the repository he published, and no evidence in the BTS that he actually understood what would be involved in doing so. All he ever said was "sure, I'll promise that if it gets what I want". Either way, it's quite clear that his interest in maintaining a version of global6 vanished nearly as quickly as it was professed. > > So if that's what we're going to do, I'd like to see some sort of > > evidence put on the record here by the people asserting "nobody uses > > it" to show those assertions do have some real basis in fact that's > > stronger than a thinly veiled "I don't use it". And some stronger > > explanation for why we have no other practical choice to do that than > > "I couldn't be bothered investigating bugs in other code that effect > > me, it's easier to just break it for you instead". > > > > If we have that, and a good consensus on it, and nobody has any better > > options we could opt for instead - then at least we have something to > > point at as being a properly considered consensus decision, which I > > don't have to worry about being dragged back here to defend because > > somebody else doesn't like what problems your preferred option inflicts > > upon them, if I arbitrarily pick you over them. > > > > > > Until we can do that, all I can really do is what I've already been > > doing, namely stick with the current status quo, and see what we can > > do to address any specific individual problems that people care enough > > about to report in some actually actionable way. > > So, nothing will move on your side until I bring some proof that "nobody > is interested in htags". Well, I won't bring any such proof either. That was a claim _you_ made in bringing this to the TC. Are you really saying now that you have no basis at all for making it? > Your mail should show the TC you don't intend on bringing any
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 23 octobre 2016 19:53 +1030, Ron : >> So, nothing will move on your side until I bring some proof that "nobody >> is interested in htags". Well, I won't bring any such proof either. > > That was a claim _you_ made in bringing this to the TC. Are you really > saying now that you have no basis at all for making it? There are several people (15 of them) in both bug reports asking for a new upstream release. None of them said they were using the CGI stuff. >> Your mail should show the TC you don't intend on bringing any solution >> other than the status quo. > > That isn't what I said at all. What I'm saying is that there is no way > we can avoid _some_ potential user not losing here, whatever we do. > That's just a plain and simple and awful fact of the situation. > > So if you don't want to be the one who loses from whatever consensus > we do arrive at as the best of a bunch of bad options, you're probably > going to need to present a slightly more compelling argument than > "I can't be bothered doing any work to help decide what's really best". > > Trying to play procedural games and hoping that luck might fall your > way because you threw the dice is really not very helpful for making > a good technical decision here. > > I'm appalled at the status quo. My concern is that we don't make > that even worse with uninformed decisions. In the absence of good > information, sometimes the best thing to do is be patient until > more of it arrives. But I'm happy to talk it out here and see if we > can arrive at some informed consensus, even if it's only so that we > can have some more independent and objective input to put an end to > the "ooh, that nasty maintainer won't do what I want" side of it. Let's see what the TC thinks. I don't have more arguments to bring to this debate. -- When one burns one's bridges, what a very nice fire it makes. -- Dylan Thomas signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
]] Ron > I'm appalled at the status quo. My concern is that we don't make > that even worse with uninformed decisions. In the absence of good > information, sometimes the best thing to do is be patient until > more of it arrives. I agree with this. On the other hand, waiting forever isn't productive either, which I think is where a lot of Vincent's frustration comes from, that it's hard to know when we've waited «long enough». I'm leaning towards dropping htags, since that seems to have problems security-wise (the idea of generated CGIs don't fill me with joy, at least, and hopefully not many others either), and also has a lot less value today than it used to back in the days. Maybe the question we should ask is less «who/how many people use htags?» and more «what value does htags provide?». I'm no big fan of arbitrarily breaking people's workflows, which we might be the result if we remove htags. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sun, Oct 23, 2016 at 08:48:53PM +0200, Tollef Fog Heen wrote: > ]] Ron > > > I'm appalled at the status quo. My concern is that we don't make > > that even worse with uninformed decisions. In the absence of good > > information, sometimes the best thing to do is be patient until > > more of it arrives. > > I agree with this. On the other hand, waiting forever isn't productive > either, which I think is where a lot of Vincent's frustration comes > from, that it's hard to know when we've waited «long enough». Indeed. As I said in the initial summary I posted, I can certainly sympathise with (and directly feel!) people's frustration with this, it's my frustration too. And my frustration with this is the same sort of problem the TC has with any decision that isn't a clear cut win-win - it doesn't really fix things to just move that frustration to a different group of users. It just restarts the debate with a different group of angry players feeling hard done by, sending you hate mail, and resorting to 'hostile' methods they hope might play out in their favour. So mostly for me, it had got to a point where I'd exhausted exploring and advocating for all the obviously possible good outs - and after that it wasn't so much a case of waiting 'long enough', but rather waiting until something material changed which tipped the balance or reopened the discussion with some new aspect to consider, which might make something else actually look better overall than the status quo did. ... and it may well be that this has actually happened now with upstream's decision to drop all support for providing a secure system CGI of any form that people can use for this. The upstream code is basically now back to what it was in the 90's, with the only way to use this being to allow execution of a generated CGI in the same tree as the html content. Which was already well known to be a dangerous and ill advised idiom even back then ... > I'm leaning towards dropping htags, since that seems to have problems > security-wise (the idea of generated CGIs don't fill me with joy, at > least, and hopefully not many others either), and also has a lot less > value today than it used to back in the days. That's the direction I'm tipping toward too. At the very least, this new change makes it even less desirable than it already was to ship the new upstream version 'as is', so in the absence of other workable suggestions, the salient question in my mind is basically boiling down into: Do we just give up on htags as being a viable thing at all, drop it, and just worry about whether the rest of what global provides is actually sane enough to still ship? Or do we keep the current version of htags for existing users, and patch the things people report they are having problems with in the other parts? The latter is mainly still an open question, because looking at the new options global's gtags has added, none of them seem to be particularly earth shattering innovations - though we still don't actually have any answer on what is broken about the external ggtags wrapper to know whether the new options are even related to that at all. So fixing that might not actually be all that hard if someone who cares about the external tools which I don't use wants to look at what is really broken about them, and might be the closest we get to actually giving both sides of that something resembling a fair compromise. I'd certainly be prepared to review and apply any sane patches to do that (and that's always been an open offer). But it would still leave us with the abstract math question of whether two half-sucks are greater or less than a whole. And I don't know offhand whether there are any other external tools we need to consider. Vincent claimed there were "many frontends" effected by this, but I don't know if that was a Rhetorical Many, or based on a numbering system that goes {0,Many,ManyMany,...}, or if he knows something else that he didn't detail - but nobody has yet mentioned any other "frontends" in reports to the BTS or to me. So if they actually exist, and do have problems, it would be good to know what they are so we can include them in any assessment of this too. > Maybe the question we should ask is less «who/how many people use > htags?» and more «what value does htags provide?». I'm no big fan of > arbitrarily breaking people's workflows, which we might be the result if > we remove htags. Yes, at the very least I think that's looking like the only metric which we can objectively weigh up and base any decision along these lines and its rationale upon. I don't think we can entirely discount existing users, but it's not looking like we're going to get any stronger basis for a head count argument (for either side of this) than we'd get from chicken entrails. If we can at least tell them something like "We're really sorry, but it's 2017, have you ever looked at doxygen? Here's a handy comparison." - that's a bit
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Tollef Fog Heen writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > [Ron:] > > I'm appalled at the status quo. My concern is that we don't make > > that even worse with uninformed decisions. In the absence of good > > information, sometimes the best thing to do is be patient until > > more of it arrives. > > I agree with this. On the other hand, waiting forever isn't productive > either, which I think is where a lot of Vincent's frustration comes > from, that it's hard to know when we've waited «long enough». Some years ago. > I'm leaning towards dropping htags, since that seems to have problems > security-wise (the idea of generated CGIs don't fill me with joy, at > least, and hopefully not many others either), and also has a lot less > value today than it used to back in the days. I don't think the TC should be stepping in to make these kind of decisions about the package. Rather, the TC should give the package to the people who want to do the work and are currently blocked. There is IMO no indication that the prospective new maintainers would do a bad job or that their strategy for dealing with this CGI problem (to wit, removing the feature) is inappropriate. The maintainer's comments about this are FUD. The level of demand for this feature would have to be very substantial for it to justify leaving this package at such an ancient version for years and years. Also, it is not right to reverse the burden of proof this way: the maintainer is suggesting that the feature could only be removed, to unblock a new upstream version, if it could somehow be proved that people don't need this feature. Well, we don't know how many people use this feature but we do know that the package right now is in bad shape. The maintainer here has only engaged on this issue because the TC has become involved, despite extensive efforts by several contributors to unblock things. IMO explanations now are too late. Furthermore, the TC should make a decision rapidly so that a fixed version of the package can be in stretch. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, Oct 24, 2016 at 03:11:15PM +0100, Ian Jackson wrote: > Tollef Fog Heen writes ("Bug#841294: Overrule maintainer of "global" to > package a new upstream version"): > > I'm leaning towards dropping htags, since that seems to have problems > > security-wise (the idea of generated CGIs don't fill me with joy, at > > least, and hopefully not many others either), and also has a lot less > > value today than it used to back in the days. > > I don't think the TC should be stepping in to make these kind of > decisions about the package. Rather, the TC should give the package > to the people who want to do the work and are currently blocked. Let me see if I've got this straight ... You're saying that the TC shouldn't "Make a decision when asked to do so", or "Offer advice" ... And that it should do that by making a decision to ignore the facts presented to it and instead summarily delegate that job to someone who promised to do the work 2 years ago but hasn't, and someone who has said quite plainly here that they aren't interested in doing any work at all to understand the facts or detail their actual problems to us accurately? You should do irony for a living. This is pure gold. > There is IMO no indication that the prospective new maintainers would > do a bad job or that their strategy for dealing with this CGI problem > (to wit, removing the feature) is inappropriate. The maintainer's > comments about this are FUD. The level of demand for this feature > would have to be very substantial for it to justify leaving this > package at such an ancient version for years and years. How is that any different from saying the level of demand for the (still unspecified) new features that are needed to support something which apparently has so little interest that it's not even packaged for Debian would have to be "very substantial for it to justify breaking an existing feature that we've distributed and supported for 17 years"? This is a platitude you could have pulled from a fortune cookie. Not an argument with any technical basis or insight or merit. And not the kind of hollow nonsense we should apply in either direction for making a decision about the best thing to do with this. > Also, it is not right to reverse the burden of proof this way: the > maintainer is suggesting that the feature could only be removed, to > unblock a new upstream version, if it could somehow be proved that > people don't need this feature. Well, we don't know how many people > use this feature Upstream asserts this is an important feature and that they will not remove it. It's supported by doxygen. It was the outstanding feature of this package in 1999 which got it packaged for Debian in the first place. So tell us again who is trying to "reverse the burden of proof" here? I'll put a dollar down that says you don't even know what the features of this software package were at all before you wrote that. > but we do know that the package right now is in bad shape. And we know that each new upstream release for the last few years appears to put it in even worse shape in some respects. You don't get out of a bad situation by pretending you aren't stuck deep in the middle of one. > The maintainer here has only engaged on this issue because the TC has > become involved, despite extensive efforts by several contributors to > unblock things. IMO explanations now are too late. "extensive efforts". Is that what the cool kids call complaining without even explaining or investigating what you are complaining about these days? I made the effort to detail the situation here in as much detail as possible precisely so that people who are tasked by the project to provide independent technical guidance can help us arrive at a thoughtful consensus that's a bit broader than just me having to repeatedly explain why things are like they are to people who don't actually care as long as they get what they want, without having to put any real effort or thought in, and without any regard to the effect that might have on other users. And so that if or when what we decide does upset someone else (which is almost guaranteed as an outcome one way or another), we can point those people to a considered consensus instead of having them level ridiculous accusations at me, and appealing again to the TC to override that decision too. If we're going to do this here, we should do it once, and do it right. It's never "too late" to want good decisions. > Furthermore, the TC should make a decision rapidly so that a fixed > version of the package can be in stretch. So that if we do make a terrible mistake nobody will have time to notice or get it fixed before
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sun, 23 Oct 2016, Tollef Fog Heen wrote: > Maybe the question we should ask is less «who/how many people use > htags?» and more «what value does htags provide?». I'm no big fan of > arbitrarily breaking people's workflows, which we might be the result > if we remove htags. It sure looks like upstream has removed the CGI generation option from ctags itself, and no longer supports the --system-cgi option. Htags appear to now just be generated statically, with the possibility of a generated CGI as well [which seems to just set appropriate paths.] It's quite possible that I've totally missed something (the upstream manual is a bit impenetrable), but maybe this will obviate the need to answer this question? [Also, I'd like to note that currently Punit has not participated in the CTTE bug, and the last comment on #574947 was in 2014, so I'm not convinced that we have an alternative maintainer even if we were to decide to change ownership of this package.] -- Don Armstrong https://www.donarmstrong.com If everything seems to be going well, you have obviously overlooked something. -- Steven Wright
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 24 octobre 2016 12:48 -0500, Don Armstrong : > [Also, I'd like to note that currently Punit has not participated in > the CTTE bug, and the last comment on #574947 was in 2014, so I'm not > convinced that we have an alternative maintainer even if we were to > decide to change ownership of this package.] There is also #816924. As for #574947, Ron stopped any participation. I don't see what should be expected from other participants. Two of them proposed an updated packaging, one of them proposed to help as a co-maintainer, none of them got any attention. -- It has long been an axiom of mine that the little things are infinitely the most important. -- Sir Arthur Conan Doyle, "A Case of Identity" signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, 24 Oct 2016, Vincent Bernat wrote: > ❦ 24 octobre 2016 12:48 -0500, Don Armstrong : > > > [Also, I'd like to note that currently Punit has not participated in > > the CTTE bug, and the last comment on #574947 was in 2014, so I'm not > > convinced that we have an alternative maintainer even if we were to > > decide to change ownership of this package.] > > There is also #816924. As for #574947, Ron stopped any participation. > I don't see what should be expected from other participants. Two of them > proposed an updated packaging, one of them proposed to help as a > co-maintainer, none of them got any attention. Ah, excellent; I missed #816924. I withdraw this criticism. -- Don Armstrong https://www.donarmstrong.com I'm sorry about those late night emails. I only said those things because I was too drunk to be afraid. -- a softer world #579 http://www.asofterworld.com/index.php?id=579
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, Oct 24, 2016 at 12:48:10PM -0500, Don Armstrong wrote: > On Sun, 23 Oct 2016, Tollef Fog Heen wrote: > > Maybe the question we should ask is less «who/how many people use > > htags?» and more «what value does htags provide?». I'm no big fan of > > arbitrarily breaking people's workflows, which we might be the result > > if we remove htags. > > It sure looks like upstream has removed the CGI generation option from > ctags itself, and no longer supports the --system-cgi option. Htags > appear to now just be generated statically, with the possibility of a > generated CGI as well [which seems to just set appropriate paths.] > > It's quite possible that I've totally missed something (the upstream > manual is a bit impenetrable), but maybe this will obviate the need to > answer this question? Only half-missed :) That removes any trace of the ability to generate a _static_ CGI that can be audited and installed to a system path. Which basically takes us back to the original situation from the 90's again, where the CGI is generated dynamically for each source repo, and is expected to be allowed to execute from the same tree as the static html content. It is possible to generate html that doesn't use a CGI at all, but that completely removes the ability to search the gtags database (which is what the CGI is needed to do) - which makes htags fairly useless, since the whole point of global is the tag search function, and you really would be far better off using something like doxygen instead which provides client side search functionality. The evolution was basically: - 1999 I added the ability to generate static CGI and use it securely. It was then suitable for use as a distro package, and uploaded to Debian. Upstream was sensitive about accepting major contributions that might mean he couldn't relicence it without permission from other authors, so he wanted the major parts of that kept separate, and we added only the hooks needed to support it to the main body of his code. (at some point after that he did change the licence from BSD to GPL). - 2010 Upstream proposed replacing that with a mechanism that was part of the 'upstream' code, and approached me privately to review his proposed changes. This was the "run a generated script as root and/or chmod 777 the privileged directory" option. He then wasn't interested in anything but a rubberstamp acceptance of that, and I couldn't convince him why that would be Troublesome. At that point he also deliberately removed the old interfaces that were necessary to support what we had, and the stalemate began. - At some point more recently, he broke that mechanism too, then dropped it completely (which is the change you were looking at). So now we're back to the pre-1999 option of only having it generated dynamically, hardcoded to be in the same tree as the static html. Which was already a fairly strongly condemned practice in the 90's. So basically, you've now got a choice of "Something worse than doxygen with no search functionality", or something that's a PITA to make work at best (you need to let your web server execute CGIs from arbitrary paths), and a security hole waiting for people to walk through at worst, and potentially still worse than what you'd get from doxygen anyway. I haven't audited the most recent code in detail yet, but the older code and docs used to be full of warnings along the lines of "if you put this on the public internet, you lose. Don't do that.". Which doesn't seem like something we really want in a distro package. That's basically why "just nuke htags now" is starting to look like a viable, and even sensible, option. But it's tricky to know who might be upset by that - and we don't have a clear idea of exactly what we'd really gain elsewhere from that tradeoff, since most of the people saying "I need a new upstream" haven't actually been telling us what the real problem is which that fixes, even when I asked. It's quite possible that some of those would just need a trivial patch to what we currently have - but with these latest changes to htags, I am feeling more and more like the writing is on the wall for its ultimate demise now - even if upstream isn't accepting that yet. But I haven't forgotten the hatemail I got for finally killing off svgatextmode, a whole decade after its upstream declared it an obsolete solution, when kms finally made it impossible to keep it working - so I don't underestimate what some people might cling to. Cheers, Ron
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, 25 Oct 2016 05:47:27 +1030 Ron wrote: [...] > That's basically why "just nuke htags now" is starting to look like > a viable, and even sensible, option. But it's tricky to know who > might be upset by that - and we don't have a clear idea of exactly > what we'd really gain elsewhere from that tradeoff, since most of > the people saying "I need a new upstream" haven't actually been > telling us what the real problem is which that fixes, even when I > asked. Gtags in Debian doesn't work with modern code base. Last time I tried (several years ago), it segfault'ed while trying to index Linux kernel. Here is my two cents on the issue of whether Debian should update global to a newer version and nuke htags: While I can't provide concrete numbers on how many people care or don't care about htags, there are some proxies that can help with this: 1. Most if not all the bug reporters for global package don't use htags. 2. Other distros' maintainers / users don't seem to care about htags or its implications. 3. The Debian users of global, according to popcon, is declining, which means less and less people care about current package (hence htags, for that matter). The core functionality of global is code indexing. As it stands, the current version is buggy and chokes on modern code base. The usability of the current package is only going to be less and less. No matter how secured the current package is, Debian users won't be able to use it because it can't generate index files in the first place. Eventually no-one will use this package. All in all, I think it is a disservice to Debian users to keep the status quo. I believe you've exhausted all venues to communicate with upstream your concern about CGI scripts. It is unfortunate that no progress was made in the last 8+ years. Under such circumstance, sacrificing a non-core functionality (htags) to serve the greater good seems to be a good trade-off to me. Wei.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
So in summary, the maintainer has: * Not packaged the new upstream version due to concerns about a feature which is not present in the current Debian version and which could therefore be removed from a new-upstream-version upload without causing a regression in Debian; * Explicitly and repeatedly blocked other people who wanted to do the work to upload the new version (possibly with the troublesome feature removed); * Failed to engage positively with all of the many people who have enquired about the question; * Specifically, failed to give clear and constructive directions to those willing to do the work; The above have been carrying on for many many years. There has been no upload for six years. Most recently: * The maintainer has completely ignored a bug filed in March where sseveral people request an update and where it is obvious that no-one really understands the problem. It is not necessary to decide whether the CGI feature should be disabled, or should ideally be fixed. It is in fact not necessary to make any difficult technical analyses to conclude that the maintainer has made a massive net negative contribution to this package. They have done this solely by virtue of their position as the Debian maintainer. The maintainer has abused the maintainer's gatekeeper role. There are people ready and willing to do the work, who are currently blocked. Giving this package to a new maintainer is a no-brainer. If the TC will not depose a maintainer in circumstances like these, what will it take ? Please do not come to a "negotiated settlement" which leaves the current maintainer in charge. The effect of that is that all the constructive and useful people will be subject to the arbitrary whims of the the current maintainer. If the TC's decision, in such a clear case of abuse of power, is to leave the problem maintainer in charge, that is a decision to allow that person to continue to block people if they feel like it. With the TC's current attitude, it takes desperation (as well as determination and courage) to take a matter like this to the TC. If you have anything left to lose, taking this kind of dispute to the TC is a very risky step: the TC is not likely to get rid of a despot, and despots do not react well to challenges to their authority. So the petitioner (who probably cares about the package) is still under the maintainer's thumb, but they have annoyed the maintainer. Please would the TC prove me wrong. (For a change.) Ian. (quite frustrated) -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
]] Wei Liu > On Tue, 25 Oct 2016 05:47:27 +1030 Ron wrote: > [...] > > That's basically why "just nuke htags now" is starting to look like > > a viable, and even sensible, option. But it's tricky to know who > > might be upset by that - and we don't have a clear idea of exactly > > what we'd really gain elsewhere from that tradeoff, since most of > > the people saying "I need a new upstream" haven't actually been > > telling us what the real problem is which that fixes, even when I > > asked. > > Gtags in Debian doesn't work with modern code base. Last time I tried (several > years ago), it segfault'ed while trying to index Linux kernel. FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and last time I used it, it also worked fine with the emacs integration, so I don't recognise the crying from the rooftops about it being broken in Debian. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#841294: Overrule maintainer of "global" to package a new upstream version
]] Ian Jackson > So in summary, the maintainer has: > > * Not packaged the new upstream version due to concerns about a >feature which is not present in the current Debian version and >which could therefore be removed from a new-upstream-version upload >without causing a regression in Debian; htags is in the version in Debian. > * Failed to engage positively with all of the many people who have >enquired about the question; > > * Specifically, failed to give clear and constructive directions to >those willing to do the work; I disagree with those characterisations. He's asked for clarifications on what is broken without anything resembling an adequate reply. I'm not going to comment further on your personal attacks against the maintainer. I think you're behaving below yourself and that you should stop. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 25 octobre 2016 07:33 +0200, Tollef Fog Heen : >> * Specifically, failed to give clear and constructive directions to >>those willing to do the work; > > I disagree with those characterisations. He's asked for clarifications > on what is broken without anything resembling an adequate reply. Sorry? When did that happen? Do you refer to (IMO, the single occurrence where some clarifications were asked): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166 I replied: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171 I now understand that the answer was not enough, but this is new information. As of 2014, there was no answer to this message. The whole bug report is about people trying to understand and give information and the maintainer not giving a damn. People saying that gtags don't work at all for them didn't get any reply: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#34 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#190 If you refer to what Ron is asking in #841294, this is far too late. I won't help to debug a 8+ years version of a software while the newest version works just fine for me. Would you? It is not like this version is somewhat maintained (as if it was a fork). The latest upload was in 2010. -- Make your program read from top to bottom. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sun, Oct 23, 2016 at 7:49 AM, Ron wrote: > On Sat, Oct 22, 2016 at 05:41:54PM +0200, Vincent Bernat wrote: >> ❦ 22 octobre 2016 14:44 +1030, Ron : >> [...] > > Without repeating what I already said above about this option, we do > already have some evidence about how well it might be implemented in > practice ... > > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176 > Punit (who you were proposing to take this over if the TC agreed with > you about that being the best option) said: > > While there doesn't seem to be any motivation to resolve the issues > blocking the package upgrade, I'd like to point you to a package > repository containing an upgrade to recent upstream release (6.2.12) - > > http://anonscm.debian.org/gitweb/?p=collab-maint/global.git. > > The package is also updated to follow more recent packaging standards. > > It would be ideal if the official package got upgraded (or maybe > replaced by another package), but in the meanwhile I'd like to keep > the above repo in-sync with upstream releases. Please let me know if > you face any issues using that version. > > > Anyone want to take a bet on guessing the last time that repo was > "in-sync with upstream releases"? > > If you guessed "about a week before that email was sent ...", then > yeah, you win the "I've seen this before too" booby prize. > > It's now something like 12 releases and more than 2 years behind > being "in-sync with upstream", and hasn't been touched again at all > since then ... Seeing that I wasn't getting a clear response on what the problem blocking the upgrade is and how to resolve it, I didn't spend any effort on the repository. As I don't use htags (or the related cgi-bin functionality) I was looking for guidance on what is needed to fix/resolve the issue with newer upstream releases. The reason I wanted to see the package upgraded was because the existing version didn't work for me on the linux kernel source tree (while upstream does). Forgive me for not being either a debian or a source code tagging software expert. If only you'd engaged with the commentators of #574947 and #816924, we wouldn't be here trying to point fingers.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Ron writes: ... > That's basically why "just nuke htags now" is starting to look like > a viable, and even sensible, option. But it's tricky to know who > might be upset by that - and we don't have a clear idea of exactly > what we'd really gain elsewhere from that tradeoff, since most of > the people saying "I need a new upstream" haven't actually been > telling us what the real problem is which that fixes, even when I > asked. This sounds like, if you were given enough feedback, you'd be willing to fork this to keep the old functionality available, while servicing the needs of users of new features -- is that right? If that is the case, and having read the rest of what you've written, it seems that the clamour for upgrading to the latest release is a symptom of not paying sufficient attention to the messy details. > It's quite possible that some of those would just need a trivial > patch to what we currently have - but with these latest changes to > htags, I am feeling more and more like the writing is on the wall > for its ultimate demise now - even if upstream isn't accepting > that yet. > > > But I haven't forgotten the hatemail I got for finally killing off > svgatextmode, a whole decade after its upstream declared it an > obsolete solution, when kms finally made it impossible to keep it > working - so I don't underestimate what some people might cling to. How viable is it to have two conflicting packages: global5: continuing as you have it now (perhaps with patches to make it work for recent use cases) global6: (with htags support removed) If you did that, and especially if you changed a config file to include a note that the global5 package might go away in the next release (so that most people will see that on upgrade) then you could provoke the feedback you want, and perhaps also make judgements based on the way popcon figures shift over time. Would that work for you? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Philip Hands writes: ... > How viable is it to have two conflicting packages: > > global5: continuing as you have it now >(perhaps with patches to make it work for recent use cases) > > global6: (with htags support removed) Ah, I see -- I had somehow got the impression that the first was already called global5 from comments in the thread. Given that it's actually called 'global' I guess that adds an extra wrinkle. Depending upon your preference I would expect that you select one or other version to be the inheritor of the global name. It seems like you are tempted to drop htags anyway now, so calling the version 6 package 'global' and adding the global5 package to give people an escape route seems like the right thing to do. That also makes it much easier to detect when people cling to version 5, since there will only be intentional installations of that package. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, Oct 25, 2016 at 6:29 AM, Tollef Fog Heen wrote: > ]] Wei Liu > >> On Tue, 25 Oct 2016 05:47:27 +1030 Ron wrote: >> [...] >> > That's basically why "just nuke htags now" is starting to look like >> > a viable, and even sensible, option. But it's tricky to know who >> > might be upset by that - and we don't have a clear idea of exactly >> > what we'd really gain elsewhere from that tradeoff, since most of >> > the people saying "I need a new upstream" haven't actually been >> > telling us what the real problem is which that fixes, even when I >> > asked. >> >> Gtags in Debian doesn't work with modern code base. Last time I tried >> (several >> years ago), it segfault'ed while trying to index Linux kernel. > > FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and > last time I used it, it also worked fine with the emacs integration, so > I don't recognise the crying from the rooftops about it being broken in > Debian. > Sure, if it works for you. That's great. I couldn't go back in time to extract a backtrace or coredump. It could be that I was so unlucky that at the time my computer was constantly hit by cosmic rays that it just couldn't cope with that version of global. I installed a new version of global since then and never looked back. But at some point I decided I cared enough to check the situation of global in Debian again. I scraped all information I could find and that led to #816924 (which is the reason I know about this CTTE bug, BTW). It is entirely possible that all reporters who said global didn't work were all out-liners. It is entirely possible that there are hundreds (based on popcon data) of satisfying Debian global users in the wild. They just don't speak up because there is nothing to report. I can only reason from first principle: there is a reason why a new release is made. Either there are new shiny features, or there are bugs to fix, most likely to be both. I don't believe the current Debian global is free of bugs, and I believe it would serve Debian best if we move on from this ancient version. If some sort of objective metric is needed, I suggest we wait until popcon number drops to zero, however long it takes. I'm absolutely fine with that. :-) Wei. > -- > Tollef Fog Heen > UNIX is user friendly, it's just picky about who its friends are
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, Oct 25, 2016 at 09:03:40AM +0200, Philip Hands wrote: > Ron writes: > > ... > > That's basically why "just nuke htags now" is starting to look like > > a viable, and even sensible, option. But it's tricky to know who > > might be upset by that - and we don't have a clear idea of exactly > > what we'd really gain elsewhere from that tradeoff, since most of > > the people saying "I need a new upstream" haven't actually been > > telling us what the real problem is which that fixes, even when I > > asked. > > This sounds like, if you were given enough feedback, you'd be willing to > fork this to keep the old functionality available, while servicing the > needs of users of new features -- is that right? I definitely think that's an option we'd be silly to take off the table before we had enough information to determine that it wasn't a very practical choice from here on out. I'd already forked it (with upstream's blessing that this was how we should do it) to add the extra functionality that was needed before the very first upload of it in 1999 - and have been maintaining that fork ever since. The only thing that changed was upstream made it impossible to just pull all of their new changes in verbatim without breaking what we already had. But my hope had always been that eventually user demand communicated to upstream would lead us to find some common ground on that again, one way or another, and we'd get past that stalemate. For anything I maintain, I'm always willing to carry and/or write sensible patches that fix real problems people are having. In this case, it potentially really wouldn't be any different to carrying backported patches from an 'unstable' upstream branch to a stable release package - which isn't exactly an uncommon practice. I do that all the time with software I'm upstream for, and the distro is full of packages doing exactly that. That certainly seemed like an easy option for Vincent's ggtags problem. The new options added to gtags seem mostly pretty trivial, but I never got (and still don't have) a clear answer about whether that is actually the problem with it or not, and if so, what extra options it actually needs. For all I know at this stage, the incompatibility is related to something else entirely. Maybe the output formatting changed or some thing like that. I don't know if it's "completely" broken, or if some minor feature of it just has a glitch. When he said he wasn't interested in investigating it, there didn't seem to be much point hounding him to do that. If it really was a widely used front end, someone else would eventually come along who was interested in digging a bit deeper to fix it. Historically, that's how this sort of thing usually works. > If that is the case, and having read the rest of what you've written, it > seems that the clamour for upgrading to the latest release is a symptom > of not paying sufficient attention to the messy details. Yes, there is an element here of what a friend of mine often complains about with getting her IT staff to fix problems. All they ever say is "we're waiting for a new upstream release". Which isn't to say I'm convinced yet that this is the right option for us to go with from here - but I think if we're going to weigh up the pros and cons of each, knowing there is no one clear right choice that is certain to make everyone happy, then it's one that we shouldn't rule out before we know if there is some real showstopper that makes it look obviously worse than the other alternatives. Either way, it *is* a thing we could do Right Now, without having to wait on coming to some consensus about what the long term future ought to be. Fixing things that don't break anything else is about the only no brainer that we do have here. > > It's quite possible that some of those would just need a trivial > > patch to what we currently have - but with these latest changes to > > htags, I am feeling more and more like the writing is on the wall > > for its ultimate demise now - even if upstream isn't accepting > > that yet. > > > > > > But I haven't forgotten the hatemail I got for finally killing off > > svgatextmode, a whole decade after its upstream declared it an > > obsolete solution, when kms finally made it impossible to keep it > > working - so I don't underestimate what some people might cling to. > > How viable is it to have two conflicting packages: > > global5: continuing as you have it now >(perhaps with patches to make it work for recent use cases) > > global6: (with htags support removed) > > If you did that, and especially if you changed a config file to include > a note that the global5 package might go away in the next release (so > that most people will see that on upgrade) then you could provoke > the feedback you want, and perhaps also make judgements based on the way > popcon figures shift over time. My hunch is that this would be about as wildly successful as trying to hedge
Bug#841294: Overrule maintainer of "global" to package a new upstream version
> Philip Hands writes: > It seems like you are tempted to drop htags anyway now, so calling the > version 6 package 'global' and adding the global5 package to give people > an escape route seems like the right thing to do. > > That also makes it much easier to detect when people cling to version 5, > since there will only be intentional installations of that package. I second this proposal by Phil. It seems to me that this is the most reasonable outcome, given the current situation. This means that global gets updated to the latest version, with a NEWS message stating that htags functionality has been removed and that users that care about htags should install global5 instead. Ron, you haven't replied to this proposal yet. Can you state your opinion regarding this? Thanks! -- Regards, Marga
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Hi Marga, On Tue, Nov 01, 2016 at 11:32:49AM +0100, Margarita Manterola wrote: > > Philip Hands writes: > > It seems like you are tempted to drop htags anyway now, so calling the > > version 6 package 'global' and adding the global5 package to give people > > an escape route seems like the right thing to do. > > > > That also makes it much easier to detect when people cling to version 5, > > since there will only be intentional installations of that package. > > I second this proposal by Phil. It seems to me that this is the most > reasonable > outcome, given the current situation. This means that global gets updated to > the > latest version, with a NEWS message stating that htags functionality has been > removed and that users that care about htags should install global5 instead. > > Ron, you haven't replied to this proposal yet. Can you state your opinion > regarding this? Did I mess up on the CC for that somehow? Or was there something I didn't address about the question(s) of going this way in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#135 I can try to clarify that if there's a question in your mind that you don't think I touched on there. Cheers, Ron
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Ron writes: > Hi Marga, > > On Tue, Nov 01, 2016 at 11:32:49AM +0100, Margarita Manterola wrote: >> > Philip Hands writes: >> > It seems like you are tempted to drop htags anyway now, so calling the >> > version 6 package 'global' and adding the global5 package to give people >> > an escape route seems like the right thing to do. >> > >> > That also makes it much easier to detect when people cling to version 5, >> > since there will only be intentional installations of that package. >> >> I second this proposal by Phil. It seems to me that this is the most >> reasonable >> outcome, given the current situation. This means that global gets updated to >> the >> latest version, with a NEWS message stating that htags functionality has been >> removed and that users that care about htags should install global5 instead. >> >> Ron, you haven't replied to this proposal yet. Can you state your opinion >> regarding this? > > Did I mess up on the CC for that somehow? Or was there something I > didn't address about the question(s) of going this way in: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#135 > > I can try to clarify that if there's a question in your mind that > you don't think I touched on there. The question that remains is what you actually intend to do. You went into some detail about why the existing popcon figures should not be relied upon, which is fair enough but seems not to take account of the fact that my suggestion was for you to create a new global5 package which would not be automatically pulled in by anything (unless the maintainers of reverse dependencies decide that it's better to switch to depending upon global5, which should probably be strongly discouraged). The popcon figures for global would then still be contaminated with whatever dragged it in in the first place, but the figures for global5 would tell you the extent to which the userbase of the global5-only features actually exists. Either there are real users for those features, which might persuade you that the effort of backporting features to global5 is justified -- in that case the exit strategy would be for the patched global5 to be the final inheritor of the 'global' package (in stretch+1 say, replacing the v6 package once you have the relevant feature parity). Alternatively, if very few people install global5, you can publish an update that reminds people that the package is going away, and asking them to tell you why they might be upset about that, and then you either get useful feedback, or you can remove the package with a clear conscience. I would think that this is a strategy that would allow you to act. Perhaps you can explain why you apparently think doing nothing indefinitely is better for our users. I am aware that there are subtleties here that I may have missed, so please don't assume that I'm intentionally ignoring what you think of as the obvious flaws with this idea. I really don't mind being treated as an ignoramus. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote: > Ron writes: > > > > I can try to clarify that if there's a question in your mind that > > you don't think I touched on there. > > The question that remains is what you actually intend to do. Nod. So far here, I've mostly tried to stick to just outlining the facts we have to deal with, and the options I think we have and the pros and cons of them - because I don't have a preconceived answer to that which I'm welded to, and I was more interesting in listening to well considered comments that people might have had than turning this into a mindless tug of war between two inflexible positions. There's some things I think it's obvious that we shouldn't do, and some things I think we shouldn't do which might not have such a clear consensus - but that's not enough on its own to make it clear what we _should_ do, and I agree with you that if the fresh input we are getting here is tailing off, then it's probably on my head to make a suggestion now that we can consider the merits of. I have been chewing over how various options might pan out, to try and decide what I think looks the Least Bad overall, for both the immediate gratification people and in the long term. But I wanted to give everyone who wanted it a chance to weigh in with their own ideas, and I wanted to have a good look at what had actually changed on the ground with the latest upstream changes - without having that get short-circuited by people who didn't want to put in any work to look in detail crying "your idea sucks, I demand satisfaction" again. I can sympathise with their pain, but it's a poor train of logic to base any sort of hard decision on. > You went into some detail about why the existing popcon figures should > not be relied upon, which is fair enough but seems not to take account > of the fact that my suggestion was for you to create a new global5 > package which would not be automatically pulled in by anything (unless > the maintainers of reverse dependencies decide that it's better to > switch to depending upon global5, which should probably be > strongly discouraged). Sorry if I confused those two things there. The issues with what we can extrapolate from existing popcon numbers wasn't really related to your suggestion at all. But it seemed like something that needed a bit of light shone on it, since a few people had made arguments based on "because popcon". You didn't do that, but at least one of the comments after yours did it again. I probably should have kept that more clearly separate. > The popcon figures for global would then still be contaminated with > whatever dragged it in in the first place, but the figures for global5 > would tell you the extent to which the userbase of the global5-only > features actually exists. Yeah, I did see the logic you were working through there, but I thought the other reasons for why 'solving' this by just turning it into two conflicting packages, both with a tiny number of users, would be strong enough to stand on their own without a detailed analysis of what that part might (or might not) usefully add for us. > Either there are real users for those features, which might persuade you > that the effort of backporting features to global5 is justified -- in > that case the exit strategy would be for the patched global5 to be the > final inheritor of the 'global' package (in stretch+1 say, So to answer that part more directly, I think the big problem with just this part of it, is that popcon is a fairly strongly lagging indicator (which the 'spike' fairly clearly does show, it took ~3 years to peak, and even longer than that to subside again) - so to use it as a 'nail in the coffin' metric, really we'd be looking at more like stretch+2 or even (much) later - which realistically, becomes a fair approximation for "we will never make a decision based on this", even if we discount guessing what proportion of people using this also use popcon on the machines they use it on, to decide if it's a relevant metric at all. I think in that sort of time frame, the probability of something else substantive changing, which would make this even less certain or less useful, is comparatively high. Basically, we'd be resigning ourselves to saying "this will be a mess forever", and an even bigger mess in Debian. Which is why that's not my first preference here. The value of Debian is in making the messy outer world less messy where possible. Not in making it a dumping ground for the spoils of indecision about how to deal with that. > replacing the v6 package once you have the relevant feature parity). To do that still needs the people affected to actually tell us what the 'relevant' features they want parity with are. And if they did that, we could have solved that part of it 'overnight' at any time in the last or next few years. Until someone complaining about that puts their hand up to do even the minimal work to explain e
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Note: this is written as an outsider who doesn't have any direct stake in the issue. On Sun, 6 Nov 2016 05:00:12 +1030 Ron wrote: > > And I think the latter is basically what the "just ship multiple > versions and hope the future gets clearer" option boils down to. > All it really does is take the pressure off of everyone but me > to have any interest at all in actually trying to resolve the > genuinely Hard part of this. And it does that by making an even I don't think the others have any obligation to try to resolve any technical issues, and it is 100% reasonable of them to insist that Debian just ship a new upstream version (as long as the packaging is not otherwise unacceptably bad; but simply disabling any functionality that is not secure or otherwise OK upstream is a valid answer). Based on what I've seen in this thread, I think I can say you're clearly in the wrong. And that does not require considering any of the technical issues with the software. The software now shipped in Debian as "global" is simply too outdated compared to upstream. That you have technical objections to something in the newer versions could be a reason for you to create a new fork. But you have not properly done that, and abusing your Debian packager position to indefinitely hold back the package is not an appropriate answer to any technical issues, regardless of the validity of the technical objections. To properly create a fork, you'd need to either pick a new name for your fork, or contest whose version has the right to the name "GLOBAL". You have obviously not chosen a new name. You don't seem to be claiming to be the overall upstream maintainer of GLOBAL either, and claiming that would be totally inappropriate if you're only shipping your version in Debian. As such, you have no business shipping your version under the "global" package name. Either ship the upstream version - even if flawed and causing problems for some users - or use another package name.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Nov 06 2016, Ron wrote: > On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote: >> Ron writes: >> > >> > I can try to clarify that if there's a question in your mind that >> > you don't think I touched on there. >> >> The question that remains is what you actually intend to do. > > Nod. So far here, I've mostly tried to stick to just outlining the > facts we have to deal with, and the options I think we have and the > pros and cons of them - because I don't have a preconceived answer > to that which I'm welded to, and I was more interesting in listening > to well considered comments that people might have had than turning > this into a mindless tug of war between two inflexible positions. It's too bad that you only started doing this after this was escalated to the CTTE. Had you responded at such length and with so little delay to the earlier bug reports, the situation would be very different. But now, your sudden communicativeness just has the opposite effect. In my opinion, the fact that you had no time for this issue for multiple years, but are now able to send a large number of long emails about it to the ctte does not speak in your favor. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sun, Nov 06, 2016 at 05:09:56PM -0800, Nikolaus Rath wrote: > On Nov 06 2016, Ron wrote: > > On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote: > >> Ron writes: > >> > > >> > I can try to clarify that if there's a question in your mind that > >> > you don't think I touched on there. > >> > >> The question that remains is what you actually intend to do. > > > > Nod. So far here, I've mostly tried to stick to just outlining the > > facts we have to deal with, and the options I think we have and the > > pros and cons of them - because I don't have a preconceived answer > > to that which I'm welded to, and I was more interesting in listening > > to well considered comments that people might have had than turning > > this into a mindless tug of war between two inflexible positions. > > It's too bad that you only started doing this after this was escalated > to the CTTE. Had you responded at such length and with so little delay > to the earlier bug reports, the situation would be very different. But > now, your sudden communicativeness just has the opposite effect. > > In my opinion, the fact that you had no time for this issue for multiple > years, but are now able to send a large number of long emails about it > to the ctte does not speak in your favor. I'm sorry, remind me again about where and what you have ever tried to offer that would be of value to resolving this which I didn't respond to? Because I've had countless detailed discussions with people who have, and I don't recall you ever being part of any of that. Just repeating myself over and over to people who clearly weren't interested in helping with what was needed to solve the Hard parts of this, proved itself time and again to be an insane hope. I'm sorry for you if what you spent a few minutes skimming over didn't show that to you before you decided to pick up a stone and throw it. I've always given time to anyone who took the time to understand and showed an interest and willingness to try something new to improve this. And it's clear that the person who gave the most recent (and best) feedback to the original bug found it easy enough to clearly understand the situation from what was already written there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#190 Which part of that did you not understand? If you want to understand reality, then you ought to understand that it's drive-by mud slinging like yours which have led to a lot of capable developers simply unsubscribing from most or all of Debian's mailing lists to avoid getting mired in them. And it's aggressive prejudice like Ian's, and the people who thought they could (ab)use it to get their way in an argument which led to a lot of people losing trust in the TC to actually do Good Things. Vincent brought this here after contributing nothing more constructive or indicative of understanding than stamping his feet and insisting "I want a new upstream and I want it now. And I want someone else to do the work". I've taken the time to repeat this all again now, because regardless of how it got here, I actually have some faith in the new face of the TC as a forum for building 'project wide' consensus around hard problems. Having read all of that, Phil has now asked me to propose a concrete alternative to what he suggested, which I did. And I think the important difference is that we have the opportunity to build a consensus here which includes a good proportion of impartial and non-partisan voices who weighed up all the options like I've been doing. People who will have my back to say this was well thought through, if and/or when other people start making contentless complaints like you are about whatever the new state ends up being, and taking sides, and throwing more stones. People whose time is potentially valuable and shouldn't be wasted. I'm looking at this as a test of how the TC might be able to function like that as much as anything else, and I think that's worth a bit of the time that I have to give to Debian. So if this is the best analysis you are capable of sharing based on all of what has been written about this - then indeed you will have to just forgive me and learn if I henceforth don't continue to respond to your comments when they add nothing to the solution. The way you make time to engage in things that might really make a difference is to not waste it on things that obviously won't. I can't make you want to learn and think. But I hope that one day you'll understand that you're bringing nothing to the discussion but distracting noise if you don't. In the meantime, can we first please stay focussed on solutions to the _problem_ instead of just childishly attacking the man stuck on the pointy end of it. This is already hard enough without also having to set the record straight about ignorant slurs on what I have or haven't done and uninformed speculation about why ... that sort of nonsense isn't helping anyone get this resolved f
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 7 novembre 2016 16:45 +1030, Ron : > I've always given time to anyone who took the time to understand and > showed an interest and willingness to try something new to improve > this. And it's clear that the person who gave the most recent (and > best) feedback to the original bug found it easy enough to clearly > understand the situation from what was already written there: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#190 A message that received absolutely no answer (and quite similar to the other reports: doesn't work with current version, works with the new upstream version, kthxbye). > Vincent brought this here after contributing nothing more constructive > or indicative of understanding than stamping his feet and insisting > "I want a new upstream and I want it now. And I want someone else > to do the work". "Now" was three years ago. My last message in the above bug report [0] was also received with a silence on your side. There are 15 people in the thread asking for a new upstream version. Several of them proposed patches to package a new version. None of them get an answer from you. Nobody will help debug an issue and build a patch on an 8 year old software while there are new versions available. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171 -- Document your data layouts. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Nov 07 2016, Ron wrote: >> In my opinion, the fact that you had no time for this issue for multiple >> years, but are now able to send a large number of long emails about it >> to the ctte does not speak in your favor. > > I'm sorry, remind me again about where and what you have ever tried > to offer that would be of value to resolving this which I didn't > respond to? > > Because I've had countless detailed discussions with people who have, > and I don't recall you ever being part of any of that. [...] > I've taken the time to repeat this all again now, because regardless > of how it got here, I actually have some faith in the new face of the > TC as a forum for building 'project wide' consensus around hard problems. > Having read all of that, Phil has now asked me to propose a concrete > alternative to what he suggested, which I did. And I think the important > difference is that we have the opportunity to build a consensus here > which includes a good proportion of impartial and non-partisan voices who > weighed up all the options like I've been doing. It seems you're only interested in impartial and non-partisan voices when they happen to back your position. I am impartial and non-partisan, and formed my opinion by reading the bugs and your emails. If you indeed welcome opinions from people like me, your statements above are a little odd. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote: > On Nov 07 2016, Ron wrote: > > > I've taken the time to repeat this all again now, because regardless > > of how it got here, I actually have some faith in the new face of the > > TC as a forum for building 'project wide' consensus around hard problems. > > Having read all of that, Phil has now asked me to propose a concrete > > alternative to what he suggested, which I did. And I think the important > > difference is that we have the opportunity to build a consensus here > > which includes a good proportion of impartial and non-partisan voices who > > weighed up all the options like I've been doing. > > It seems you're only interested in impartial and non-partisan voices > when they happen to back your position. I am impartial and non-partisan, > and formed my opinion by reading the bugs and your emails. And "your opinion" still hasn't said even a single word to show that you understand the technical problem here, or to offer any solution to it. The problem which doesn't just magically go away regardless of who might implement it. And now you say that apparently you didn't even read the conversation that you interjected into enough to notice that Phil and I were having a civil discussion precisely on the _difference_ we saw in ways that this might be 'solved' ... All you did was dismiss and (continue to) try to side track that. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#155 (for anyone who missed it before people tried to bury it piling on to the man again) > If you indeed welcome opinions from people like me, your statements > above are a little odd. I think you missed the bit about "comprehending the problem and building consensus on solutions" - because if this is all you have to offer then no, "opinions" from people "like you" are neither helpful nor welcome. Even if they 100% agree with me. They are just a toxic symptom of people still ignoring the hard technical problem. Which is very different from the suggestions of people, say, "like Phil", where no matter how much we disagree at the outset, we can still focus that on looking at the merits of ways to solve the problem as best we can in the circumstances that we have. And try to come to some sort of best consensus on it. When you understand that distinction, and have something we've all missed to contribute, _then_ you'll be welcome, whoever you're disagreeing with. If all you want to do is play "Trump school of debate", then please take that somewhere else, and leave this thread to focus on the technical details of _what_ we ought to do. If we don't solve that, then who does it is kind of irrelevant, there'll still be a Hard Problem that someone won't be happy with. Ron
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > I think you missed the bit about "comprehending the problem and building > consensus on solutions" Somehow I missed the part where you helped contributors to "comprehend the problem" and enabled them to "build consensus on solutions" between March 2010 and mid-October 2016. No, wait, that's because you didn't. You basically just said "no". Maintainership of this package should be transferred to maintainer(s) who are capable of encouraging and leading a community, rather than a maintainer who simply obstructs (and only responds with fine words when is a threat to their authority). The leadership aspects of maintainership are the only essential capacities of a Debian maintainer and with respect to this package, your record is of failure. It is obvious that there are a variety of possible technical approaches, most if not all of which are better than maintaining the status quo for half a decade. I have confidence that if the package were wrested from your control, and the petitioners made maintainers, the technical aspects would be resolved adequately. The real problem here is not technical. This is a management failure. Ian. Full disclosure: * I know Wei Liu as a work colleague and friend and encouraged him to participate in this bug report; * As Ron may remember, I previously encountered him in a previous situation that came before the TC, relating to codecs and mumble. It's some years ago now but IIRC I found myself disagreeing with Ron. * I have formed my opinion about `global' by reading the bug logs. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, Nov 08, 2016 at 02:52:29PM +, Ian Jackson wrote: > Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new > upstream version"): > > I think you missed the bit about "comprehending the problem and building > > consensus on solutions" > > Somehow I missed the part where you helped contributors to "comprehend > the problem" and enabled them to "build consensus on solutions" > between March 2010 and mid-October 2016. Yes, you did. And you managed to miss it despite the fact I gave links to the public discussions in my first reply here and that other people in those have referred to the private discussions we had too. I'm impressed. Or are you seriously suggesting that I ought to have repeated all of that, every time, to every person who said "me too" without adding anything new to the discussion or situation? But thanks for adding one more example of how trivial it is to play the blame game when you have nothing of value to add for actually helping to make thing better - and for making it clear that many of the people doing that are being agitated to by others rather than having any real interest in the quality of what Debian ships. Clap, clap.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > On Tue, Nov 08, 2016 at 02:52:29PM +, Ian Jackson wrote: > > Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new > > upstream version"): > > > I think you missed the bit about "comprehending the problem and building > > > consensus on solutions" > > > > Somehow I missed the part where you helped contributors to "comprehend > > the problem" and enabled them to "build consensus on solutions" > > between March 2010 and mid-October 2016. > > Yes, you did. And you managed to miss it despite the fact I gave links > to the public discussions in my first reply here and that other people > in those have referred to the private discussions we had too. I assume you are talking about: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166 These are the only two references I could find in the whole of this bug (#841294) from you to your own earlier messages. In fact #574947 contains only FIVE responses from you over a period of SIX YEARS. #816924, filed in March 2016, contains none. It is true that 574947#131, in April 2014, contains an explanation of an underlying technical difficulty. But it also contains a strong NAK, and this wording: I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. It is not appropriate for the Debian maintainer to firmly NAK at the same time as asking contributors to set direction. 574947#166 is, like most of your messages, a very short mail saying "please fix it" without any proposed technical approach. I do not deny that there is an underlying technical difficulty. But in the absence of someone doing some substantial engineering to make the questionable upstream feature packageable, there is a simple choice: Either we stay with the current, ancient version; or we disable the troublesome feature (or ship it in a broken state, where it is necessary to be root to use it). The tradeoff you have chosen is to privilege hypothetical users of a niche feature, in favour of a clamour of users wanting the benefits of the new upstream version. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > These are the only two references I could find in the whole of this > bug (#841294) from you to your own earlier messages. In fact #574947 > contains only FIVE responses from you over a period of SIX YEARS. > #816924, filed in March 2016, contains none. I made this timeline to show how Ron thinks it is appropriate to deal with this package. Messages to #574947 and #816924, combined Each # is one email Each P is one email containing a patch or link to updated package Each U is one upload Users and Maintainer Notes contributorsactivity # Mar 2010 Request for 5.9.3 Apr 2010 May 2010 Jun 2010 Jul 2010 Aug 2010 # Sep 2010 Oct 2010 U Last-ever maintainer upload Nov 2010 [ last new-upstream-version P Dec 2010 upload was in 2008. ] Jan 2010 Feb 2010 # Mar 2011 Apr 2011 May 2011 # Jun 2011 User reports success Jul 2011 with Dec patch for 5.9.x Aug 2011 Sep 2011 Oct 2011 Nov 2011 Dec 2011 Jan 2012 Feb 2012 Mar 2012 Apr 2012 May 2012 Jun 2012 # Jul 2012 Aug 2012 Sep 2012 Oct 2012 Nov 2012 Dec 2013 Jan 2013 P# Feb 2013 # Mar 2013 ## Apr 2013 # ## May 2013 # Jun 2013 Jul 2013 Aug 2013 Sep 2013 Oct 2013 # Nov 2013 Dec 2013 # Jan 2014 Feb 2014 # Mar 2014 #P Apr 2014 ## May 2014 Jun 2014 # Jul 2014 Aug 2014 Sep 2014 Oct 2014 Nov 2014 Dec 2014 Jan 2015 Feb 2015 # Mar 2015 Apr 2015 May 2015 # Jun 2015 Jul 2015 Aug 2015 Sep 2015 Oct 2015 Nov 2015 Dec 2015 Jan 2016 Feb 2016 ### Mar 2016 # Apr 2016 May 2016 Jun 2016 Jul 2016 Aug 2016 Sep 2016 ### Oct 2016 --- tc referral -- -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > I made this timeline to show how Ron thinks it is appropriate to deal > with this package. > > Messages to #574947 and #816924, combined > Each # is one email > Each P is one email containing a patch or link to updated package > Each U is one upload I should say that this timeline drastically _under_represents the change in Ron's engagement with the technical problems in this package, following TC referral. Many of his copious mails in the TC thread are each in themselves longer than _all his pre-TC mails on this topic combined_ ! Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, 8 Nov 2016 15:33:32 +1030 Ron wrote: > On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote: > > It seems you're only interested in impartial and non-partisan voices > > when they happen to back your position. I am impartial and non-partisan, > > and formed my opinion by reading the bugs and your emails. > > And "your opinion" still hasn't said even a single word to show that you > understand the technical problem here, or to offer any solution to it. > The problem which doesn't just magically go away regardless of who might > implement it. Even if your technical concerns were correct, they do not justify your handling of the package. Saying that your actions have been wrong, and the package needs to be handled differently, does not require addressing the technical CGI issues in any way. You have no basis to insist that people care about the CGI issue or try to solve it before commenting on other handling of the package. > > If you indeed welcome opinions from people like me, your statements > > above are a little odd. > > I think you missed the bit about "comprehending the problem and building > consensus on solutions" - because if this is all you have to offer then > no, "opinions" from people "like you" are neither helpful nor welcome. > Even if they 100% agree with me. They are just a toxic symptom of people > still ignoring the hard technical problem. "The problem" here is the way you've blocked the package at an ancient version. Fixing this does not require creating a perfect CGI framework or in any other way fixing all upstream issues and making the software perfect. Maybe _you_ really care about the CGI issue. But if nobody - including you - cares enough to create a perfect solution, then it'll be broken. Too bad, but even if you're really disappointed, holding the package indefinitely at an obsolete version is not an acceptable response. Again, that nobody has created a perfect upstream does not justify your handling of the package, and you don't get to blame others or call their behavior "toxic" because of that. > details of _what_ we ought to do. If we don't solve that, then who does > it is kind of irrelevant, there'll still be a Hard Problem that someone > won't be happy with. You keep talking about Hard Problems and how others must solve them to be allowed to criticize your actions or actually do anything to change the status quo that you've failed to improve for several years. That's bullshit. If someone packages a new upstream without solving those issues, that'll be perfectly acceptable. Fixing software to be perfect is not a requirement for packaging, and creating a package that lacks some desired functionality when upstream lacks it is OK. The way you've handled the package is not OK.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, Nov 08, 2016 at 04:56:40PM +, Ian Jackson wrote: > Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to > package a new upstream version"): > > I made this timeline to show how Ron thinks it is appropriate to deal > > with this package. > > > > Messages to #574947 and #816924, combined > > Each # is one email > > Each P is one email containing a patch or link to updated package > > Each U is one upload > > I should say that this timeline drastically _under_represents the > change in Ron's engagement with the technical problems in this > package, following TC referral. > > Many of his copious mails in the TC thread are each in themselves > longer than _all his pre-TC mails on this topic combined_ ! It's ok, we get it. You've got an axe to grind, and boy are the sparks flying off it thick and hot! The volume of private mail I've expended, over a much longer period than is in than is in the public archives, at trying to find a resolution to this dwarfs anything here too - so you might understand why I'm a little tired of repeating it to people who are bringing nothing to the table. Or why I didn't repeat it again to people who opened duplicates of the original BTS thread. So please just go take a cold shower or something, instead of wasting everyone's time bloating this thread with hysterical foaming and misrepresentation of what I actually said, and what people actually need, that is irrelevant to us deciding _what_ the best compromise is for what should be in any future package of this software. I'm sure there's plenty of other even older bugs in the BTS which haven't been fixed yet that you could spend some of your overzealousness on if you're that desperate to vent your rage on things you've never contributed to, or used, or taken the time to understand. Unless you're just trying to bury the embarrassment of your previous hasty post under a mountain of stuff people's eyes will glaze over on. In which case, knock yourself out. I guess. It's your permanent record. But I've got Real Work to do, and we've got a release freeze looming, and wasting time on being bullied by you isn't helping any of that.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > It's ok, we get it. You've got an axe to grind, and boy are the sparks > flying off it thick and hot! My axe is the same one I often have in Technical Committee discussions. It is the axe of challenging the unaccountable power exercised by despotic Debian package maintainers, within the fiefdoms of their countless petty autocracies. My axe is the axe that would chop aside the barriers erected by those who dislike other people's software, and who use their position to obstruct and to destroy. My axe is the axe that would clear the path for collaboration. My axe is the axe of freedom for Debian's users and contributors. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Could you both please stop? Sniping at eachother is not helping us resolve the technical and social issues here. -- Don Armstrong https://www.donarmstrong.com More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote: > ]] Wei Liu > > > Gtags in Debian doesn't work with modern code base. Last time I tried > > (several > > years ago), it segfault'ed while trying to index Linux kernel. > > FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and > last time I used it, it also worked fine with the emacs integration, so > I don't recognise the crying from the rooftops about it being broken in > Debian. It seems that it depends on the kernel source tree in use. I just tried on a couple and found these reuslts: ~/debian/linux-4.0$ gtags ~/debian/linux-4.0$ global -s enable_dbg arch/arm64/include/asm/assembler.h 4 files generated: GPATH GTAGS GSYMS GTAGS ~/debian/linux-3.16.7-ckt9$ gtags gtags: directory stack over flow. ~/debian/linux-3.16.7-ckt9$ global -s enable_dbg global: GSYMS not found. only 2 files generated: GPATH GTAGS global 6.5.4 (upstream release) works on both. ( I also found 844330 in the process, which is just a packaging update issue ) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, Nov 14, 2016 at 04:55:06PM +, Wookey wrote: > On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote: > > > > FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and > > last time I used it, it also worked fine with the emacs integration, so > > I don't recognise the crying from the rooftops about it being broken in > > Debian. > > It seems that it depends on the kernel source tree in use. Just to clarify this here based on the details you provided when you later reported https://bugs.debian.org/844356, it turns out that it apparently doesn't depend on the kernel source tree or its version as such - what you saw happens when the source tree is polluted with infinite symlink loops, apparently due to a broken build script in this case. Which is something lots of things will choke on, and there is an easy workaround which most people should be using anyway if they are using this on codebases of this size, to skip uselessly indexing the bulk of the build tree where there is no source you want tags for. But thanks for the good report in that bug about _what_ really went wrong for you there. This is useful information. > ( I also found 844330 in the process, which is just a packaging update issue ) And thanks for the pointers to what changed with the emacs policy in this one too. That one was only evident if you actually had emacs installed (which I don't), and which nobody else had so far reported. It should be fixed in sid now though. Good bug reports are the foundation for getting things fixed, so thanks for setting a good example there. Cheers, Ron
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Hi, apologies for the delay in responding here. ]] Ron […] > I'd really like to keep this to just one package, for the reasons > already given (though there's surely more if anyone still needs > even more). This sounds pretty reasonable to me. > I'd really like to avoid "surprising" anyone unreasonably by pulling > the rug out from under them with no time to usefully give us their > own feedback too, and/or to contribute patches (here or upstream) to > remedy that in some suitable way. Not everyone does nothing when > that is the option they are presented with. > > I'd really like this to converge on a 'final' conclusion in a shorter > timeline than "before we really run out of toy story release names > forever". > > And I'd really like it to have a strong enough technical basis and > consensus that we can still stand by it even if there are a few > people who do cry foul from the rough - however loudly or insistently. > > Bonus points for minimising the risk of some unforeseen clusterfck > emerging that we'll only be able to (try to) fix under the stricter > freeze update rules, or that might mean we end up shipping with > nothing at all for Stretch. This all sounds reasonable to me. > Given that we're now on both the cusp of the freeze and the silly > season of the year where holidays and other rituals thin out the > attention people have for other things until the new year, and > that the smoother the freeze goes, the sooner we'll be out of it > again after February, and that given how long this has already > gone on for, that really isn't very far away ... > > What I think is looking 'best', would be to once again extend the > offer, to anyone whose joy is ruined by what we currently have, > to accept (and/or help create) reasonable patches to what we > currently have to fix that for them. If you don't drag your feet > on that, we should have plenty of time to review and upload those. Ok. > Then once the cycle begins for Stretch+1 early next year, we'll > make the move to drop htags and pull in an audited new upstream > release from whatever is current at the time. Assuming it doesn't > jump an entirely new and bigger shark in the meantime to add some > other horrible disaster that we don't yet know about. > > That means we can start telling people _now_ to expect that will > happen unless they can make a case otherwise. And that anyone > who doesn't get that memo will have a whole release cycle to > see that it's gone, and try to make their case then. Probably makes sense to add a warning anybody running htags now that «this will be dropped in the next release», then. > If nobody at all does that by the time Stretch+1 freezes, then > we can have fairly good confidence in it being a 'final' answer. > If they do, then again we actually have time to try and find a > better solution before it becomes set in stone. And we'll at > least have given them about as fair a chance, with as much > warning, as we ever reasonably can offer to do that. Yup. [...] > I'm still open to listening to other suggestions, but if we have > a sufficient consensus on this, and nothing better on the table, > then, unless I've also missed some horrible showstopper, I think > I'm willing to run with it. I think this sounds quite reasonable, all in all. It gets us a newer version (albeit not for stretch, but I see the points about changing that so close to the freeze), it gives users some warning about htags going away (and if that's a huge problem, we can adjust course as we learn more). Vincent, would this be acceptable to you? The rest of the committee: what do you think? Is this an ok way through? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, 15 Nov 2016 21:32:38 +0100 Tollef Fog Heen wrote: > I think this sounds quite reasonable, all in all. It gets us a newer > version (albeit not for stretch, but I see the points about changing > that so close to the freeze), it gives users some warning about htags > going away (and if that's a huge problem, we can adjust course as we > learn more). Would it be possible to provide an new upstream release in experimental (now) and have a 6.* based version in stretch-backports once stretch is released? As an outsider, who doesn't really use global but is just reading what's going on here, this seems like it would satisfy almost everyone Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 15 novembre 2016 21:32 +0100, Tollef Fog Heen : > Vincent, would this be acceptable to you? My understanding of Ron's mail is the following: do nothing now and wait for Stretch release to see what version could be packaged. I am not thrilled by this option (but I rank it above the "do nothing" option). There was no upload for 6 years. A new version could be uploaded in unstable before the release and blocked by an RC bug. Or to experimental like suggested. -- Write clearly - don't sacrifice clarity for "efficiency". - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-11-16 06:02 +1030, Ron wrote: > On Mon, Nov 14, 2016 at 04:55:06PM +, Wookey wrote: > > On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote: > > > > > > FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and > > > last time I used it, it also worked fine with the emacs integration, so > > > I don't recognise the crying from the rooftops about it being broken in > > > Debian. > > > > It seems that it depends on the kernel source tree in use. > > Just to clarify this here based on the details you provided when you > later reported https://bugs.debian.org/844356, it turns out that it > apparently doesn't depend on the kernel source tree or its version > as such - what you saw happens when the source tree is polluted with > infinite symlink loops, apparently due to a broken build script in > this case. Right. I was going to reply with that bug pointer here. It is an example of something that newer upstream versions cope with without failing. So is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756367 which I have just confirmed is still a bug with 5.7.1, but not with 6.5.5 (There was a request earlier in this thread for actual issues with 5.7.1, that are fixed in newre releases, IIRC) I added a note in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947 on that packaging update. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, 21 Nov 2016 17:16:34 +1030 Ron wrote: > If we run with your proposal, what are you actually suggesting we tell > the people who'd be upset by the loss of htags without notice in Stretch? > Because I don't really see how you've addressed that here. > > AFAICS, there's just either an implicit "Sucks to be you", or an > implication that this is a simple "regression" which might be fixed > by sending patches upstream. Assuming the htags functionality really can't be supported with a newer upstream version: tell people that the functionality is no longer available in current GLOBAL. If someone - including you - thinks this is a major problem and wants to provide an alternative, a fork providing this functionality can be packaged. Under a name other than "global". > FWIW, I actually agree with a lot of the general rules of thumb that > you outlined here, about how things should work in the normal case. > But this isn't really a "normal" case, if it was we wouldn't be talking > about this here at all. What to do would be obvious to everyone. There's nothing particularly "abnormal" about disagreeing with upstream decisions. What is unusual, and is the reason why this has been escalated here, is how badly you have handled the situation in your packaging. > The group complaining loudly now have basically squandered the entire > release cycle by not reporting actionable bugs about what they need, > and haven't sent any patches to remedy that. And they are proposing If anyone has "squandered the release cycle", it's you. You already knew, or should have known, that the package was in an untenable state. You've failed to fix the situation for years. You don't get to blame other people for that. >
Bug#841294: Overrule maintainer of "global" to package a new upstream version
The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up the different outcome possibilities, which would help forming our opinions. Not all these options are exclusive, or would need an actual TC decision. Here we go: A) 'global' stays maintained as it currently is. This would imply: - no new 'global' upstream release before stretch, - no 'htags removal' warning in stretch, - possibility for the maintainer (and/or other interested parties) to start maintaining a 'global6'; this wouldn't offer any guarantee for a more recent version of 'global' in stretch. This would also imply having two 'global' packages in certain suites. B) A fresher version of 'global' is uploaded to experimental 'soon' (with or without interested parties' help; with or without a TC decision) This would imply: - any interested party would file (and close) Debian bugs for issues and regressions (with appropriate severities), to make the 'fitness for a stable release' assessment easier, and earlier. C) After the release of stretch, a fresher version of 'global' is uploaded to unstable with the explicit goal of making it available in buster. This would imply: - any interested party would file (and close) Debian bugs for issues and regressions (with appropriate severities), to make the 'fitness for a stable release' assessment easier. - after migration to testing, this would make the fresher version of 'global' available for backporting to stretch-backports. - the version of 'global' released in stretch could carry 'htags removal' warnings; D) A fresher version of 'global' is uploaded to unstable 'soon', targetting stretch (with or without interested parties' help; with or without a TC decision) This would imply: - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority in a TC vote); - any interested party (including the maintainer) would file (and close) Debian bugs for issues and regressions (with appropriate severities), to make the 'fitness for a stable release' assessment easier. - that this fresher version of 'global' would reach 'fit for release' status before the Stretch release. E) the 'global' package is handed to other maintainer(s) This would imply: - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority in the TC vote); -- Cheers, OdyX [0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte. 2016-11-22-16.59.html signature.asc Description: This is a digitally signed message part.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-11-23 18:19 +0100, Didier 'OdyX' Raboud wrote: > The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up > the different outcome possibilities, which would help forming our opinions. > Not all these options are exclusive, or would need an actual TC decision. > > Here we go: > > B) A fresher version of 'global' is uploaded to experimental 'soon' >(with or without interested parties' help; with or without a TC decision) > > This would imply: > - any interested party would file (and close) Debian bugs for issues and >regressions (with appropriate severities), to make the 'fitness for a >stable release' assessment easier, and earlier. OK, as Punit and I have prepared a current 6.5.5 which would be a candidate for a 'modern' release, and I think it's useful to have such a version available for people to test and file bugs against, I will do a 5-day delayed NMU to experimental. Putting it in experimental does not imply automatic transtion to stretch, nor block uploads via unstable, so seems a reasonable thing to do. This version is not perfect, but it is current with updated packaging. I'll include details of the known issues in one of the 'please can we have a new version' bugs. I think it's more useful to have the current state of play avalable than for me to keep messing with it privately. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Wookey writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > OK, as Punit and I have prepared a current 6.5.5 which would be a > candidate for a 'modern' release, and I think it's useful to have such > a version available for people to test and file bugs against, I will > do a 5-day delayed NMU to experimental. Putting it in experimental > does not imply automatic transtion to stretch, nor block uploads via > unstable, so seems a reasonable thing to do. > > This version is not perfect, but it is current with updated > packaging. I'll include details of the known issues in one of the > 'please can we have a new version' bugs. I think it's more useful to > have the current state of play avalable than for me to keep messing > with it privately. Hooray, thank you. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Didier 'OdyX' Raboud writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > E) the 'global' package is handed to other maintainer(s) > > This would imply: > > - overruling the 'global' maintainer's decision (§6.1.4, implies >3:1 majority in the TC vote); No, handing the `global' package to other maintainer(s) would be a decision under 6.1(2). Quoting that section: In cases where Developers need to implement compatible ... stances (for example, if they [Developers] disagree about [various things], ** or about who should be the maintainer for a package) ** the technical committee may decide the matter. 6.1(2) does not have a 3:1 requirement. Ian.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Wed, Nov 23, 2016 at 5:19 PM, Didier 'OdyX' Raboud wrote: > The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up > the different outcome possibilities, which would help forming our opinions. > Not all these options are exclusive, or would need an actual TC decision. > > Here we go: > > A) 'global' stays maintained as it currently is. > > This would imply: > - no new 'global' upstream release before stretch, > - no 'htags removal' warning in stretch, > - possibility for the maintainer (and/or other interested parties) to start >maintaining a 'global6'; this wouldn't offer any guarantee for a more >recent version of 'global' in stretch. This would also imply having two >'global' packages in certain suites. > > B) A fresher version of 'global' is uploaded to experimental 'soon' >(with or without interested parties' help; with or without a TC decision) > > This would imply: > - any interested party would file (and close) Debian bugs for issues and >regressions (with appropriate severities), to make the 'fitness for a >stable release' assessment easier, and earlier. > > C) After the release of stretch, a fresher version of 'global' is uploaded to >unstable with the explicit goal of making it available in buster. > > This would imply: > - any interested party would file (and close) Debian bugs for issues and >regressions (with appropriate severities), to make the 'fitness for a >stable release' assessment easier. > - after migration to testing, this would make the fresher version of 'global' >available for backporting to stretch-backports. > - the version of 'global' released in stretch could carry 'htags removal' >warnings; > > D) A fresher version of 'global' is uploaded to unstable 'soon', targetting >stretch (with or without interested parties' help; with or without a TC >decision) > > This would imply: > - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority >in a TC vote); > - any interested party (including the maintainer) would file (and close) >Debian bugs for issues and regressions (with appropriate severities), to >make the 'fitness for a stable release' assessment easier. > - that this fresher version of 'global' would reach 'fit for release' status >before the Stretch release. > > E) the 'global' package is handed to other maintainer(s) > > This would imply: > - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority >in the TC vote); In offline discussions with Wookey, we came to the realisation that reading the various bug reports (including this one) it is not very clear how global (upstream) is structured, the functionality it provides and bits that are holding back the debian update. Gnu Global is a source code tagging system similar in functionality to ctags or cscope. It allows searching for symbol definitions and use in the codebase by splitting the functionality into two steps - * Indexing - This is a offline step where an index of source code symbols definitions and references for a code base is created. This functionality is provided by "gtags" binary (part of upstream global). Indexes (or is it indices?) typically live in the source tree (they don't need to). * Searching - Once the code base is indexed, the indexes can be used to search for symbol definitions as well as query locations where the symbol is referenced. This can be done using the "global" binary (again provided by upstream). Also there are various integrations with commonly used editors - emacs, vim, elvis, etc - that internally invoke global for their symbol lookup requirements. So if you are a developer who would like to use global to navigate your way through a large code base a common way to use it would be to use "gtags" and the editor integration of your choice. In addition to the above mechanisms, upstream also provides "htags" which can be used to generate an HTML version of the index. "htags" uses the index created by "gtags" and the source tree as input and generates html files which allow you to navigate the source code in the browser. By default, htags generates static pages which means you can browse the code in a local browser without requiring a web server. Optionally, "htags" can generate a dynamic index (which reduces disk space usage) but requires an http server setup to be able to serve the pages. In this scenario, you will also need to be able to execute CGI scripts as the symbol lookup is done when serving the http request (as opposed to pre-processed when using static pages). And this last bit (integration with system web server) is the functionality that had security concerns raised by Ron and for which there are patches in the debian package. In recent versions (> 6.4, Apr '15), upstream has dropped support for generating scripts that expect to be written to system cgi-bin folder. As demonstrated by wookey[1], it is still possible to use the d
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"): > In offline discussions with Wookey, we came to the realisation that > reading the various bug reports (including this one) it is not very > clear how global (upstream) is structured, the functionality it > provides and bits that are holding back the debian update. Thank you for your clear and excellent explanation. On to some questions it raises for me: > Optionally, "htags" can generate a dynamic index (which reduces disk > space usage) but requires an http server setup to be able to serve the > pages. In this scenario, you will also need to be able to execute CGI > scripts as the symbol lookup is done when serving the http request (as > opposed to pre-processed when using static pages). > > And this last bit (integration with system web server) is the > functionality that had security concerns raised by Ron [etc.] So, to be clear, it is this functionality which is dropped in the package that you and Wookey uploaded to experimental/delayed ? But AIUI this functionality remains: > In addition to the above mechanisms, upstream also provides "htags" > which can be used to generate an HTML version of the index. "htags" > uses the index created by "gtags" and the source tree as input and > generates html files which allow you to navigate the source code in > the browser. By default, htags generates static pages which means you > can browse the code in a local browser without requiring a web server. So the impact for a user of the existing functionality the regression is not that their entire workflow is disrupted. Rather (unless the software is improved) they have these choices: - Put up with pregenerated html indices. Is the only downside of this that they use additional disk space, and presumably cpu time to generate them ? - Run the htags server on a high-numbered port somehow. (Is there some kind of simple scriptery provided, to do this?) - If the machine is not really multi-user, tear down the security boundary defending the webserver from their user account, and give their user account access to the webserver cgi directory (or plumb it in with symlinks). (Are there any instructions or scripts for this?) (Also this assumes that the source code is not super secret.) I don't know much about this, but several of these choices seem likely to be plausible choices for many if not most current users of htags. FAOD none of this changes my view about the proper resolution of this TC petition. But answers might help clarify the discussion. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Wed, Nov 30, 2016 at 4:56 PM, Ian Jackson wrote: > Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to package > a new upstream version"): >> In offline discussions with Wookey, we came to the realisation that >> reading the various bug reports (including this one) it is not very >> clear how global (upstream) is structured, the functionality it >> provides and bits that are holding back the debian update. > > Thank you for your clear and excellent explanation. > > > On to some questions it raises for me: > >> Optionally, "htags" can generate a dynamic index (which reduces disk >> space usage) but requires an http server setup to be able to serve the >> pages. In this scenario, you will also need to be able to execute CGI >> scripts as the symbol lookup is done when serving the http request (as >> opposed to pre-processed when using static pages). >> >> And this last bit (integration with system web server) is the >> functionality that had security concerns raised by Ron [etc.] > > So, to be clear, it is this functionality which is dropped in the > package that you and Wookey uploaded to experimental/delayed ? > The debian packaging added two tools not present in upstream - htconfig and htmake. These tools and debian patched htags together make the integration with system web server work to the extent that Ron was comfortable shipping the package. Both htmake and htconfig are authored by Ron. So although the package uploaded by Wookey retain the tools they have become non-functional due to upstream changes to htags. But as you point out, you can still achieve a very similar end result using other mechanisms. > But AIUI this functionality remains: > >> In addition to the above mechanisms, upstream also provides "htags" >> which can be used to generate an HTML version of the index. "htags" >> uses the index created by "gtags" and the source tree as input and >> generates html files which allow you to navigate the source code in >> the browser. By default, htags generates static pages which means you >> can browse the code in a local browser without requiring a web server. > > > > So the impact for a user of the existing functionality the regression > is not that their entire workflow is disrupted. That is exactly what I was trying to get across in my previous email. > > Rather (unless the software is improved) they have these choices: > > - Put up with pregenerated html indices. Is the only downside >of this that they use additional disk space, and presumably >cpu time to generate them ? There > > - Run the htags server on a high-numbered port somehow. (Is there >some kind of simple scriptery provided, to do this?) It would be a web server - htags isn't a server in itself. Upstream's suggestion of using python -m CGIHTTPServer in the generated HTML folder worked for the package Wookey has uploaded. This command can be executed with user privileges and runs a local instance of an http server. IIUC, running the web server with user privileges, prevents it from binding to external interfaces/IP addresses. > > - If the machine is not really multi-user, tear down the security >boundary defending the webserver from their user account, and give >their user account access to the webserver cgi directory (or plumb >it in with symlinks). (Are there any instructions or scripts for >this?) (Also this assumes that the source code is not super >secret.) So I am not very familiar with cgi scripts (having never used it myself) but I believe what you say is possible - somebody with a little more knowledge than me should be easily able to come up with the instructions. > > I don't know much about this, but several of these choices seem likely > to be plausible choices for many if not most current users of htags. > > > FAOD none of this changes my view about the proper resolution of this > TC petition. But answers might help clarify the discussion. > > Thanks, > Ian. > > -- > Ian JacksonThese opinions are my own. > > If I emailed you from an address @fyvzl.net or @evade.org.uk, that is > a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
I just noticed I missed out responding to one of your queries in my reply. On Wed, Nov 30, 2016 at 7:19 PM, Punit Agrawal wrote: > On Wed, Nov 30, 2016 at 4:56 PM, Ian Jackson > wrote: >> Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to >> package a new upstream version"): >>> In offline discussions with Wookey, we came to the realisation that >>> reading the various bug reports (including this one) it is not very >>> clear how global (upstream) is structured, the functionality it >>> provides and bits that are holding back the debian update. >> >> Thank you for your clear and excellent explanation. >> >> >> On to some questions it raises for me: >> >>> Optionally, "htags" can generate a dynamic index (which reduces disk >>> space usage) but requires an http server setup to be able to serve the >>> pages. In this scenario, you will also need to be able to execute CGI >>> scripts as the symbol lookup is done when serving the http request (as >>> opposed to pre-processed when using static pages). >>> >>> And this last bit (integration with system web server) is the >>> functionality that had security concerns raised by Ron [etc.] >> >> So, to be clear, it is this functionality which is dropped in the >> package that you and Wookey uploaded to experimental/delayed ? >> > > The debian packaging added two tools not present in upstream - > htconfig and htmake. These tools and debian patched htags together > make the integration with system web server work to the extent that > Ron was comfortable shipping the package. Both htmake and htconfig are > authored by Ron. > > So although the package uploaded by Wookey retain the tools they have > become non-functional due to upstream changes to htags. But as you > point out, you can still achieve a very similar end result using other > mechanisms. > >> But AIUI this functionality remains: >> >>> In addition to the above mechanisms, upstream also provides "htags" >>> which can be used to generate an HTML version of the index. "htags" >>> uses the index created by "gtags" and the source tree as input and >>> generates html files which allow you to navigate the source code in >>> the browser. By default, htags generates static pages which means you >>> can browse the code in a local browser without requiring a web server. >> >> >> >> So the impact for a user of the existing functionality the regression >> is not that their entire workflow is disrupted. > > That is exactly what I was trying to get across in my previous email. > >> >> Rather (unless the software is improved) they have these choices: >> >> - Put up with pregenerated html indices. Is the only downside >>of this that they use additional disk space, and presumably >>cpu time to generate them ? AFAICT, yes. >> >> - Run the htags server on a high-numbered port somehow. (Is there >>some kind of simple scriptery provided, to do this?) > > It would be a web server - htags isn't a server in itself. Upstream's > suggestion of using > > python -m CGIHTTPServer > > in the generated HTML folder worked for the package Wookey has > uploaded. This command can be executed with user privileges and runs a > local instance of an http server. > > IIUC, running the web server with user privileges, prevents it from > binding to external interfaces/IP addresses. > >> >> - If the machine is not really multi-user, tear down the security >>boundary defending the webserver from their user account, and give >>their user account access to the webserver cgi directory (or plumb >>it in with symlinks). (Are there any instructions or scripts for >>this?) (Also this assumes that the source code is not super >>secret.) > > So I am not very familiar with cgi scripts (having never used it > myself) but I believe what you say is possible - somebody with a > little more knowledge than me should be easily able to come up with > the instructions. > >> >> I don't know much about this, but several of these choices seem likely >> to be plausible choices for many if not most current users of htags. >> >> >> FAOD none of this changes my view about the proper resolution of this >> TC petition. But answers might help clarify the discussion. >> >> Thanks, >> Ian. >> >> -- >> Ian JacksonThese opinions are my own. >> >> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is >> a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sat, 10 Dec 2016 06:54:17 +1030 Ron wrote: > You then had the gall to angrily insist that while you thought he might > be a better maintainer than me, it was still my responsibility to do the > work to fix all the obvious things that others had missed in their fork > (which he hadn't contributed anything to either). I'm afraid that's not > how encouraging volunteers to contribute their time for you works ... > sorry if this is news to you. It was perfectly reasonable to ask that if you have any pretense at all of actually doing the work expected of your maintainer position, you'd contribute to creating packaging for the new upstream version, instead of only attacking the people working on it. > things. But because the increasingly ill-named technical committee has once > again refused to stick its collective necks out to actually offer technical > advice when explicitly asked to. We chopped some heads off the hydra, but > Explaining things in careful detail has had every appearance of being a > complete waste of my time whichever way this might have ended up. The only The fundamental problem with most of your technical arguments was that they were arguments about upstream development, not about packaging. Even if they were 100% true, they still would not justify how you have handled the Debian package. If you disagree with upstream that way, you should try to convince them, and if that fails and you care enough, create a new upstream fork. Instead, you turned the Debian packaging into a practical fork. That's not the right place for hosting a new fork. You also obviously did a bad job of maintaining your fork (given the complete lack of development). Your attitude seems to have been that you insist on keeping the original GLOBAL out of Debian, do no development at all yourself, and if anyone has problems with your fork you insist that they do the work of developing it. That's not reasonable at all.
Re: Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-10-25 07:33 +0200, Tollef Fog Heen wrote: > ]] Ian Jackson > > > * Specifically, failed to give clear and constructive directions to > >those willing to do the work; > > I disagree with those characterisations. He's asked for clarifications > on what is broken without anything resembling an adequate reply. NOW, yes, when after 5 years people gave up filing bugs and brought it to the technical committee. _Now_ Ron has ample time to write very long responses. But the problem is that he didn't respond usefully in the bugs, for years. Various people said 'the debian version doesn't work, but the current upstream version does, can we upgrade please?'. And were mostly ignored or given short shrift. (Vincent just posted URLS). Normal people, who are not of the Ian and Ron (and me) 'old-school Debian, we quite like an argument' personality type, find this _extremely_ offputting. I am only involved because I work with Punit and he came to me asking for advice on what to do. He's not posting here because the last thing he wants is an argument (you know, the sort of quiet person who _really_ doesn't like arguments). He thinks it's silly that we can't have a newer version of global, but if that's what decided, then fine. He won't argue - he'll just use upstream, debian will be stuck with the ancient version, and we'll have lost a contributor. As he points out - there are many, many other things he can do with his spare time that don't involve an argument or dealing with a difficult maintainer. So if this thing is only assessed in terms of who is the most enthusiastic debater then Ron wins (he's very good at it). I realise this makes things harder for the TC to assess, because they see a rather one-sided view. I would just ask them to bear personalities and communication preferences in mind. (As I said to Punit, 'everything used to be like this, but we improved a lot in the last few years, and this is much rarer than it used to be'). Debian used to have a (largely deserved) reputation as an unpleasant project to work in. We've done a lot in the last few years to improve that situation. I invite the TC to reflect on how this would have played out if global had had a different maintainer. This is (or should be) about attitude, responsiveness, and helpfulness, at least as much as the technical (htags) debate. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-11-30 16:56 +, Ian Jackson wrote: > On to some questions it raises for me: > > > Optionally, "htags" can generate a dynamic index (which reduces disk > > space usage) but requires an http server setup to be able to serve the > > pages. In this scenario, you will also need to be able to execute CGI > > scripts as the symbol lookup is done when serving the http request (as > > opposed to pre-processed when using static pages). > > > > And this last bit (integration with system web server) is the > > functionality that had security concerns raised by Ron [etc.] > > So, to be clear, it is this functionality which is dropped in the > package that you and Wookey uploaded to experimental/delayed ? Said package is available as of today: https://buildd.debian.org/status/package.php?p=global&suite=experimental And that functionality was left in as it was a self-contained patch, pending determining whether in fact it remained useful/compatible or not. So you still get htmake and htconfig commands. However I have now done some checking, and no it doesn't work any more because it uses the btreeop command, which has been removed in current upstream, and the --action option to htags which is also gone. We are having a think about whether this code can be hacked about a bit to remain useful or if its approach is simply no longer relevant, given upstream changes. And I just said replying to Sam, there is a lot be said for not diverging significantly from upstream, because there is significant overhead in doing so. So this patch is currently likely to get dropped unless someone works out a way to make it work/be useful. > But AIUI this functionality remains: > > > In addition to the above mechanisms, upstream also provides "htags" > > which can be used to generate an HTML version of the index. "htags" > > uses the index created by "gtags" and the source tree as input and > > generates html files which allow you to navigate the source code in > > the browser. By default, htags generates static pages which means you > > can browse the code in a local browser without requiring a web server. > So the impact for a user of the existing functionality the regression > is not that their entire workflow is disrupted. > Rather (unless the software is improved) they have these choices: > > - Put up with pregenerated html indices. Is the only downside >of this that they use additional disk space, and presumably >cpu time to generate them ? Correct. And they can easily be symlinked from say /var/www/html/global/ to make them a) accessible from system webserver and b) conveniently listed. The static HTML is 7G for a kernel source tree. The dynamic version is 3.3G. (or 4.8G with the suggested '--suggest2' options) So there is a x2 space overhead. > - Run the htags server on a high-numbered port somehow. (Is there >some kind of simple scriptery provided, to do this?) There is an example in the NEWS file, which should go in the man page. It's trivial: cd HTML; python -m CGIHTTPServer or cd HTML; python3 -m http.server --cgi Then browse to http://localhost:8000/ > - If the machine is not really multi-user, tear down the security >boundary defending the webserver from their user account, and give >their user account access to the webserver cgi directory (or plumb >it in with symlinks). (Are there any instructions or scripts for >this?) (Also this assumes that the source code is not super >secret.) I've just started playing with this to see what can be done (bearing in mind the question of how much effort we should put into this sort of upstream divergence anyway). Simply symlinking /var/www/global/sourcetree to from gives you a convenient list of globalised htags to look through if they are static. The issue with dynamic htags (and the search functionality) is that by default your web server won't run .cgi scripts in arbitrary directories (for good reasons). I don't know if we can have a central .cgi that 'sources' the global.cgi or completion.cgi in the htags sourcetree/HTML dir and uses it, or if that's still not actually a good idea. Possibly something nifty with apache config scripts would work. Suggestions welcome. > I don't know much about this, but several of these choices seem likely > to be plausible choices for many if not most current users of htags. Right. I think the functionality upstream provides is fine. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Bug#841294: Overrule maintainer of "global" to package a new upstream version
Wookey writes: > On 2016-11-30 16:56 +, Ian Jackson wrote: > >> On to some questions it raises for me: >> >> > Optionally, "htags" can generate a dynamic index (which reduces disk >> > space usage) but requires an http server setup to be able to serve the >> > pages. In this scenario, you will also need to be able to execute CGI >> > scripts as the symbol lookup is done when serving the http request (as >> > opposed to pre-processed when using static pages). >> > >> > And this last bit (integration with system web server) is the >> > functionality that had security concerns raised by Ron [etc.] >> >> So, to be clear, it is this functionality which is dropped in the >> package that you and Wookey uploaded to experimental/delayed ? > > Said package is available as of today: > https://buildd.debian.org/status/package.php?p=global&suite=experimental > > And that functionality was left in as it was a self-contained patch, > pending determining whether in fact it remained useful/compatible or > not. So you still get htmake and htconfig commands. > > However I have now done some checking, and no it doesn't work any more > because it uses the btreeop command, which has been removed in current > upstream, and the --action option to htags which is also gone. > > We are having a think about whether this code can be hacked about a > bit to remain useful or if its approach is simply no longer relevant, > given upstream changes. And I just said replying to Sam, there is a > lot be said for not diverging significantly from upstream, because > there is significant overhead in doing so. So this patch is currently > likely to get dropped unless someone works out a way to make it > work/be useful. > >> But AIUI this functionality remains: >> >> > In addition to the above mechanisms, upstream also provides "htags" >> > which can be used to generate an HTML version of the index. "htags" >> > uses the index created by "gtags" and the source tree as input and >> > generates html files which allow you to navigate the source code in >> > the browser. By default, htags generates static pages which means you >> > can browse the code in a local browser without requiring a web server. > >> So the impact for a user of the existing functionality the regression >> is not that their entire workflow is disrupted. > >> Rather (unless the software is improved) they have these choices: >> >> - Put up with pregenerated html indices. Is the only downside >>of this that they use additional disk space, and presumably >>cpu time to generate them ? > > Correct. And they can easily be symlinked from say > /var/www/html/global/ to make them a) accessible from system > webserver and b) conveniently listed. The static HTML is 7G for a > kernel source tree. The dynamic version is 3.3G. (or 4.8G with the > suggested '--suggest2' options) So there is a x2 space overhead. > >> - Run the htags server on a high-numbered port somehow. (Is there >>some kind of simple scriptery provided, to do this?) > > There is an example in the NEWS file, which should go in the man page. It's > trivial: > > cd HTML; python -m CGIHTTPServer > or > cd HTML; python3 -m http.server --cgi > > Then browse to http://localhost:8000/ This functionality is also provided by htags-server(1), which is included in your package: https://www.mankier.com/1/htags-server [BTW htags-server/htags-server.1 should be added to debian/global.manpages] >> - If the machine is not really multi-user, tear down the security >>boundary defending the webserver from their user account, and give >>their user account access to the webserver cgi directory (or plumb >>it in with symlinks). (Are there any instructions or scripts for >>this?) (Also this assumes that the source code is not super >>secret.) > > I've just started playing with this to see what can be done (bearing > in mind the question of how much effort we should put into this sort > of upstream divergence anyway). > > Simply symlinking /var/www/global/sourcetree to > from > gives you a convenient list of globalised htags to look through if they are > static. > > The issue with dynamic htags (and the search functionality) is that by > default your web server won't run .cgi scripts in arbitrary > directories (for good reasons). I don't know if we can have a central > .cgi that 'sources' the global.cgi or completion.cgi in the htags > sourcetree/HTML dir and uses it, or if that's still not actually a > good idea. > > Possibly something nifty with apache config scripts would work. Suggestions > welcome. > >> I don't know much about this, but several of these choices seem likely >> to be plausible choices for many if not most current users of htags. > > Right. I think the functionality upstream provides is fine. It strikes me that users are likely to fall into one of two groups: Local access by users that do not wish to offer remote access and are not offering accounts on the machi
Re: Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-12-01 22:56 +0100, Philip Hands wrote: > Wookey writes: > > On 2016-11-30 16:56 +, Ian Jackson wrote: > > > >> > And this last bit (integration with system web server) is the > >> > functionality that had security concerns raised by Ron [etc.] > >> > >> So, to be clear, it is this functionality which is dropped in the > >> package that you and Wookey uploaded to experimental/delayed ? > > > > Said package is available as of today: > > https://buildd.debian.org/status/package.php?p=global&suite=experimental > > > > And that functionality was left in as it was a self-contained patch, > > pending determining whether in fact it remained useful/compatible or > > not. So you still get htmake and htconfig commands. > > > > However I have now done some checking, and no it doesn't work any more > > because it uses the btreeop command, which has been removed in current > > upstream, and the --action option to htags which is also gone. > >> - Run the htags server on a high-numbered port somehow. (Is there > >>some kind of simple scriptery provided, to do this?) > > > > There is an example in the NEWS file, which should go in the man page. It's > > trivial: > > > > cd HTML; python -m CGIHTTPServer > > or > > cd HTML; python3 -m http.server --cgi > > > > Then browse to http://localhost:8000/ > > This functionality is also provided by htags-server(1), which is > included in your package: > > https://www.mankier.com/1/htags-server > > [BTW htags-server/htags-server.1 should be added to debian/global.manpages] Well spotted. cheers for feedback. OK. Punit (and I) prepared an updated package with the above fixes, and htmake/htconfig dropped, so it's now pretty much a vanilla upstream package. Git repo is here: https://github.com/punitagrawal/global I've done a 5-day delayed NMU to experimental of 6.5.5-0.2. I'll put some more details in #816924 This is essentially a candidate for unstable/stretch, should 'putting v6 in unstable or stretch' be agreed-upon. So anyone who cares should check it out and file bugs. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature