On Tue, Nov 19, 2019 at 01:24:24PM -0800, Russ Allbery wrote:
> > I agree with Holger that it's probably better to leave the amount of
> > time undefined, and see what happens on a case by case basis.
> If we're going to expect there to be a transition period, I would prefer
> the time be defined, rather than left for case-by-case argument. If folks
> would prefer that we have zero delay (as soon as Policy standardizes a
> facility currently only supported by systemd, people can start using it
> immediately), that's viable from a Policy perspective. But it's hard (and
> not particularly fun) work on Policy to decide a reasonable non-zero delay
> on a case-by-case basis for every feature.
aaaaah! Now I see that this is ment differently than it was proposed. Me
blames the length of the third sentence in paragraph #9 in proposal D on
https://www.debian.org/vote/2019/vote_002
What I missed that this delay (of 6/12 month) is a delay for *-policy* about
describing/defining such a feature. I thought it ment to prohibit people
from using such new features.
Of course policy can lag behind 'artificially' (or on purpose), I mean,
fine, as long as new software can be uploaded and make use of such
features. (I really wouldnt want it to become impossible to just upload
the latest gnome release.)
> Ian's text says that we always introduce new feature descriptions and then
> pick something between six months and a year before people get to start
> using the new thing, and provides an easy out that in the case of
> disagreement we can just always pick a year and be done.
In practice you can and do this already. (By saying, this is too new,
policy describes status quo, etc).
> This may slow progress, but it removes a point of argument, which is very
> appealing.
I wonder why you dont prefer a fixed timeline then. 6 *or* 12 months.
--
cheers,
Holger
-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Attachment:
signature.asc
Description: PGP signature