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 <ron@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 shigio@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 shigio@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
Reply to: