Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ron <ron@debian.org>]

On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote:
> Ron <ron@debian.org> 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 exactly what their complaint really is,
this part of the problem doesn't ever go away.

AIUI the main thing we are talking about a 'feature parity' problem
with, is something that itself has so few users and/or so little
interest that it's not even in Debian at all.  Which isn't to say
we should just ignore it - but if people are making a 'needs of the
many' argument, that's not irrelevant either.

Punit hasn't cared to maintain the global fork he did for that to
pull in any of the new changes from the last 12 upstream releases in
the last 2.5 years, so it seems that there is a definite limit to
what they actually need or care about on that front.  We just still
don't know what it actually is.  I did think it was a bit rich for
him to pull out the "if only you'd engaged ..." excuse, when I did
and he simply said he wasn't interested in answering that question.

But this too would be an evolving problem if upstream does later
add something interesting that someone else comes to depend on.
We can't really ever win with a plan that goes "we should fork this
from upstream, but be no different to upstream" - someone will
always be unhappy with something that way when 'upstream' decides
to be hostile to the fork.  Before that happened, maintaining the
extra things they didn't care about was easy for a very long time.

And that's all before we start on the new problems we'd create by
'silently' flip-flopping people's existing installs between
incompatible versions over a series of releases.


> 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.

All that said, I'm actually completely with you on this part of it
about this being something it would be very helpful to have a more
complete answer for.

I think the key difference is, I think the longer it takes to get
an answer to it that we can have some confidence in, the deeper
we are going to have crawled into a potentially endless maze,
without a map of the way forward, and the harder it's actually
going to be to try to get out of it again later.


So I think if we are going to sound people out on that, and I am
thinking that given the most recent developments upstream that
we should - then if we have consensus on that, we should look at
ways we can elicit that with more speed and certainty than popcon
and a shell game with multiple packages can tell us.


> 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.

If it sounds like I'm saying that, then either I wrote too much for
people to actually read, or wrote it badly (or more probably both!)
or this is a "when did you stop beating your wife?" question (which
I don't think it was intended as).

I'm absolutely not suggesting that "we should do nothing" is the
answer we should arrive at here.  But I do strongly believe that
"we should decide nothing" would be an equally bad, or even worse,
outcome too.

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
bigger and harder mess to clean up later than we already have to
deal with today.  And winds up people even more to drag this back
here again when I later need to decide what to do to clean it all
up again 'unilaterally', or refuse to fork again and package a
third version if upstream does something like this once more ...

It lets us "do something" to appease one complaint, without the
complainant putting in any effort, but it doesn't actually "solve"
or clearly answer anything.  It just adds even more technical debt
that will still need to be serviced eventually.

If putting off deciding that for as long as we already have hasn't
produced any helpful change, just people trying to ram through their
own zero-effort preference, then I don't hold out much hope that
putting it off even longer and sweeping some of the awkward bits
under a hastily thrown rug would improve that in any genuinely
useful way overall.

If people want this to move forward differently, one way or the other
(and I've certainly wanted that for a long time now), then we need to
actually make some hard and potentially equally unpopular decisions,
not avoid them.  And we need to do that by consensus if people don't
like the hard and unpopular decision I was forced into making several
years ago ...

Which even then, was never a decision to "do nothing".  It wasn't
me who decided to do nothing when I asked for an actual bug report
about the real problem and got told "no, Because New Upstream".


> 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.

On the contrary, it seems pretty clear to me that you are trying
to find a workable out to this in good faith.  And trying to keep
things moving along so they don't stagnate here too.

Though perhaps the question facing you is a little biased by "how
do I painlessly get this off the TC's plate without making things
worse" :)  But I'm likewise conscious of the subtleties there too.


> I really don't mind being treated as an ignoramus.

And that's likewise why I've so far held back on trying to drive this
in any particular direction myself, beyond just trying to keep it
somewhere near to 'still on the actual road'.  I have no problem with
thinking through all the merits of any option someone else brings to
the table and really hoped that somebody would see something that I'd
so far missed which would make the Right Answer clearer than it has
been for quite a while now.

So to cut back to the chase of your initial question above - with
the caveat that it's not yet what I'm fixated on 'intending' to do.
Here's what I think is possibly looking like the best option that
I can presently see from where we currently stand:


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).

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.


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.

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.

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.


I don't think it's a Great Answer.  And I don't hold out a lot of
hope that it won't get me hate mail and public slander from some
quarter or another, either or both of now and later.  But it gives
everyone an equally fair chance to put in the effort to improve what
bugs _them_ if they really do care - and most importantly it doesn't
just cut the can in two and kick both halves of it down the road to
litter the future.  We have a clear endgame where it's crushed and
recycled, and people have time to decide what they really want it to
be turned into next, and what effort they are prepared to put in to
help make that happen how they want it.

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.

  Cheers,
  Ron