Re: Knowing the release names in advance
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
Reply to: