RE: [opensuse-project] Code names
Personally I'm not overly bothered about code names especially when it comes to having it as the main reference for a release. If it's used as a "pet name" then fine and I vote for the philosipher theme. I don't see why we should change the naming/versioning convention that has been used, it works very well so why try and fix it? There seems to be a tendency at the minute to jump on the band-wagon and do what the other buggers are doing, and to this I most definitely say NO! openSUSE is believe it or not a pioneer in many a space within the Linux community, and as such should forge its own way not play follow the herd (or should that be hurd? :-) ) So to re-iterate my stance, no to code names but if we go for a code name use it only as a pet name rather than the primary name. Thank you for listening, this has been a party politiccal broadcast for openSUSE. Regards, Andy -- Andrew Wafaa, openSUSE Member: FunkyPenguin -----Original Message----- From: Stephan Kulow Sent: 04/05/2009 10:13:44 Subject: [opensuse-project] Code names Hi, The code names I came up with the morning I posted the schedule, were not so great (check the forum to see a lot of people offended), so I would like to discuss it more generally: what is a good code name line? I actually love the philosopher's line as it gives openSUSE some kind of nice touch, but we'd still need some numbers associated with it. And as I watched a monthy python live DVD on the weekend, I came up with the idea to put the naming in better hands :) http://www.youtube.com/watch?v=92vV3QGagck - check 0:27 and 0:48 into the video to see 2 possible lists. (or if you like it as boring text, see http://en.wikipedia.org/wiki/The_Philosophers'_Football_Match) Or someone has an even better idea on how to solve this problem. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Andrew Wafaa wrote:
if we go for a code name use it only as a pet name rather than the primary name.
As far I understood it from the thread, people are suggesting to use code names as an extension to the (unchanged) numbering scheme. Example: 11.2 Amaranth 11.3 Burgundy 12.0 Crimson 12.1 Denim 12.2 Emerald 12.3 Fuchsia ... you get the idea ... :-) This might send a signal to the community that: * each openSUSE release is individual & unique * major changes do not happen only in x.0 releases * x.0 is not less mature than the others * x.1,2,3 are not just updates to the previous ones -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Allow me to argue against colors once more... On Tue, May 5, 2009 at 5:27 AM, Pavol Rusnak <prusnak@suse.cz> wrote:
Andrew Wafaa wrote:
if we go for a code name use it only as a pet name rather than the primary name.
As far I understood it from the thread, people are suggesting to use code names as an extension to the (unchanged) numbering scheme.
Example:
11.2 Amaranth 11.3 Burgundy 12.0 Crimson 12.1 Denim 12.2 Emerald 12.3 Fuchsia ... you get the idea ... :-)
This might send a signal to the community that:
* each openSUSE release is individual & unique
Then either the <Major_num>.<Minor_num> or the <name> seems redundant. Neither version number nor name tell me anyhting useful. Certainly not when I should give the release up and move on.
* major changes do not happen only in x.0 releases
Then why do we distinguish minor from major releases? If this really is the case I think many users, and not just novices, will be surprised. My impression is the convention that minor numbers indicate minor changes is so ingrained the project/community has a responsibility to stop using minor number changes to indicate major changes. Further more if 10.3->11.0 means no more than 10.1->10.2 then I'd also argue we are misleading 'novices' or even sophisticated outsiders. This suggests moving to a identity naming scheme that abandons incremental numbering is imperative.
* x.0 is not less mature than the others
Then why do we insist on using such numbering?
* x.1,2,3 are not just updates to the previous ones
Then really these minor number increments seem misleading given what I understand is the information 'average' users impute from these schemes. OK so I'm repeating myself.... Why is using the end-of-life YY-MM not: - informative about an important piece of information? - indicative of freshness? That is, it seems clear that 09-11 is an older release than 10-12 Granted there will be some explaining to do, but the benefits are: - You can still (if I understand openSUSE release/support policy correctly) tell which release is newer than the other. The color scheme does not allow this, so you would still need numbering. Numbering detail that is meaningless - all noise no signal. - You clearly indicate when a release has expired. Reading an email or forum thread about openSUSE 12-01 (or 12:01 to disambiguate the legacy numbering convention) in 2013 means I know this information is likely either built in to my current 'alive' release or irrelevant. Some issues are: - What should the YY and MM separator be? It probably should not be '.' to avoid confusion with the current numbering scheme. - Is it possible that end-of-life dates might leapfrog, e.g. 13-07 is older than 13-10. I understand that this might happen with Ubuntu's LTS release/support policy but I thought the openSUSE release/support policy ruled this scenario out... correct? No one has raised an objection to end-of-life YY-MM naming. I agree that it is a (very?) different idea. Is it really that stupid an idea, as to be axiomatically a bad idea :) Some reasons it is a bad (counter-productive) idea are.... Cheers Mark
-- Best Regards / S pozdravom,
Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 04 May 2009 07:15:52 pm Mark V wrote:
No one has raised an objection to end-of-life YY-MM naming. I agree that it is a (very?) different idea.
For instance Amaranth, release Nov 2009, support ends Nov 2011. It is a bit too long for the name, but I think it is worth to think how to make support term more visible, as number of problems can be avoided if users know from day one how long it will last, instead to leave that hidden in depth of wiki, and leave newcomers, that are used to other software vendors that quit support as soon as new release is out, to panic when some package is dropped out of openSUSE. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, May 5, 2009 at 3:14 PM, Rajko M. <rmatov101@charter.net> wrote:
On Monday 04 May 2009 07:15:52 pm Mark V wrote:
No one has raised an objection to end-of-life YY-MM naming. I agree that it is a (very?) different idea.
For instance Amaranth, release Nov 2009, support ends Nov 2011.
Ok so my posts are too obscure :) openSUSE 11-11 What is 'too long' about that? If the community wants a name, then adopt the Ubuntu date+name convention: openSUSE 11-11 (Asparagus) or openSUSE Asparagus (11-11) Unless openSUSE starts adopting end-of-life schedules that leapfrog each other, which I think Ubuntu does, then the most distant expiry date is the most recent release, so the release date information is redundant. It seems everyone accepts the Major.Minor numbering is misleading, does this mean it is going to be abandoned? Or will it continue and just a name be added?
It is a bit too long for the name, but I think it is worth to think how to make support term more visible, as number of problems can be avoided if users know from day one how long it will last, instead to leave that hidden in depth of wiki, and leave newcomers, that are used to other software vendors that quit support as soon as new release is out, to panic when some package is dropped out of openSUSE.
-- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 05 May 2009 07:51:30 pm Mark V wrote:
Unless openSUSE starts adopting end-of-life schedules that leapfrog each other, which I think Ubuntu does, then the most distant expiry date is the most recent release, so the release date information is redundant.
You see, that is why I proposed to have release schedule linked from Project Overview. So many people, including you, think that support ends with new release, which is plain wrong. The (open)SUSE is older then *buntu, and it has leapfrog end-of-life policy since ever. It is merely that *buntu copied SUSE end-of-life policy down to the length of term - 2 years for each release, since release date. See http://en.opensuse.org/Roadmap for release dates of currently supported versions. Currently you have 10.3, 11.0 and 11.1 alive and well, ie. all supported. Support for 10.3 will end in October 2009, shortly before 11.2 release. The 11.0 will run supported until June 2010, and 11.1 till December 2010. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, May 6, 2009 at 12:49 PM, Rajko M. <rmatov101@charter.net> wrote:
On Tuesday 05 May 2009 07:51:30 pm Mark V wrote:
Unless openSUSE starts adopting end-of-life schedules that leapfrog each other, which I think Ubuntu does, then the most distant expiry date is the most recent release, so the release date information is redundant.
You see, that is why I proposed to have release schedule linked from Project Overview. So many people, including you, think that support ends with new release, which is plain wrong.
No I don't. See the link to this page: http://en.opensuse.org/SUSE_Linux_Lifetime Which I provided before giving some examples. I did so precisely to indicate that was the understanding I was working from, and so that people would not not assume a different end-of-life policy (like Ubuntu's) and leap off on tangents..... I think it is hilarious that anyone would: - look at that page, - see the graphic I saw, - read the examples I gave and the description, - reach the conclusion you just did. I suspect step one was skipped ;) I think there is some confusion about terminology. Release lifespans can overlap, which openSUSE's do. That's fine and does not cause confusion in the name scheme I suggested - as I stated clearly perhaps too often ;) By 'leapfrog' I meant: An older release has a 'expiry' date that is after a newer release, i.e it starts from behind, passes over and ends-up ahead of the newer release expiry date - like you do in leapfrog :) Maybe leapfrog is played somewhere where to start from behind and jump on top of the obstacle and stops there.... hmm analogy this is getting weird so I'll stop now :) My understanding is that in openSUSE if release B is made after release A, then the expiry date of B will be after the expiry date of A. See the graphic on the lifetime page. It really was clear to me ;) Again as I've stated clearly several times, this is different to Ubuntu, where a LTS release expiry date _can_ leapfrog a release that occurs after the LTS release - anyway it is irrlevant _except_ that I did want to flag that if openSUSE feel they might ever consider such a end-of-life policy like Ubuntu's then the naming scheme suggested would _not_ 'work', for the reasons I (badly) explained. My fault for poor choice of terms and explanation.
The (open)SUSE is older then *buntu, and it has leapfrog end-of-life policy since ever. It is merely that *buntu copied SUSE end-of-life policy down to the length of term - 2 years for each release, since release date. See http://en.opensuse.org/Roadmap for release dates of currently supported versions.
Currently you have 10.3, 11.0 and 11.1 alive and well, ie. all supported. Support for 10.3 will end in October 2009, shortly before 11.2 release. The 11.0 will run supported until June 2010, and 11.1 till December 2010.
I'm not sure what made you think I suggested otherwise, anyway.... Cheers
-- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Mark V a écrit :
It seems everyone accepts the Major.Minor numbering is misleading, does this mean it is going to be abandoned? Or will it continue and just a name be added?
It should really be abandonned. We where always said that the name was choosen by the commercials and we had no mean to change this. If we *can* change it, go on. I see two things. * name: a name (word) makes it more friendly. It's valways better to say I use "Amaranth" than XX.YY * we have to use a numbered name, in addition to the color name, to fix a date. We can use the same sheme than Ubuntu use: starting date, but the idea to use the *ending* date seems to me new and very interesting. Ubuntu have LTS for Long Time Support, as it seems we can't have the same, making obvious the ending time is a very good idea. openSUSE have a very long support time, this could enphasise on this aspect. "openSUSE Amaranth good until 11.11" jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
jdd wrote:
We can use the same sheme than Ubuntu use: starting date, but the idea to use the *ending* date seems to me new and very interesting.
And when we use the ending date, the next release will be named 11.11, so we didn't go back from 11.1 to 9.11 (which is unfortunate also) and keep the increasing tendency: 11.0, 11.1, 11.11, 12.07, 13.03, 13.11, 14.07, 15.03, ... -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 06 May 2009 18:59:56 +0200, Pavol Rusnak wrote:
jdd wrote:
We can use the same sheme than Ubuntu use: starting date, but the idea to use the *ending* date seems to me new and very interesting.
And when we use the ending date, the next release will be named 11.11, so we didn't go back from 11.1 to 9.11 (which is unfortunate also) and keep the increasing tendency:
Problem is that end dates can change as development on the next release progresses. Wasn't there recently a shift from a 6 month development cycle to an 8 month development cycle? Suppose in 2 years it's decided to go to a 10-month development cycle? That shifts the end dates for the ones that are already out there. It seems to me that it's a better idea to go with something that isn't able to change rather than something that may. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Jim Henderson a écrit :
Suppose in 2 years it's decided to go to a 10-month development cycle? That shifts the end dates for the ones that are already out there.
why? I don't think so. duration is more or less 2 years jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 06 May 2009 19:53:53 +0200, jdd wrote:
Jim Henderson a écrit :
Suppose in 2 years it's decided to go to a 10-month development cycle? That shifts the end dates for the ones that are already out there.
why? I don't think so. duration is more or less 2 years
If the replacement product isn't ready when the previous one goes EOL, that creates a gap. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 5:06 AM, Jim Henderson <hendersj@gmail.com> wrote:
On Wed, 06 May 2009 19:53:53 +0200, jdd wrote:
Jim Henderson a écrit :
Suppose in 2 years it's decided to go to a 10-month development cycle? That shifts the end dates for the ones that are already out there.
why? I don't think so. duration is more or less 2 years
If the replacement product isn't ready when the previous one goes EOL, that creates a gap.
The proposal is to just use the EOL date when the final release is made. There has been no suggestion to /change/ how release dates are arrived at, nor how releases are made/scheduled. If what you suggest is correct - that openSUSE can have a gap where no release is 'alive' - then that problem exists regardless of the naming scheme you adopt. If anything this naming scheme has forced these 'problems' to be exposed - if they exist at all that is ;) I think product release/support policies are quite separate from naming schemes - the proposal is simply to bring some important information forward instead of it being buried on a 'lifetime' wiki page that very few look at. Cheers
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 07 May 2009 08:26:58 +1000, Mark V wrote:
I think product release/support policies are quite separate from naming schemes - the proposal is simply to bring some important information forward instead of it being buried on a 'lifetime' wiki page that very few look at.
I think this is a key statement, Mark - product release/support policies should be separate from naming schemes. Thus the release/support dates shouldn't really be used as part of the naming scheme. :-) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 8:50 AM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 07 May 2009 08:26:58 +1000, Mark V wrote:
I think product release/support policies are quite separate from naming schemes - the proposal is simply to bring some important information forward instead of it being buried on a 'lifetime' wiki page that very few look at.
I think this is a key statement, Mark - product release/support policies should be separate from naming schemes. Thus the release/support dates shouldn't really be used as part of the naming scheme. :-)
Perhaps I diagree with my self now :) see below. If the support date is really fixed then I'm willing to make the compromise to place that data front and center of casual users. One can even make that the support policy _should_ be the naming scheme. Example: Currently openSUSE has a policy of approx 2 year lifetime. Say that 'lifespan' becomes the rule of thumb. If circumstances change and the community decides it wants to reduce lifespans (to reduce the community's workload, or whatever reason).... now there is a problem. If the EOL date is built into the naming convention this is much less a problem, just relase with a shorter date and everyone will know. So I suppose one can actually make the case that the effects of the 'lifetime' policy (the expiry date) should be as visible as possible.... The potential problems (the known unknowns) of the end-of-life naming scheme so far are: 1) openSUSE introduces something like Ubuntus LTS where an older relase can outlive a newer release. 2) openSUSE end-of-life dates become adjustable after a final release is published Are those risks worth the benefit? Cheers
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 07 May 2009 09:07:44 +1000, Mark V wrote:
I think this is a key statement, Mark - product release/support policies should be separate from naming schemes. Thus the release/support dates shouldn't really be used as part of the naming scheme. :-)
Perhaps I diagree with my self now :) see below. If the support date is really fixed then I'm willing to make the compromise to place that data front and center of casual users.
Don't ya just hate when you start disagreeing with yourself? ;-)
One can even make that the support policy _should_ be the naming scheme.
Example: Currently openSUSE has a policy of approx 2 year lifetime. Say that 'lifespan' becomes the rule of thumb. If circumstances change and the community decides it wants to reduce lifespans (to reduce the community's workload, or whatever reason).... now there is a problem. If the EOL date is built into the naming convention this is much less a problem, just relase with a shorter date and everyone will know.
I'm beginning to wonder if we're talking at cross purposes here. If the release is out there already with an EOL date of 2010-12 (Dec 2010), the release is already out there, surely you wouldn't want to change it after release because a change in circumstances lead the community to reduce the lifespan and release more frequently? Changing the name after release is certain to be disasterous, and I'm sure you see the reasons for that, so I'm not sure I follow what you're saying....
So I suppose one can actually make the case that the effects of the 'lifetime' policy (the expiry date) should be as visible as possible....
The potential problems (the known unknowns) of the end-of-life naming scheme so far are: 1) openSUSE introduces something like Ubuntus LTS where an older relase can outlive a newer release. 2) openSUSE end-of-life dates become adjustable after a final release is published
Are those risks worth the benefit?
I know I've seen some say they'd like an LTS policy/strategy from openSUSE, kinda like Ubuntu's policy. That said, the obvious reply is "if you need LTS, then you should be looking at SLES or SLED rather than openSUSE". Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 12:21 PM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 07 May 2009 09:07:44 +1000, Mark V wrote:
I think this is a key statement, Mark - product release/support policies should be separate from naming schemes. Thus the release/support dates shouldn't really be used as part of the naming scheme. :-)
Perhaps I diagree with my self now :) see below. If the support date is really fixed then I'm willing to make the compromise to place that data front and center of casual users.
Don't ya just hate when you start disagreeing with yourself? ;-)
One can even make that the support policy _should_ be the naming scheme.
Example: Currently openSUSE has a policy of approx 2 year lifetime. Say that 'lifespan' becomes the rule of thumb. If circumstances change and the community decides it wants to reduce lifespans (to reduce the community's workload, or whatever reason).... now there is a problem. If the EOL date is built into the naming convention this is much less a problem, just relase with a shorter date and everyone will know.
I'm beginning to wonder if we're talking at cross purposes here.
If the release is out there already with an EOL date of 2010-12 (Dec 2010), the release is already out there, surely you wouldn't want to change it after release because a change in circumstances lead the community to reduce the lifespan and release more frequently?
I don't propose that. Never have. You raised an issue where I said that such a scenario would be concerning, and I explicitly asked if that was possible. One response was along the lines of: no guarantee, but it has never happened yet.
Changing the name after release is certain to be disasterous, and I'm sure you see the reasons for that, so I'm not sure I follow what you're saying....
No I'm saying right now people might reason figure: I setup my machine with latest, and I'm good for (roughly) two years for the release date. If in two years they grab the next release, and the (rough) lifespan rule-of-thumb has changed, you'll need to make sure they don't just assume it is still two years. Contrived I accept.
So I suppose one can actually make the case that the effects of the 'lifetime' policy (the expiry date) should be as visible as possible....
The potential problems (the known unknowns) of the end-of-life naming scheme so far are: 1) openSUSE introduces something like Ubuntus LTS where an older relase can outlive a newer release. 2) openSUSE end-of-life dates become adjustable after a final release is published
Are those risks worth the benefit?
I know I've seen some say they'd like an LTS policy/strategy from openSUSE, kinda like Ubuntu's policy. That said, the obvious reply is "if you need LTS, then you should be looking at SLES or SLED rather than openSUSE".
Agreed. As I've been at pains to point out from the outset: I'm assuming no LTS type releases will made. If they are introduced they'll break the following description given to newbies: "The release with the most distant EOL date is the most recent release" As I've said all along: this is one issue that would need to be considered carefully. For me, I don't see it as a deal breaker - the EOL info is too important. Cheers
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 07 May 2009 12:43:28 +1000, Mark V wrote:
community's workload, or whatever reason).... now there is a problem. If the EOL date is built into the naming convention this is much less a problem, just relase with a shorter date and everyone will know.
I'm beginning to wonder if we're talking at cross purposes here.
If the release is out there already with an EOL date of 2010-12 (Dec 2010), the release is already out there, surely you wouldn't want to change it after release because a change in circumstances lead the community to reduce the lifespan and release more frequently?
I don't propose that. Never have. You raised an issue where I said that such a scenario would be concerning, and I explicitly asked if that was possible. One response was along the lines of: no guarantee, but it has never happened yet.
Ah, so in fact we're debating something we're in violent agreement about. ;-)
Changing the name after release is certain to be disasterous, and I'm sure you see the reasons for that, so I'm not sure I follow what you're saying....
No I'm saying right now people might reason figure: I setup my machine with latest, and I'm good for (roughly) two years for the release date. If in two years they grab the next release, and the (rough) lifespan rule-of-thumb has changed, you'll need to make sure they don't just assume it is still two years. Contrived I accept.
And easily resolved, by including a note to that effect in the installer and on the website (I wonder if there are any stats about how many people pull their downloads through opensuse.org vs. just going to a mirror and downloading - guess that would be difficult-to-impossible to measure since "just going to a mirror" implies they don't go to the opensuse site.)
I know I've seen some say they'd like an LTS policy/strategy from openSUSE, kinda like Ubuntu's policy. That said, the obvious reply is "if you need LTS, then you should be looking at SLES or SLED rather than openSUSE".
Agreed. As I've been at pains to point out from the outset: I'm assuming no LTS type releases will made. If they are introduced they'll break the following description given to newbies: "The release with the most distant EOL date is the most recent release" As I've said all along: this is one issue that would need to be considered carefully. For me, I don't see it as a deal breaker - the EOL info is too important.
Agreed on all counts; the solution to the description problem would be to add a qualifier that states "excluding any release that is tagged as including long term support (LTS)". Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 1:06 PM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 07 May 2009 12:43:28 +1000, Mark V wrote:
And easily resolved, by including a note to that effect in the installer and on the website (I wonder if there are any stats about how many people pull their downloads through opensuse.org vs. just going to a mirror and downloading - guess that would be difficult-to-impossible to measure since "just going to a mirror" implies they don't go to the opensuse site.)
Hmm good point. If I understand things correctly there is a push to improve zypper dup. Even if zypper dup is never good enough to be a fully live update/upgrade path its improvement does raise the prospect that increasingly people will get their updated openSUSE without having to trawl web pages, download iso, burn iso and install from scratch. In cases where an OEM sells the computer with openSUSE installed you are not going to have them browsing the pages until they seek out the forums.... So more prominent EOL advertising on the web page will be good only for the first install, and only for some users - it doesn't address upgrades. Unless it remains the case that the official openSSUE upgrade path is intended to remain: "Backup your data, Download the iso and make an fresh install" Cheers
I know I've seen some say they'd like an LTS policy/strategy from openSUSE, kinda like Ubuntu's policy. That said, the obvious reply is "if you need LTS, then you should be looking at SLES or SLED rather than openSUSE".
Agreed. As I've been at pains to point out from the outset: I'm assuming no LTS type releases will made. If they are introduced they'll break the following description given to newbies: "The release with the most distant EOL date is the most recent release" As I've said all along: this is one issue that would need to be considered carefully. For me, I don't see it as a deal breaker - the EOL info is too important.
Agreed on all counts; the solution to the description problem would be to add a qualifier that states "excluding any release that is tagged as including long term support (LTS)".
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 3:43 AM, Jim Henderson <hendersj@gmail.com> wrote:
On Wed, 06 May 2009 18:59:56 +0200, Pavol Rusnak wrote:
jdd wrote:
We can use the same sheme than Ubuntu use: starting date, but the idea to use the *ending* date seems to me new and very interesting.
And when we use the ending date, the next release will be named 11.11, so we didn't go back from 11.1 to 9.11 (which is unfortunate also) and keep the increasing tendency:
Problem is that end dates can change as development on the next release progresses. Wasn't there recently a shift from a 6 month development cycle to an 8 month development cycle?
No problem. During development the release name can be used and only tagged with an EOL date during the release candidate phase (for example) - assuming you are correct in saying that the EOL date is as fluid during the dev cycle as you suggest it is.
Suppose in 2 years it's decided to go to a 10-month development cycle? That shifts the end dates for the ones that are already out there.
What! Now I am worried, is it really the case that the openSUSE end-of-life date changes once the 'final' is released? This seems nuts to me so would appreciate some unambiguous clarification.....
It seems to me that it's a better idea to go with something that isn't able to change rather than something that may.
Thanks for brining this to my attention. I had no idea that the EOL date could change once the final release was made. Cheers
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 07 May 2009 08:13:29 +1000, Mark V wrote:
Problem is that end dates can change as development on the next release progresses. Wasn't there recently a shift from a 6 month development cycle to an 8 month development cycle?
No problem. During development the release name can be used and only tagged with an EOL date during the release candidate phase (for example) - assuming you are correct in saying that the EOL date is as fluid during the dev cycle as you suggest it is.
My experience (not in OSS but in closed-source development) is that the cycles can and do vary. That's why a product like NetWare has an EOL that's 15 years in the future (was at one point for current releases).
Suppose in 2 years it's decided to go to a 10-month development cycle? That shifts the end dates for the ones that are already out there.
What! Now I am worried, is it really the case that the openSUSE end-of-life date changes once the 'final' is released? This seems nuts to me so would appreciate some unambiguous clarification.....
Bear in mind that I'm speaking from the perspective of working at a software company where EOL dates typically are dependent on the next product release.
It seems to me that it's a better idea to go with something that isn't able to change rather than something that may.
Thanks for brining this to my attention. I had no idea that the EOL date could change once the final release was made.
Now you're just being facetious. ;-) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 8:30 AM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 07 May 2009 08:13:29 +1000, Mark V wrote:
Problem is that end dates can change as development on the next release progresses. Wasn't there recently a shift from a 6 month development cycle to an 8 month development cycle?
No problem. During development the release name can be used and only tagged with an EOL date during the release candidate phase (for example) - assuming you are correct in saying that the EOL date is as fluid during the dev cycle as you suggest it is.
My experience (not in OSS but in closed-source development) is that the cycles can and do vary.
That's why a product like NetWare has an EOL that's 15 years in the future (was at one point for current releases).
Suppose in 2 years it's decided to go to a 10-month development cycle? That shifts the end dates for the ones that are already out there.
What! Now I am worried, is it really the case that the openSUSE end-of-life date changes once the 'final' is released? This seems nuts to me so would appreciate some unambiguous clarification.....
Bear in mind that I'm speaking from the perspective of working at a software company where EOL dates typically are dependent on the next product release.
It seems to me that it's a better idea to go with something that isn't able to change rather than something that may.
Thanks for brining this to my attention. I had no idea that the EOL date could change once the final release was made.
Now you're just being facetious. ;-)
No actually the first time I paid /any/ attention to what openSUSE does with their lifetime/expiry dates was when I wrote that email that had the lifetime wiki page linked to it. Up until now I've just adopted the policy I shouldn't be more than 1 release behind the latest - I just updated to 11.1 now that the 11.2 RC is out. I can quite believe that a distro reserves the right to 'kill off' a release if it proves too problematic to maintain - are there any openSUSE guarantees on this point? Cheers
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 07 May 2009 08:39:32 +1000, Mark V wrote:
Thanks for brining this to my attention. I had no idea that the EOL date could change once the final release was made.
Now you're just being facetious. ;-)
No actually the first time I paid /any/ attention to what openSUSE does with their lifetime/expiry dates was when I wrote that email that had the lifetime wiki page linked to it. Up until now I've just adopted the policy I shouldn't be more than 1 release behind the latest - I just updated to 11.1 now that the 11.2 RC is out.
I can quite believe that a distro reserves the right to 'kill off' a release if it proves too problematic to maintain - are there any openSUSE guarantees on this point?
Sorry if I misread your intent, Mark. :-) I don't think there are any guarantees. Maybe it will be clearer if I use a concrete example. For the sake of discussion, let's say the current plan is that 11.0 reaches end of support on December 31, 2009, and that 11.1 reaches end of support on December 31, 2010. Also for the sake of discussion, the release dates for 11.1 and 11.2 are December 31, 2009 and December 31, 2010, corresponding with the EOL dates for 11.0 and 11.1. The flow is thus that as 11.2 is released, 11.0 is placed at EOL. With me so far? Now for whatever reason, 11.2 isn't ready on December 31, 2010 and say, for the sake of discussion, that it's going to be at least 3 months before it releases. If you EOL 11.0 on December 31, 2010 anyways, then you are not following the stated goal to support "current release" and "previous release", because at that point only 11.1 is in support (as the "current release"). If 11.0's been "codenamed" as "2010-12" because that's the EOL date, the name loses its meaning when 11.2 slips and 11.0 stays in support for another 3 months (assuming that it would for the sake of continuing to support "previous release" per the stated policy of release support). So then do you change the codename for 11.0 to align with it's new anticipated EOL, or do you say "you know what, the codename doesn't really mean anything" after spending the time and energy to decide that it should mean something? Or do you violate the support policy and support only "current" release and not "previous release" because "next release" slipped due to unforseen circumstances? Or do you not slip 11.2 and release it even though it's not ready? That's why I see using EOL dates as a codename for the releases as a bad thing. I hope that clarifies my thoughts on the matter enough. :-) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 9:01 AM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 07 May 2009 08:39:32 +1000, Mark V wrote:
Thanks for brining this to my attention. I had no idea that the EOL date could change once the final release was made.
Now you're just being facetious. ;-)
No actually the first time I paid /any/ attention to what openSUSE does with their lifetime/expiry dates was when I wrote that email that had the lifetime wiki page linked to it. Up until now I've just adopted the policy I shouldn't be more than 1 release behind the latest - I just updated to 11.1 now that the 11.2 RC is out.
I can quite believe that a distro reserves the right to 'kill off' a release if it proves too problematic to maintain - are there any openSUSE guarantees on this point?
Sorry if I misread your intent, Mark. :-)
I don't think there are any guarantees.
Maybe it will be clearer if I use a concrete example.
For the sake of discussion, let's say the current plan is that 11.0 reaches end of support on December 31, 2009, and that 11.1 reaches end of support on December 31, 2010.
Also for the sake of discussion, the release dates for 11.1 and 11.2 are December 31, 2009 and December 31, 2010, corresponding with the EOL dates for 11.0 and 11.1.
The flow is thus that as 11.2 is released, 11.0 is placed at EOL.
With me so far?
Now for whatever reason, 11.2 isn't ready on December 31, 2010 and say, for the sake of discussion, that it's going to be at least 3 months before it releases.
If you EOL 11.0 on December 31, 2010 anyways, then you are not following the stated goal to support "current release" and "previous release", because at that point only 11.1 is in support (as the "current release").
If 11.0's been "codenamed" as "2010-12" because that's the EOL date, the name loses its meaning when 11.2 slips and 11.0 stays in support for another 3 months (assuming that it would for the sake of continuing to support "previous release" per the stated policy of release support).
So then do you change the codename for 11.0 to align with it's new anticipated EOL, or do you say "you know what, the codename doesn't really mean anything" after spending the time and energy to decide that it should mean something? Or do you violate the support policy and support only "current" release and not "previous release" because "next release" slipped due to unforseen circumstances?
Or do you not slip 11.2 and release it even though it's not ready?
That's why I see using EOL dates as a codename for the releases as a bad thing. I hope that clarifies my thoughts on the matter enough. :-)
Yes it is possible to construct a release policy or development shcedule where a EOL naming scheme is fragile. Looking at the lifetime wiki page it seems OpenSUSE share your concern and try to plan a release date while /two/ relases are alive. Your point about the EOL date slipping as developments slips is valid but can be accommodated: - During development a planned release is coded named: <color> - On the actual release date the release is named: openSUSE <EOL> That last point was facetious ;) I doubt you could name a release only on it's release date, URI names, mirrors etc need to be set up... But you probably could hold off 'naming' the release until the RC or Beta phases, etc where the risk of slipping is possible smaller. Cheers
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 07 May 2009 09:24:10 +1000, Mark V wrote:
Yes it is possible to construct a release policy or development shcedule where a EOL naming scheme is fragile.
Well, I don't know that it's "constructing" the policy or schedule that way, but sometimes in projects stuff happens that prevents a date from being missed. :-)
Looking at the lifetime wiki page it seems OpenSUSE share your concern and try to plan a release date while /two/ relases are alive.
Yeah, that was my understanding as well. :-)
I doubt you could name a release only on it's release date, URI names, mirrors etc need to be set up... But you probably could hold off 'naming' the release until the RC or Beta phases, etc where the risk of slipping is possible smaller.
Arguably, just because you give the release a name doesn't mean that the current URI names/mirrors/etc have to use it. They could still use the fixed numeric values - that's pretty well established anyways, so messing with them would most likely create confusion. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 06 May 2009 05:39:32 pm Mark V wrote:
I can quite believe that a distro reserves the right to 'kill off' a release if it proves too problematic to maintain - are there any openSUSE guarantees on this point?
The only hard guarantee is past experience, where SUSE never declared release non-maintainable before scheduled EOL. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 2:59 AM, Pavol Rusnak <prusnak@suse.cz> wrote:
jdd wrote:
We can use the same sheme than Ubuntu use: starting date, but the idea to use the *ending* date seems to me new and very interesting.
And when we use the ending date, the next release will be named 11.11, so we didn't go back from 11.1 to 9.11 (which is unfortunate also) and keep the increasing tendency:
11.0, 11.1, 11.11, 12.07, 13.03, 13.11, 14.07, 15.03, ...
Hence my discussion of the '-' delimiter... 11.0, 11.1, 11-11, 12-07, 13-03, 13-11, 14-07, 15-03 Not perfect but better than '.' We could, until the change over becomes widely known, understood and adopted, adopt a convention of indicating end-of-life, such openSUSE Asparagus (a.k.a EL:11-11) but that does get a little too long for me. Cheers
-- Best Regards / S pozdravom,
Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 2009-05-07 at 08:07 +1000, Mark V wrote:
openSUSE Asparagus (a.k.a EL:11-11)
but that does get a little too long for me.
Yeah, this is getting a little confusing. Seriously, we should have *one* name for the product (at least publicly). If we want to use "openSUSE Foobar 11.2" inside the project to describe a release, that's cool, but when it comes to publicly, let's stick with one name: either openSUSE 11.2 or openSUSE Foobar (of course those names are just examples). -- Kevin "Yeaux" Dupuy openSUSE Member www.twitter.com/KevinDupuy -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 06 May 2009 06:02:46 pm Kevin "Yeaux" Dupuy wrote:
On Thu, 2009-05-07 at 08:07 +1000, Mark V wrote:
openSUSE Asparagus (a.k.a EL:11-11)
but that does get a little too long for me.
Yeah, this is getting a little confusing. Seriously, we should have *one* name for the product (at least publicly). If we want to use "openSUSE Foobar 11.2" inside the project to describe a release, that's cool, but when it comes to publicly, let's stick with one name: either openSUSE 11.2 or openSUSE Foobar (of course those names are just examples).
Agree on this. Naming must be easy to swallow. Loading release dates, kernel versions, size of DVD, and what, not will force people to cut name to reasonable size, or give some digestible name, and that will produce confusion as there will be as many shortcuts, as people using them. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 9:21 AM, Rajko M. <rmatov101@charter.net> wrote:
On Wednesday 06 May 2009 06:02:46 pm Kevin "Yeaux" Dupuy wrote:
On Thu, 2009-05-07 at 08:07 +1000, Mark V wrote:
openSUSE Asparagus (a.k.a EL:11-11)
but that does get a little too long for me.
Yeah, this is getting a little confusing. Seriously, we should have *one* name for the product (at least publicly). If we want to use "openSUSE Foobar 11.2" inside the project to describe a release, that's cool, but when it comes to publicly, let's stick with one name: either openSUSE 11.2 or openSUSE Foobar (of course those names are just examples).
Agree on this. Naming must be easy to swallow.
Agreed. Would the following be simple enough? Code name <color> during development phases: openSUSE Asparagus Release name <EOL> at/near the release date: openSUSE 11-11 Cheers
Loading release dates, kernel versions, size of DVD, and what, not will force people to cut name to reasonable size, or give some digestible name, and that will produce confusion as there will be as many shortcuts, as people using them.
-- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 06 May 2009 06:27:34 pm Mark V wrote:
On Thu, May 7, 2009 at 9:21 AM, Rajko M. <rmatov101@charter.net> wrote: ...
Naming must be easy to swallow.
Agreed. Would the following be simple enough? Code name <color> during development phases: openSUSE Asparagus Release name <EOL> at/near the release date: openSUSE 11-11
No, it wouldn't. I want exact date + first and last kernel versions + + + :-) C'mon. It's a release name, not short history of release and it's properties. It is something that is unique and easy to remember when you want to refer to, when you want to put it in boot menu. When I ask somebody which release, now I need only number. I already know it is openSUSE and if I want to know more I will go to wiki and see details. Fact that Project Overview should contain more links to relevant information is obvious, but you can't fit all that is relevant for all people in release name. Some would like to know what is kernel version, other Firefox, third will want to know something else. For every openSUSE user you will find something different as important. So lets stick with colors, or city names without extensions. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 06 May 2009 20:10:26 -0500, Rajko M. wrote:
So lets stick with colors, or city names without extensions.
This is similar to what RedHat does (or used to do). It was pretty straight forward: "Enigma" was a known release, and the name could be used interchangeably for the version number. On the console, the prompt was something like: RedHat 7.2 (Enigma) Login: So for us, why not: openSUSE 11.2 (Asparagus) Login: And something similar on the default *dm login screens? No fuss, no muss, and it doesn't overcomplicate things, which I think we might be doing here. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 06 May 2009 09:25:57 pm Jim Henderson wrote:
and it doesn't overcomplicate things, which I think we might be doing here.
As usual :-) (was that Mr. Godwin's point) -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 06 May 2009 22:06:16 -0500, Rajko M. wrote:
On Wednesday 06 May 2009 09:25:57 pm Jim Henderson wrote:
and it doesn't overcomplicate things, which I think we might be doing here.
As usual :-) (was that Mr. Godwin's point)
LOL, finally, some humour! ;-) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 1:06 PM, Rajko M. <rmatov101@charter.net> wrote:
On Wednesday 06 May 2009 09:25:57 pm Jim Henderson wrote:
and it doesn't overcomplicate things, which I think we might be doing here.
As usual :-) (was that Mr. Godwin's point)
It's been fun and I've had more than my fair say. I'm going to have to leave this thread now. I suppose my main points are : 1) EOL is important - make it prominent. 2) EOL matters most for the more casual users - make it unavoidable knowledge no matter how they update/upgrade. 3) Tagging releases with their EOL adds no complexity and is sytematic. 4) Tagging releases with their EOL could constrain future release EOL policy, but in ways that are trivial or at least, IMO, worth the price. Cheers
-- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 12:25 PM, Jim Henderson <hendersj@gmail.com> wrote:
On Wed, 06 May 2009 20:10:26 -0500, Rajko M. wrote:
So lets stick with colors, or city names without extensions.
This is similar to what RedHat does (or used to do).
It was pretty straight forward: "Enigma" was a known release, and the name could be used interchangeably for the version number.
On the console, the prompt was something like:
RedHat 7.2 (Enigma) Login:
So for us, why not:
openSUSE 11.2 (Asparagus) Login:
And something similar on the default *dm login screens?
No fuss, no muss, and it doesn't overcomplicate things, which I think we might be doing here.
I thought the decision was to drop Major.Minor numbering because they are misleading? May have misunderstood. Cheers
Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 07 May 2009 13:07:00 +1000, Mark V wrote:
No fuss, no muss, and it doesn't overcomplicate things, which I think we might be doing here.
I thought the decision was to drop Major.Minor numbering because they are misleading? May have misunderstood.
I don't think there was a decision to drop Major.Minor versioning, just to add the use of "friendly names". But I wasn't reading this list back when the proposed name (which started the entire discussion) was discussed, so I could be wrong. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, May 7, 2009 at 11:10 AM, Rajko M. <rmatov101@charter.net> wrote:
On Wednesday 06 May 2009 06:27:34 pm Mark V wrote:
On Thu, May 7, 2009 at 9:21 AM, Rajko M. <rmatov101@charter.net> wrote: ...
Naming must be easy to swallow.
Agreed. Would the following be simple enough? Code name <color> during development phases: openSUSE Asparagus Release name <EOL> at/near the release date: openSUSE 11-11
No, it wouldn't. I want exact date + first and last kernel versions + + + :-)
C'mon.
It's a release name, not short history of release and it's properties. It is something that is unique and easy to remember when you want to refer to, when you want to put it in boot menu.
When I ask somebody which release, now I need only number. I already know it is openSUSE and if I want to know more I will go to wiki and see details.
Fact that Project Overview should contain more links to relevant information is obvious, but you can't fit all that is relevant for all people in release name. Some would like to know what is kernel version, other Firefox, third will want to know something else. For every openSUSE user you will find something different as important.
So lets stick with colors, or city names without extensions.
Sure, I'm not proposing EOL as an extension but as the only tag (a compromise where it decomes the extension is better than buring the EOL again). Anyway. Let us be clear: color/city/food/philosopher is cute but meaningless/uninformative. What is so difficult about (systematic) YY-MM but not difficult about random color/city/food/philosopher? I keep asking these direct questions but getting convoluted indirect answers. So far, after some wrestling, I think we've tagged to known 'issues' neither of which apply to openSUSE as it currently stands. There also has been no one directly address how likely they feel the current situation will change - which would be a good reason to avoid tagging a release with its EOL. Perhaps they recognize that doing so throws open the question of whats the point of having an EOL date if it is so fragile/confusing/convoluted you can't tag a release with it :) (Ubuntu people would have that conversation and might say, well the extra time you get by having occasional LTS releases is worth the randomness/confusion) There seemed to be a reasonable objection: what if things go pear-shaped during dev period and the this means the EOL must get pushed back? If you feel that strongly to have a name during dev them use a temp one, cilty/color/ etc. that is as meaningless/uninformative as the dev phase is temporary :) Personally, I don't see any point in naming during the dev phases beyond the generic 'Factory'. When things are firm enough to be named then name it <EOL>. Now even a casual user knows something critical (the EOL date) that is otherwise buried. This way junk-information/noise such as color/city/food/philosopher never enters a description when someone asks you: "What openSUSE release are you using?" Hypothetical, repeat hypothetical, forum exchange: Req: What release are you using? Res: YY-MM Req: Hmm, that end date is 3 months away, it'll be much less hassel for you to upgrade, where this problem doesn't happen, than solve this problem now and still have to upgrade in a month or two. Res: Ahh thanks I didn't know that was the end-of-life date. I though they were picking significant anniversary dates of different philosopher's city of birth - I had noticed Linux people seem to enjoy using irrelevant/obscure names. Req: No prob's. If you can live with things as they are, wait two weeks and the YY-MM3 release will be out it seems quite good, and you'll be good until YY-MM3. If you can't wait use the YY-MM2 release and this issue should be fixed there too. Res: OK thanks. Some parts of this distro seem very disciplined and well thought through, others seem very random compared to.... Cheers
-- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 2009-05-07 at 09:27 +1000, Mark V wrote:
Agreed. Would the following be simple enough? Code name <color> during development phases: openSUSE Asparagus Release name <EOL> at/near the release date: openSUSE 11-11
That's fine, but now I have to raise a question that should have been obvious to me before: what's the point of a separate development codename? Why call the same product two different things? If it's "openSUSE 11.2" then let's use that in releases and inside the project, or if it's gonna be "openSUSE <Codename> then let's use that in development and release date. Do we really need to make things more complicated than they need to be? -- Kevin "Yeaux" Dupuy openSUSE Member www.twitter.com/KevinDupuy -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/5/7 Kevin "Yeaux" Dupuy <kevin.dupuy@opensuse.org>:
That's fine, but now I have to raise a question that should have been obvious to me before: what's the point of a separate development codename? Why call the same product two different things? If it's "openSUSE 11.2" then let's use that in releases and inside the project, or if it's gonna be "openSUSE <Codename> then let's use that in development and release date.
Do we really need to make things more complicated than they need to be? -- Kevin "Yeaux" Dupuy openSUSE Member www.twitter.com/KevinDupuy
I agree. We don't have already a codename for the development version? "Factory"? Regards, Luiz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 5 May 2009, Mark V wrote:
Why is using the end-of-life YY-MM not: - informative about an important piece of information?
Because - it is just _one_ piece of information, and far from the most important for developers nor users during the development cycle nor during and for quite a while after the release, and - it is subject to change. Others already brought examples, but this being a community project, what happens if a group of volunteers steps up to provide security updates past the point Novell has been sponsoring historically? That may well happen a year after the release. And because - changing names between development cycle and production, especially close to the actual release as some have suggested, is confusing (= bad for marketing) and risky (= bad for quality). Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Product Management T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Andrew Wafaa wrote:
Personally I'm not overly bothered about code names especially when it comes to having it as the main reference for a release. If it's used as a "pet name" then fine and I vote for the philosipher theme.
Ditto.
So to re-iterate my stance, no to code names but if we go for a code name use it only as a pet name rather than the primary name.
Ditto. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (10)
-
Andrew Wafaa -
Gerald Pfeifer -
jdd -
Jim Henderson -
Kevin "Yeaux" Dupuy -
Luiz Fernando Ranghetti -
Mark V -
Pavol Rusnak -
Per Jessen -
Rajko M.