On Mon, 31 Dec 2012 01:23:56 +0800 Thomas Goirand <zigo@debian.org> wrote: > Let's say you have a software that somehow, installs Debian. I use a lot of those and wrote one of them. > Then it might require the user to select which name of the > release to install. Or it could simply use the names which don't change: oldstable, stable, testing, unstable, experimental. That's what multistrap does. That's why the archive *has* names which don't change. We have names which have fixed content (lenny, squeeze, wheezy) and we have names which are always available (oldstable, stable, testing). Simple. An unblock request for this kind of change wouldn't be a problem, neither would a backport. It's not as if this is common. There aren't that many bootstrapping tools. There is no point having a name for release+2 because there will not be any content for that name until after the release of something which doesn't exist until after the current release. i.e. Jessie has no content currently. It won't have any content until after Wheezy is released. Talking about the name which comes after Jessie is pointless - nothing will exist for that name for years yet. Complete vapourware. > Currently, we knew about the name Jessie *after* the freeze, > meaning that we couldn't have written a software that would > debootstrap it without asking for an unblock. Just use testing and provide the name via backports - it would only be moving a symlink anyway. Or, as above, a trivial unblock. This kind of thing is not even a problem - base-files has to do it every release. > I made that point very clear multiple times .. wrongly. >, and I haven't been > the only one doing it. Yet, it hasn't been heard, and I never > receive any technical argumentation as to why we shouldn't > know the release names well in advance. I've not seen any valid technical reasons why we should know it beyond the start of the freeze. A name would be meaningless that far ahead. Just like the time-based freeze, we'd have people inventing policy / goals / content for the name which has no basis in anything and then getting annoyed when the actual content didn't fit their mistakes. > Maybe if there was > a greater number of DD insisting that this is necessary, this > could change. Please +1 to this if you agree. It's not necessary. > If there is a reason why we shouldn't know, please expose it > in this list. I, don't see any. I don't see technical reasons to invent a label for vapourware. Naming something which (at that point) has a non-existent feature set is a nonsense. The next stable release at least has a likely availability date which can be based on real figures (like the RC bug count) - release+1 is needed only once the freeze starts, release+2 is nowhere, it makes no sense to label it. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpRhJGC_vpZH.pgp
Description: PGP signature