Bug#841294: Overrule maintainer of "global" to package a new upstream version
Hi,
apologies for the delay in responding here.
]] Ron
[…]
> 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).
This sounds pretty reasonable to me.
> 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.
This all sounds reasonable to me.
> 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.
Ok.
> 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.
Probably makes sense to add a warning anybody running htags now that
«this will be dropped in the next release», 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.
Yup.
[...]
> 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.
I think this sounds quite reasonable, all in all. It gets us a newer
version (albeit not for stretch, but I see the points about changing
that so close to the freeze), it gives users some warning about htags
going away (and if that's a huge problem, we can adjust course as we
learn more).
Vincent, would this be acceptable to you?
The rest of the committee: what do you think? Is this an ok way
through?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: