On 12/31/2012 08:03 PM, Neil Williams wrote: > > 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.
Then we release a new stable, and these names have a different meaning ... Not a great idea. Even less a good one when many servers are involved, and you need to update them all so that it continues to bootstrap the same flavor you used to setup, which can be the case when these servers are setting-up VMs. > 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. Wouldn't it be more simple to just choose a name and we would never ever have to talk about it again, and never ever have to process any of such unblocks? Do you have numbers available of how many software reference the names of the releases? I'd be very curious to know. What I saw in codesearch.debian.net when searching for both Wheezy and Jessie made me think otherwise (eg: there was a lot more "wheezy" occurrences than "jessie", leading to potential problems when Wheezy is out and Jessie starts to exist). What about the social aspect of being able to actually talk and write about Jessie+1 with its name, rather than just "Jessie+1"? > 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. You still haven't made the (technical) point as to why it's a bad thing to know the names of release+2 in advance. Nobody ever did. I just had as an answer "but it doesn't exist yet so it doesn't make sense", which isn't a satisfying answer, neither socially or technically. > Just use testing and provide the name via backports What if I want to display to the user the names of releases, and not just "testing"? After all, it's my choice to make, no? What if I don't want to use backports (and I really don't, if I can avoid it)? > 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. I just gave you one, and you've dismissed it completely saying that we can unblock packages after the freeze. Also, is it meaningless when I type "jessie+1"? A lot of people does us this. I see it in many threads. Especially as we get closer to the freeze. That alone, IMO, should be enough reason so that we have a name to talk about, and not just <whatever>+1 which I believe is the meaningless word. I don't understand how you can just dismiss this (social) fact. > I don't see technical reasons to invent a label for vapourware. Wikipedia has the following definition for vapourware: Vaporware is a term in the computer industry that describes a product, typically computer hardware or software, that is announced to the general public but is never actually released nor officially cancelled." I don't claim that wikipedia is always right, but I do agree with such definition. So unless you are claiming Debian will die before Jessie+1 that's not matching what a vapourware is. Jessie+1 will really exist, and be released, at some point. So it's quite a natural thing to talk about it, and sometimes to reference it in some piece of software (funny thing: I now notice the added / removed "u" depending if you are American or English. :) ) Perhaps you see a better match with this: "The term also generally applies to a product that is announced months or years before its release, and for which public development details are lacking." But I don't see why not knowing yet what feature/details will be in, is a blocker to decide the name in advance. That is, IMO, unrelated. > Naming something which (at that point) has a non-existent feature set is a > nonsense. The above sentence doesn't help me to understand what's wrong with my reasoning. You're not making any technical nor social point here, IMHO. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e1edaa.7010...@debian.org