On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote: > Ron <[email protected]> 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
