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 <ron@debian.org> :
> > 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 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.
Ron
Reply to: