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 <ron@debian.org> 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 bets and users between libav and ffmpeg ... We'd create more
awkward corners to get painted into, without really getting any closer
to an actual exit strategy. It might let us kick the can down the road
for making hard decisions today, but the piper will still have to be
paid in the end.
I think if we've already dragged more people in to consider the options
and try and form a consensus, my first preference would be to try and
form it around one of the options that leaves us with one package, and
a clear statement of why we picked what we did.
If that turns out to be a horrible mistake for some reason that we
didn't foresee, then we're going to be forced to revisit it anyway,
but at least we'd only have to do that _if_ compelling new information
comes to light. This seems like an option of last resort, so we should
keep it in our hat until it's clear we have no other option but to pull
it out, and weep the tears that come with that then.
Re popcon, I'm not sure how much of anything we can read from its
tealeaves for this one. Historically it's always been a very niche
package, with a very small number of users (and as a dev tool, it's
possibly on a lot of machines that don't report popcon stats too),
but for some reason, around 2009 the popcon reports for it exploded
with a (relatively) huge spike - and I don't think I've ever really
had a good explanation for that.
It wasn't like something new and earth-shattering got added to it
around that time. So either something that people actually did use
grew it as a dep, or someone told people at a conference to mass
install it, or something even weirder happened ...
But it's made it hard to know whether the decline since is just
the correction from that still flowing on, or people using a home
brew version, or people just migrating away from it entirely.
Since the package of global 6.2.12 that Punit has published and
maintained briefly is using the same packaging as the version in
the distro, I assume that anyone using it _is_ still being counted
in the (still steadily declining) popcon numbers anyway.
If I had to bet, I'd say something more popular pulled it in as a
dep, and we're still just seeing the tail of that fade away.
Cheers,
Ron
Reply to: