On Sat, Oct 22, 2016 at 05:41:54PM +0200, Vincent Bernat wrote: > ❦ 22 octobre 2016 14:44 +1030, Ron <r...@debian.org> : > > > 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 their distro but do not read the NEWS file > of every package they have installed -- and confuse people who must still > work on machines of both earlier and later releases for some time to come. Though I agree with it completely as a general discussion, I think that the -S option should be changed. We may ignore the people who don't read NEWS file. > 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. That would be the same upstream who insisted chmod 777 was an improved new option? For all we know from what you've told us about your problem with ggtags so far, it's possible it could be fixed with a two line patch to the version of global we currently ship. Or that it's actually evidence of a real bug in ggtags itself. People thinking that compatibility is "Not something that I can really find useful" is exactly why we have these sort of intractable problems in the first place. It's not a solution to them. Sometimes there really is no other option. But not nearly as often as someone just not caring creates an otherwise easily avoidable problem. > > 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. I want a solution that's not worse than the disease, and is backed by some sort of real evidence and logic rather than personal preference heresay if it's just going to push problems to some other set of users. That's basically the only constraint I have on whatever it might be. 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 ... And despite the assertions that Punit made when you discussed forcing this via the TC, I don't see any evidence at all in that repo that he'd done anything about the troublesome CGI (or in his earlier emails that he even understood exactly what would be involved with doing that). The only changes he actually made was a bunch of churn to do things like change the package format ... He seemed to imply that he couldn't remember what he'd done anyway when accepting your prompting and offer to escalate this here. In #131 I expressed the concern that what he was promising to do to 'fix' this was just code for "This will never happen". And we can see with the benefit of time now that none of it really ever did. I'm not saying I didn't think he thought he was promising that in good faith. But I've seen enough "pump and dump" package updates over the years to have a fair idea of what promises that won't be kept in practice tend to look like. People overpromise to scratch their immediate itch, and once it's scratched, move on to overpromise somewhere else to get a different itch scratched. It is just human nature, I'm not condemning him for it, but we ignore it at our own peril. The people who recognise it in themselves are few and precious, and invariably can only do that because they too have been guilty of it at some point or another. So ... with that said, some notable things apparently _have_ changed in the 12 odd upstream releases since we discussed all this previously and I'd looked at it in detail. It turns out that upstream has actually broken compatibility with the CGI stuff Yet Again. And has now removed any possibility of doing that securely with a static audited script installed to a protected system cgi directory at all in the current releases. Which does make the idea of simply killing htags completely, at least until someone does make it sane again, seem like a less unreasonable thing to do. But what I said at the top of this mail does still apply. We can't just flip this on a whim, or all we'll do is potentially make a different group of people start screaming about Terrible Injustice being inflicted upon them instead. And "the people who screamed this time agreed they were more important than you" is no consolation to that. 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. There is no one answer that will satisfy everyone here, so changing who is unsatisfied needs a stronger justification than "I did what Vincent wanted because he nagged the hardest, for the longest, and would be wasting more of my time repeating myself over and over than you are if I didn't do that". Because that's sort of the opposite of a technically sound decision. Which is why I think that you (and anyone else with something useful to add here), needs to clearly lay out in detail what _real problems_ you are having, with some analysis of the options that could fix them, sufficiently, even if not ideally. That gives us much firmer ground to stand on to justify whatever we do next, and to stick to doing that, than if all you give us is a preconceived solution that minimises the effort you need to put in, and which is itself clearly not optimal for everyone either. I'm pretty sure that if you can present us something along those lines which is strong enough that people on the TC wouldn't be embarrassed to endorse it as a well considered decision, and the best we can do given the circumstances, that you'll have already convinced me of that too and we can just get on with having enough future certainty to actually do it. Cheers, Ron
