Hi,
As you may have noticed, we have yet to publish a roadmap for 11.2. The reason is simple: There are a lot of moving pieces at the moment, and we don't want to commit to a schedule we can't keep -- or keep a schedule that doesn't fit the project's long-term needs.
To give us something to plan around, we would like to propose a fixed release schedule. As a six-month release schedule is not something we consider feasible to maintain high-quality standards, we are proposing a fixed eight- month schedule. We have spent a considerable amount of time asking if we should go with a September release for 11.2 and then adopt an eight-month release schedule, or begin with an eight-month release schedule right away. And we came to the conclusion that it's best to adopt the eight-month schedule right away.
A six-month release cycle is interesting because you "only" have to find two months in the year for a release. Eight months makes it slightly more complicated, as you have a rotating schedule, and lose a month in the summer and winter for holidays.
So, what we're proposing is this -- the next openSUSE release in November 2009, with the next releases in July 2010, March 2011, and so forth:
November 2009: "Fichte" 11.2 July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
This gives us a single release in 2009 and 2010, and two releases in 2011. The version names and numbers may change, of course.
Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that. We are planning a strict four-week release candidate (RC) phase.
This means that the last chance to change _anything_ but really urgent fixes would be the check-in deadline of RC1, which would be released in week 41 in 2009. The schedule would leave us with whatever software we have at that point. For example, we'll miss KDE 4.5 for 11.3 or the spring version of GNOME for 12.0. If missing these releases is a problem, let's discuss this _now_.
Of course, this doesn't mean we can't publish supported or unsupported addons or updated live CDs with the respective desktops or similar software: We just need people willing to do it.
Why such a late release date? Releasing 11.2 in November has some advantages over releasing in September: - We don't rely on contributions during the summer months that much. - We can easily integrate GNOME 2.28. - We are more likely to have working drivers for hardware released in early summer is higher. (This is a weak advantage since the summer release of Intel's graphic chips didn't work out with a December release either.) - We simply have more time for everything.
The features we have in mind for 11.2 center around these top features: * Newer and better software, including: - KDE 4.3 - GNOME 2.28, - Linux kernel 2.6.30 or higher * Ext4 - possibly even as the default filesystem. * Provide YaST Web interface for easier remote adminstration. * Netbook support - Offer USB images - possibly even with deployment tool if someone writes it. - Include free drivers necessary for the netbook support. * Officially support live updates - we need way more people to use factory and report problems though. * Quicker, Faster and more Colourful
OK, I better stop here. This is already a pretty long mail - looking forward to your feedback. The last time we discussed schedules, the feedback was very good - and got us thinking quite a long time. ;)
Greetings, Stephan
Stephan Kulow a écrit :
OK, I better stop here. This is already a pretty long mail
very good overall... and back to the 8 month we should never had let out, and good named openSUSE :-)
jdd
Torsdag 05 marts 2009 12:00:46 skrev Stephan Kulow:
So, what we're proposing is this -- the next openSUSE release in November 2009, with the next releases in July 2010, March 2011, and so forth:
November 2009: "Fichte" 11.2 July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
Sounds good to me. And the SLE people are ok with having to plan around a fixed openSUSE schedule, and not the other way around? ;-)
Am Donnerstag 05 März 2009 schrieb Martin Schlander:
Torsdag 05 marts 2009 12:00:46 skrev Stephan Kulow:
So, what we're proposing is this -- the next openSUSE release in November 2009, with the next releases in July 2010, March 2011, and so forth:
November 2009: "Fichte" 11.2 July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
Sounds good to me. And the SLE people are ok with having to plan around a fixed openSUSE schedule, and not the other way around? ;-)
We never willingly planned openSUSE around SLE, but we always try to schedule products in a time slot where there is no other product. And so far SLE had an advantage with the longer release cycle. So I'm trying to be first this time in blocking dates ;)
Greetings, Stephan
On Thu, 5 Mar 2009, Martin Schlander wrote:
Sounds good to me. And the SLE people are ok with having to plan around a fixed openSUSE schedule, and not the other way around? ;-)
I have said it before, and I'll say it again: let's not worry about SLE here, let's focus on openSUSE.
Let's face it: some aspects of how we (= the openSUSE community) have been handling releases have serious room for improvement. On the tools front we have made good progress. Testing and development cycle have a lot of potential still. The proposal Coolo shared is one idea to improve on that front.
Gerald
On Mon, 2009-03-09 at 01:24 +0100, Gerald Pfeifer wrote:
Let's face it: some aspects of how we (= the openSUSE community) have been handling releases have serious room for improvement. On the tools front we have made good progress. Testing and development cycle have a lot of potential still. The proposal Coolo shared is one idea to improve on that front.
Yes i agree we should focus on testing for 11.2 (some of those steps are already done now just provide usuable beta releases and i think we are almost done in this area). My concern is only about this 8 month release cycle (which i agree because we don't have to deliver buggy stuff in the usual 6 month release like fedora and ubuntu) is the fact we have to sometimes let the latest GNOME or KDE out. Other distros are usually shipping those in time and desktops are usually the "face" of the distros. One good rule of OSS, release good and release often because it will be good marketing.
Luis
One good rule of OSS, release good and release often because it will be good marketing.
I think it is quite proven that six months are too short to deliver a good quality distribution (make a comparison between 11.0 and 11.1, for example). Plus six months put too much pressure on the developers, with the obvious consequences.
Eight months seem a good deal to me. Releasing every six is really "for geeks and cutting edge people", which is not what I would consider openSUSE goal. We should try to reach something different, geeks already have fedora, with all the cutting edge stuff of this world. OpenSUSE, for it's nature of user-friendly distribution, should target home and desktop users, experienced and not, that don't want to mess with the details of their system and want something that works. As long as this condition is satisfied, I don't think users will be disappointed for two months of difference. OpenSUSE is not far from this goal, all what we need is a plan to make consistently nice releases, and it seems to me what Coolo proposed goes in that direction.
About marketing, well, I think there are better strategies to market openSUSE than just releasing often. Make your users happy and they will spread the word faster than announcing releases everywhere on the net, and you'll also gain on another front: they will stay and eventually help. With an eight month release cycle we don't risk, if this is your doubt, to have an obsolete distribution while others have an updated one. The build service can easily fill the gap for the major applications, without requiring users to upgrade so often (another advantage to market).
Regards, Alberto
Alberto Passalacqua a écrit :
I think it is quite proven that six months are too short to deliver a good quality distribution
this don't make sense - others do and the quality is good.
With smaller time, the changes are also smaller, so are the bugs.
The problem is elsewhere, for example the lifetime of a *boxed* edition have to be longer than 6 months. Using 8 month is choice, not obligation (and I don't say it's a bad choice)
jdd
Il giorno lun, 09/03/2009 alle 08.49 +0100, jdd ha scritto:
Alberto Passalacqua a écrit :
I think it is quite proven that six months are too short to deliver a good quality distribution
this don't make sense - others do and the quality is good.
It makes perfectly sense. Look at 11.0, with an 8 month release cycle, and look at 11.1 with a six month release cycle. The difference shines.
What others do doesn't count at all in these decisions. We need something that works for THIS community and openSUSE/Novell developers.
With smaller time, the changes are also smaller, so are the bugs.
Not really true. With shorter release cycles, there is just less time to test the release. What you're talking about is another problem: the respect of deadlines to submit and add features.
The problem is elsewhere, for example the lifetime of a *boxed* edition have to be longer than 6 months. Using 8 month is choice, not obligation (and I don't say it's a bad choice)
The boxed version is supported two years, not six months, so the problem does not exist. Eight months is a good balance between releasing early and trying to provide a good distribution.
Regards, A.
Alberto Passalacqua a écrit :
With smaller time, the changes are also smaller, so are the bugs.
Not really true. With shorter release cycles, there is just less time to test the release. What you're talking about is another problem: the respect of deadlines to submit and add features.
of course not. Changes add with time, and pretty fast
The problem is elsewhere, for example the lifetime of a *boxed* edition have to be longer than 6 months. Using 8 month is choice, not obligation (and I don't say it's a bad choice)
The boxed version is supported two years, not six months, so the problem does not exist. Eight months is a good balance between releasing early and trying to provide a good distribution.
nothing to do with what I said. I don't speak about support but about creation of new dvds.
openSUSE can't have new dvd with updates because of the boxed set that can't be changed. With no box you can include all the fixes at any time. I speak of fixes for the current release, not of a new release.
If there where not box, we could have now a 11.1.2 dvd. No other change needed. Exactly what you get with an install then 4/5 hours of dl right now, mostly for people without dl capacity, and convenience.
jdd
On Mon, Mar 09, 2009 at 05:07:16PM +0100, jdd wrote:
Alberto Passalacqua a écrit :
With smaller time, the changes are also smaller, so are the bugs.
Not really true. With shorter release cycles, there is just less time to test the release. What you're talking about is another problem: the respect of deadlines to submit and add features.
of course not. Changes add with time, and pretty fast
The problem is elsewhere, for example the lifetime of a *boxed* edition have to be longer than 6 months. Using 8 month is choice, not obligation (and I don't say it's a bad choice)
The boxed version is supported two years, not six months, so the problem does not exist. Eight months is a good balance between releasing early and trying to provide a good distribution.
nothing to do with what I said. I don't speak about support but about creation of new dvds.
openSUSE can't have new dvd with updates because of the boxed set that can't be changed. With no box you can include all the fixes at any time. I speak of fixes for the current release, not of a new release.
If there where not box, we could have now a 11.1.2 dvd. No other change needed. Exactly what you get with an install then 4/5 hours of dl right now, mostly for people without dl capacity, and convenience.
The box is just a paper cover.
The process of making high quality installable DVD media is still as difficult without it.
Ciao, Marcus
If there where not box, we could have now a 11.1.2 dvd. No other change needed. Exactly what you get with an install then 4/5 hours of dl right now, mostly for people without dl capacity, and convenience.
As Marcus said, creating these DVD would take time and effort, and has no relation with the box. We could in theory have respins even if there is a boxed version.
The point is that respins are not worth the time and the effort if not in extreme cases (see 10.1). You talk about 4-5 hours to install patches, but that's the case only if you install months after release and repeat the installation many times. If you are in the second case (installing many times or on many systems), you can always download the RPM's and build a local repository or simply put them in a directory and use that directory as repository.
Doing what you suggest, in a certain sense, save you (user) some time, but reduces the time people working on openSUSE work on the release, so it doesn't help, in the end, to have better quality distributions.
Regards, A.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2009-03-09 at 23:16 -0500, Alberto Passalacqua wrote:
If there where not box, we could have now a 11.1.2 dvd. No other change needed. Exactly what you get with an install then 4/5 hours of dl right now, mostly for people without dl capacity, and convenience.
As Marcus said, creating these DVD would take time and effort, and has no relation with the box. We could in theory have respins even if there is a boxed version.
The point is that respins are not worth the time and the effort if not in extreme cases (see 10.1). You talk about 4-5 hours to install patches, but that's the case only if you install months after release and repeat the installation many times. If you are in the second case
Well, you have to install 11.1 about now to get enough updates to make it usable. Kernel crashed here till the last, recent update.
If making a second release is too much effort, how about releasing an add-on CD/DVD disk with the updates? Maybe including it with the box.
- -- Cheers, Carlos E. R.
Well, you have to install 11.1 about now to get enough updates to make it usable. Kernel crashed here till the last, recent update.
If making a second release is too much effort, how about releasing an add-on CD/DVD disk with the updates? Maybe including it with the box.
How can this simplify things? They should change the existing boxes and repackage them.
Instead of spending time in making _more_ releases, the idea of the new release scheme is to try to make good releases, so that problems like yours will be reduced.
The release early, release often approach is a smart translation of "release buggy stuff and let your user find the problems". With a eight month cycle we probably can limit this a bit more, if we all try pre-release versions and report problems timely. So, let's give it a try. But if the two additional months are wasted in making respins and test them, well, we are back to square one.
Regards, A.
Alberto Passalacqua a écrit :
How can this simplify things? They should change the existing boxes and repackage them.
Thats why we should drop the box.
Only use dvd, press enough for a quarterly delivery, drop it in an envelope when necessary. Box in only usefull in shelves, at dealer store, not by mail.
Instead of spending time in making _more_ releases, the idea of the new release scheme is to try to make good releases, so that problems like yours will be reduced.
You know that's not possible. New major stuff come always at the last time. We should use very early feature freeze and we can't
So, let's give it a
try. But if the two additional months are wasted in making respins and test them, well, we are back to square one.
we already had a 8 month delay at the beginning, two years ago. and I don't say we don't have to use 8 month, only package the updates and send them with the initial dvd (if respin dvd is too hard)
As I see it, most people here see the problem when they do, as I do, often demos. the update stage is much too long (even with highband network). But most of the world *don't have* large bandwith.
I manage LDP mirrors, many countries still have lowband network even in universities
jdd
Il giorno mar, 10/03/2009 alle 17.43 +0100, jdd ha scritto:
You know that's not possible. New major stuff come always at the last time. We should use very early feature freeze and we can't
It is perfectly possible. Take a decision -> respect it and give your users something that works. If they don't understand that they don't need the last x.xx.xx.xx version, well, it is frankly their problem, and there is Build Service for them.
So, let's give it a
try. But if the two additional months are wasted in making respins and test them, well, we are back to square one.
we already had a 8 month delay at the beginning, two years ago. and I don't say we don't have to use 8 month, only package the updates and send them with the initial dvd (if respin dvd is too hard)
OK. This can be done by the community without any help from the developers. The repository is out there, and all what you need to do is to create an image of it. Of course there is the cost of hosting it, and also the time to keep that up to date.
As I see it, most people here see the problem when they do, as I do, often demos. the update stage is much too long (even with highband network). But most of the world *don't have* large bandwith.
I manage LDP mirrors, many countries still have lowband network even in universities
I think a big part of the problem is fixed by delta patches, which significantly reduce the amount of data you download. If you do frequent demos, you can create an ad hoc product with kiwi, including the most updated release, I think.
My point however, is pretty simple: making respins, DVD and stuff like that is a big effort, is going to help a limited number of users, and it requires someone to do it. If you know someone that is not a Novell developer that does that on a regular basis and a host, it might be another story. But from what I see, you are asking Novell to take care of it, and it doesn't seem feasible to me. I would sincerely prefer to see them concentrated on the new releases, so that our community can grow and these problem will be fixed hopefully by the higher number of contributors.
Regards, Alberto
On Tuesday 10 March 2009 04:14:34 am Carlos E. R. wrote:
On Monday, 2009-03-09 at 23:16 -0500, Alberto Passalacqua wrote:
If there where not box, we could have now a 11.1.2 dvd. No other change needed. Exactly what you get with an install then 4/5 hours of dl right now, mostly for people without dl capacity, and convenience.
As Marcus said, creating these DVD would take time and effort, and has no relation with the box. We could in theory have respins even if there is a boxed version.
The point is that respins are not worth the time and the effort if not in extreme cases (see 10.1). You talk about 4-5 hours to install patches, but that's the case only if you install months after release and repeat the installation many times. If you are in the second case
Well, you have to install 11.1 about now to get enough updates to make it usable. Kernel crashed here till the last, recent update.
If making a second release is too much effort, how about releasing an add-on CD/DVD disk with the updates? Maybe including it with the box.
The add-on update DVD is not a problem. Handpick last updates, download and burn. It is work, but it's not everyday work.
I was talking about respin, just because there is a base that GM was created from. Replace packages with updated versions and run kiwi again. If everyone has to do that there will be no guaranteed quality, and individual mistakes will be attributed to openSUSE, not individual that made them.
On Tuesday 10 March 2009, Rajko M. wrote:
On Tuesday 10 March 2009 04:14:34 am Carlos E. R. wrote:
On Monday, 2009-03-09 at 23:16 -0500, Alberto Passalacqua wrote:
If there where not box, we could have now a 11.1.2 dvd. No other change needed. Exactly what you get with an install then 4/5 hours of dl right now, mostly for people without dl capacity, and convenience.
As Marcus said, creating these DVD would take time and effort, and has no relation with the box. We could in theory have respins even if there is a boxed version.
The point is that respins are not worth the time and the effort if not in extreme cases (see 10.1). You talk about 4-5 hours to install patches, but that's the case only if you install months after release and repeat the installation many times. If you are in the second case
Well, you have to install 11.1 about now to get enough updates to make it usable. Kernel crashed here till the last, recent update.
If making a second release is too much effort, how about releasing an add-on CD/DVD disk with the updates? Maybe including it with the box.
The add-on update DVD is not a problem. Handpick last updates, download and burn. It is work, but it's not everyday work.
I won't work for the retail box. The retail box is produced once with the GM and then sold. Adding a CD with updates would require a new production run or to open boxes on stock an add the CD. Both is much to expensive.
M
I was talking about respin, just because there is a base that GM was created from. Replace packages with updated versions and run kiwi again. If everyone has to do that there will be no guaranteed quality, and individual mistakes will be attributed to openSUSE, not individual that made them.
-- Regards, Rajko
Michael Loeffler a écrit :
I won't work for the retail box. The retail box is produced once with the GM and then sold. Adding a CD with updates would require a new production run or to open boxes on stock an add the CD. Both is much to expensive.
yes, it's why a soft envelope is better (filled only at mailing time)
jdd
On Wednesday 11 March 2009 05:55:24 am jdd wrote:
Michael Loeffler a écrit :
I won't work for the retail box. The retail box is produced once with the GM and then sold. Adding a CD with updates would require a new production run or to open boxes on stock an add the CD. Both is much to expensive.
yes, it's why a soft envelope is better (filled only at mailing time)
Just as little guys making copies of Linux distros do. Nothing fancy.
Maybe openSUSE should create non-profit organization that will take care of advertising, delivering media, printed stuff, from number of locations around the world. It has many advantages to volunteering, like, central place to order, low delivery cost, somewhat lower operational costs.
Rajko M. a écrit :
yes, it's why a soft envelope is better (filled only at mailing time)
Just as little guys making copies of Linux distros do. Nothing fancy.
not really.
Burned dvd are not reliable. I burn now approx 100 a month with 5% failure (failure=read failure, many disks read on some boxes but not all - video dvd)
so we must have profesionally made dvd, that ned at least 500/1000 copies, so why I proposed quarterly version (also to have the nice print on the dvd :-)
Th idea of using approved non profit organisation is good. I' myself chairman of such a group, the main problem we have is to make us known. With the help of openSUSE, we could spread such dvd copies.
this could be acheived by a redirector like download.opensuse.org giving the next LUG adress to the user
jdd
On Wednesday 11 March 2009 09:50:12 am jdd wrote:
Rajko M. a écrit :
yes, it's why a soft envelope is better (filled only at mailing time)
Just as little guys making copies of Linux distros do. Nothing fancy.
not really.
Burned dvd are not reliable. I burn now approx 100 a month with 5% failure (failure=read failure, many disks read on some boxes but not all - video dvd)
I had in mind company that I worked for. They have proprietary software as part of product and only a portion of that is printed, the rest is burned per order.
so we must have profesionally made dvd, that ned at least 500/1000 copies, so why I proposed quarterly version (also to have the nice print on the dvd :-)
... or professionally burned. There is difference.
Th idea of using approved non profit organisation is good. I' myself chairman of such a group, the main problem we have is to make us known. With the help of openSUSE, we could spread such dvd copies.
Just to point out that non-profit doesn't mean that it doesn't have finances. It's only that bottom line doesn't include profit. Here that means that you can look for many sources of support that are not available to companies, or informal groups like openSUSE.
this could be acheived by a redirector like download.opensuse.org giving the next LUG adress to the user
Sure.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2009-03-11 at 15:50 +0100, jdd wrote:
Just as little guys making copies of Linux distros do. Nothing fancy.
not really.
Burned dvd are not reliable. I burn now approx 100 a month with 5% failure (failure=read failure, many disks read on some boxes but not all - video dvd)
Did you look here?
http://www.digitalfaq.com/media/dvdmedia.htm
it is a list of which dvd media is reliable and which isn't.
- -- Cheers, Carlos E. R.
Carlos E. R. a écrit :
it is a list of which dvd media is reliable and which isn't.
I tried many media types, with no difference. This time all the faulty dvd come from the same writer, probably at end of life (I use three writers on three computers)
jdd
On Wednesday 11 March 2009 22:22:49 jdd wrote:
Carlos E. R. a écrit :
it is a list of which dvd media is reliable and which isn't.
I tried many media types, with no difference. This time all the faulty dvd come from the same writer, probably at end of life (I use three writers on three computers)
jdd
I would confirm this: the quality of burnt media not only depends on the disc but also on the combination of burner *and* reader. This is not reliable enough.
Yet, I wonder why we still cling to DVDs at all: why not put a bootable 4GB USB pen drive in the folder/box? Or a bigger drive which also contains the ISO? DVDs or CDs should be delivered only via download, imho.
Daniel Mader a écrit :
Yet, I wonder why we still cling to DVDs at all: why not put a bootable 4GB USB pen drive in the folder/box? Or a bigger drive which also contains the ISO? DVDs or CDs should be delivered only via download, imho.
now it's yet much more expensive than dvd, but it's a good idea, as it could sell a little more priced. Mandriva sells a sub key.
However the "bootable" part is unreliable. some mother boards don't boot correctly
jdd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Mader wrote:
On Wednesday 11 March 2009 22:22:49 jdd wrote:
Carlos E. R. a écrit :
it is a list of which dvd media is reliable and which isn't.
I tried many media types, with no difference. This time all the faulty dvd come from the same writer, probably at end of life (I use three writers on three computers)
jdd
I would confirm this: the quality of burnt media not only depends on the disc but also on the combination of burner *and* reader. This is not reliable enough.
That's right, but there are media that are generally good, and others that are generally bad.
Yet, I wonder why we still cling to DVDs at all: why not put a bootable 4GB USB pen drive in the folder/box? Or a bigger drive which also contains the ISO? DVDs or CDs should be delivered only via download, imho.
For backups or for the distro release?
For the distro, a flash disk is still more expensive, they are slower to write than a dvd burner (and much, much slower, and more expensive, than a DVD "printer"), many computers out there will not boot from a dvd...
For backups, a flash disk is of unknown reliability, ie, we don't know how many years the data survives (I mean, I, Joe User do not know), they are slow to write, and more expensive than a DVD. However, they can be reused.
For backups, you can use real hard-disks via USB. That's just what I do.
Distributing the DVD media is handy, but perhaps they should do it without a box. Dunno. I wonder how difficult would be to do a re-release the same way it is done for factory :-?
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-ex-factory)
On Wednesday 11 March 2009 05:29:28 am Michael Loeffler wrote:
The add-on update DVD is not a problem. Handpick last updates, download and burn. It is work, but it's not everyday work.
I won't work for the retail box. The retail box is produced once with the GM and then sold. Adding a CD with updates would require a new production run or to open boxes on stock an add the CD. Both is much to expensive.
I meant that creating own DVD is not a problem. :-) It was just clumsy reuse of Carlos words.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-03-10 at 10:47 -0500, Rajko M. wrote:
If making a second release is too much effort, how about releasing an add-on CD/DVD disk with the updates? Maybe including it with the box.
The add-on update DVD is not a problem. Handpick last updates, download and burn. It is work, but it's not everyday work.
Well, I'm not sure what exactly to download (it must have a certain structure, I suppose), but is it possible to tell the install disk to use another disk (another dvd or HD on USB) for the updates, instead of the network?
I was talking about respin, just because there is a base that GM was created from. Replace packages with updated versions and run kiwi again. If everyone has to do that there will be no guaranteed quality, and individual mistakes will be attributed to openSUSE, not individual that made them.
If the process to make the factory dvd is automated, couldn't also be automated the creation of a DVD for the current distribution with all packages updated to whatever is available in the update tree?
- -- Cheers, Carlos E. R.
On Wednesday 11 March 2009 09:19:00 am Carlos E. R. wrote:
On Tuesday, 2009-03-10 at 10:47 -0500, Rajko M. wrote:
If making a second release is too much effort, how about releasing an add-on CD/DVD disk with the updates? Maybe including it with the box.
The add-on update DVD is not a problem. Handpick last updates, download and burn. It is work, but it's not everyday work.
Well, I'm not sure what exactly to download (it must have a certain structure, I suppose), but is it possible to tell the install disk to use another disk (another dvd or HD on USB) for the updates, instead of the network?
You can tell YaST what to use. I have in mind update after installation. It is safe way. For that you have to pick latest rpm of each package, and point YaST or zypper to that directory.
I was talking about respin, just because there is a base that GM was created from. Replace packages with updated versions and run kiwi again. If everyone has to do that there will be no guaranteed quality, and individual mistakes will be attributed to openSUSE, not individual that made them.
If the process to make the factory dvd is automated, couldn't also be automated the creation of a DVD for the current distribution with all packages updated to whatever is available in the update tree?
I guess that is possible to replace original rpms with those in update tree and rerun whatever software is used to create DVD.
I haven't tried that, but it seems that is good time to learn how to do it.
On Monday 09 March 2009 11:16:33 pm Alberto Passalacqua wrote:
If there where not box, we could have now a 11.1.2 dvd. No other change needed. Exactly what you get with an install then 4/5 hours of dl right now, mostly for people without dl capacity, and convenience.
As Marcus said, creating these DVD would take time and effort, and has no relation with the box. We could in theory have respins even if there is a boxed version.
The point is that respins are not worth the time and the effort if not in extreme cases (see 10.1). You talk about 4-5 hours to install patches, but that's the case only if you install months after release and repeat the installation many times. If you are in the second case (installing many times or on many systems), you can always download the RPM's and build a local repository or simply put them in a directory and use that directory as repository.
Doing what you suggest, in a certain sense, save you (user) some time, but reduces the time people working on openSUSE work on the release, so it doesn't help, in the end, to have better quality distributions.
For me and most of guys on the list respin is wast of time. We don't need it.
To make clear, nobody talked about respin boxed version. Sincerely, if we don't make better 11.2 GM than previous few, it is better to have respin. During development you make, for instance, few Alphas, Betas and RCs, how much more effort requires respin.
Another fact is that total of updates is more than 1 GB for 11.1 i586. I tried to handpick just last versions or rpms for 11.1 i586, came to 300+ MB, and quit. Scroll bar was still in upper half, so total could be over 600 MB. I don't need all packages, but if I go to install on someone's computer I better have all updates. That makes 1.2 GB of updates for 32 & 64 bit.
Thanks to problems with EXA I was in position to install 11.0, that has total of 3+ GB for i586 alone. If it is roughly proportional to 11.1 it is 3+ GB that I should have with me to make sure that prospective Linux enthusiast get all updates, fast.
Besides, respin would be chance for marketing guys to bring attention to openSUSE: "From openSUSE workshop newest release! It installs smooth like a silk. The cutting edge 11.1 got polish ..." It would be better to have the same words applicable to GM, but upstream doesn't stop, so there will be updates no matter how good is GM.
IMHO, the respin would target people that don't want to experiment. It is completely different public than the current one.
The other way is to make sure that basic functions, installation, boot and X work flawlessly on major platforms, or give clear advice what release to use for best experience. Not working application is not a big deal (mostly), but workarounds to make system boot, is a problem (not for me, and most of folk here).
The other way is to make sure that basic functions, installation, boot and X work flawlessly on major platforms, or give clear advice what release to use for best experience. Not working application is not a big deal (mostly), but workarounds to make system boot, is a problem (not for me, and most of folk here).
... and auto-update & config (or is that included in installation).
Latest drivers not necessary, nor drivers for all hardware, provided it works for all current (at time of release) mainstream hardware.
I support this - if it doesn't work at this basic level "out of the box" then it's broken and a different "version" must be shipped in future.
David
On Monday 09 March 2009 04:22:16 Luis Medinas wrote:
On Mon, 2009-03-09 at 01:24 +0100, Gerald Pfeifer wrote:
Let's face it: some aspects of how we (= the openSUSE community) have been handling releases have serious room for improvement. On the tools front we have made good progress. Testing and development cycle have a lot of potential still. The proposal Coolo shared is one idea to improve on that front.
Yes i agree we should focus on testing for 11.2 (some of those steps are already done now just provide usuable beta releases and i think we are almost done in this area). My concern is only about this 8 month release cycle (which i agree because we don't have to deliver buggy stuff in the usual 6 month release like fedora and ubuntu) is the fact we have to sometimes let the latest GNOME or KDE out. Other distros are usually shipping those in time and desktops are usually the "face" of the distros. One good rule of OSS, release good and release often because it will be good marketing.
It's still better than right now ;) - and I suggest, let's give this a try for some releases and if it really does not work in the long run, we revisit it...
Andreas
Le lundi 09 mars 2009, à 09:45 +0100, Andreas Jaeger a écrit :
On Monday 09 March 2009 04:22:16 Luis Medinas wrote:
On Mon, 2009-03-09 at 01:24 +0100, Gerald Pfeifer wrote:
Let's face it: some aspects of how we (= the openSUSE community) have been handling releases have serious room for improvement. On the tools front we have made good progress. Testing and development cycle have a lot of potential still. The proposal Coolo shared is one idea to improve on that front.
Yes i agree we should focus on testing for 11.2 (some of those steps are already done now just provide usuable beta releases and i think we are almost done in this area). My concern is only about this 8 month release cycle (which i agree because we don't have to deliver buggy stuff in the usual 6 month release like fedora and ubuntu) is the fact we have to sometimes let the latest GNOME or KDE out. Other distros are usually shipping those in time and desktops are usually the "face" of the distros. One good rule of OSS, release good and release often because it will be good marketing.
It's still better than right now ;) - and I suggest, let's give this a try for some releases and if it really does not work in the long run, we revisit it...
Nod. I'm not that worried about missing one GNOME or KDE release. We can always offer it in a build service project, or create a re-spinned Live CD if we want (and I think we will want to do this :-)).
I mean, we're already doing the work to backport GNOME 2.26 to 11.1, eg. This would be the same thing (admittedly, a bit more difficult, since we'll want to keep the new patches in GNOME:Factory in GNOME:Unstable, but it's worth trying it at least once)
Vincent
2009/3/9 Vincent Untz vuntz@opensuse.org:
Le lundi 09 mars 2009, à 09:45 +0100, Andreas Jaeger a écrit :
On Monday 09 March 2009 04:22:16 Luis Medinas wrote:
On Mon, 2009-03-09 at 01:24 +0100, Gerald Pfeifer wrote:
Let's face it: some aspects of how we (= the openSUSE community) have been handling releases have serious room for improvement. On the tools front we have made good progress. Testing and development cycle have a lot of potential still. The proposal Coolo shared is one idea to improve on that front.
Yes i agree we should focus on testing for 11.2 (some of those steps are already done now just provide usuable beta releases and i think we are almost done in this area). My concern is only about this 8 month release cycle (which i agree because we don't have to deliver buggy stuff in the usual 6 month release like fedora and ubuntu) is the fact we have to sometimes let the latest GNOME or KDE out. Other distros are usually shipping those in time and desktops are usually the "face" of the distros. One good rule of OSS, release good and release often because it will be good marketing.
It's still better than right now ;) - and I suggest, let's give this a try for some releases and if it really does not work in the long run, we revisit it...
Nod. I'm not that worried about missing one GNOME or KDE release. We can always offer it in a build service project, or create a re-spinned Live CD if we want (and I think we will want to do this :-)).
I mean, we're already doing the work to backport GNOME 2.26 to 11.1, eg. This would be the same thing (admittedly, a bit more difficult, since we'll want to keep the new patches in GNOME:Factory in GNOME:Unstable, but it's worth trying it at least once)
All avoided if we have a general repository with backports that "normal" users can subscribe to. Just move from Factory/backports when the SW is considered stable. It can even generate positive press as "openSUSE relases KDE xxx or Gnome yyy for immediate update".
Factory or 10 different repositories will probably not do the trick. Factory is to bleeding, and an everyday user will not manage X number of aditional repositories.
Birger
Le lundi 09 mars 2009, à 14:34 +0100, Birger Kollstrand a écrit :
2009/3/9 Vincent Untz vuntz@opensuse.org:
I mean, we're already doing the work to backport GNOME 2.26 to 11.1, eg. This would be the same thing (admittedly, a bit more difficult, since we'll want to keep the new patches in GNOME:Factory in GNOME:Unstable, but it's worth trying it at least once)
All avoided if we have a general repository with backports that "normal" users can subscribe to. Just move from Factory/backports when the SW is considered stable. It can even generate positive press as "openSUSE relases KDE xxx or Gnome yyy for immediate update".
Sure, we're going to do that work in GNOME:STABLE, and the KDE team has been doing that for quite time already too. So it's just a matter of copying the packages from those projects into the backport project.
Factory or 10 different repositories will probably not do the trick. Factory is to bleeding, and an everyday user will not manage X number of aditional repositories.
That's why we build new versions of GNOME/KDE for old versions of openSUSE :-) Not everybody wants to use Factory, that's true.
Note that in the case of GNOME (and KDE, I assume), even to create a backport project, we'll need to have our own project to make sure everything is fine before moving all the packages to the backport project. So what we currently do is actually a good first step to help make happen what you'd like to see ;-)
Vincent
On Monday 09 March 2009 07:54:39 am Vincent Untz wrote: ...
Nod. I'm not that worried about missing one GNOME or KDE release. We can always offer it in a build service project, or create a re-spinned Live CD if we want (and I think we will want to do this :-)).
It is nice to hear that you think about. It really wouldn't hurt to have updated media. Installed system without need for massive updates is excellent marketing, for us and it can push other to follow, which will help Linux.
Rajko M. a écrit :
It really wouldn't hurt to have updated media.
this can't be done with the present boxed edition system.
But why do we still have boxed edition??
couldn't we *drop* the boxed edition? We could still sell a *manual* (could even be made for several versions, for example the same one for "11", then "12"..., and sell a "soft bounded" dvd, that is only the dvd, some stickers easy to send by mail and not too expensive.
The box cost more than the dvd and we don't even sell through dealers, so no box needed, so with this system we could have new dvd each quarter?
jdd
couldn't we *drop* the boxed edition? We could still sell a *manual* (could even be made for several versions, for example the same one for "11", then "12"..., and sell a "soft bounded" dvd, that is only the dvd, some stickers easy to send by mail and not too expensive.
I have no idea of the number of sold boxes. I think they make it also for marketing purposes, and actually I like the idea of the box. I know more than one contributor that started "just to have a box" and then became a faithful contributor too.
The box cost more than the dvd and we don't even sell through dealers, so no box needed, so with this system we could have new dvd each quarter?
No box needed sounds a bit strong to me. However, who would prepare the DVD's every four months? Is it really worth instead than downloading a few delta RPM's? And what about the mirrors? Would they be happy with such frequent updates?
Regards, A.
Alberto Passalacqua a écrit :
I have no idea of the number of sold boxes. I think they make it also for marketing purposes, and actually I like the idea of the box. I know more than one contributor that started "just to have a box" and then became a faithful contributor too.
yes, but having a box is pretty difficult nowaday and the most expensive is shipping costs from Germany
No box needed sounds a bit strong to me. However, who would prepare the DVD's every four months?
dvd with only the bugfixes already done should not be that difficult, but if it is why not add an update cd? but it should be available with the box/hard bound delivery, not only as dl.
most unexperienced people doing a good install endup with several hours dl at the end of the install, this is not pretty
Is it really worth instead than downloading a
few delta RPM's? And what about the mirrors? Would they be happy with such frequent updates?
updates are not a problem (only three in 8 month) if disk usage is the same
we have problems because things are blocked by the box system. Only this prevent us from having updated media (I really don't see what is difficult as having updates included with the dvd, enough to include the relevant update repository content)
jdd
On Mon, 2009-03-09 at 18:28 +0100, jdd wrote:
dvd with only the bugfixes already done should not be that difficult, but if it is why not add an update cd? but it should be available with the box/hard bound delivery, not only as dl.
So I see what you want is the update CD *with* the boxed edition. That would be difficult, but if that's what you want what does getting rid of the boxed edition help?
most unexperienced people doing a good install endup with several hours dl at the end of the install, this is not pretty
For dial-up users, yeah. For openSUSE 11.1 at least, the updates are small and take place in the background.
On Mon, 2009-03-09 at 16:36 +0100, jdd wrote:
The box cost more than the dvd and we don't even sell through dealers, so no box needed, so with this system we could have new dvd each quarter?
A couple of things on this idea:
1. I recently reinstalled an openSUSE 11.1 computer w/ the boxed edition. I have a lower-end DSL connection, and the updates took less than a couple of minutes, and it was in the background while I was setting up other stuff anyway.
2. With the tools now available, I'm sure many of us here have the ability to re-spin the openSUSE media w/ all bundled updates later. What you're saying about the boxed edition doesn't make any sense... the DVD can be made without the boxed edition.
jdd escribió:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2009-03-09 at 21:34 -0300, Cristian Rodríguez wrote:
jdd escribió:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
Yes, I would.
- -- Cheers, Carlos E. R.
2009/3/10 Carlos E. R. carlos.e.r@opensuse.org:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2009-03-09 at 21:34 -0300, Cristian Rodríguez wrote:
jdd escribió:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
Yes, I would.
I agree with Carlos, I would expect that quite a lot would like an "openSUSE for Dummies" book. (Me included :-) I guess I would discover new secrets about openSUSE there also)
Birger
On Tuesday 10 March 2009 04:40:29 am Birger Kollstrand wrote:
2009/3/10 Carlos E. R. carlos.e.r@opensuse.org:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2009-03-09 at 21:34 -0300, Cristian Rodríguez wrote:
jdd escribió:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
Yes, I would.
I agree with Carlos, I would expect that quite a lot would like an "openSUSE for Dummies" book. (Me included :-) I guess I would discover new secrets about openSUSE there also)
Birger
I agree that there are changes that is not easy to follow without serious insider help. I don't dare to start putting togeather list of questions that each serious openSUSE user would like to know. Current status of looking around mail lists, forums, wiki, all novel.com URLs etc, for pieces of information is time consuming.
Though, there must be better way to deliver printed media. Not everything is changed from version to version, so ringbook and updated pages might be the way to go. It would be far easier to prepare, cheaper to print, and user will have one current book, and archive for past releases. Beauty of the print has no much value for technical documents.
The problem for guys that have to write documentation is that developmet has to be frozen for a while, so that they can document changes. It is often far faster do create feature, then to document it. Programming languages are meant to be compressed expression, understandable to people with some training, while documentation has to explain that to people without it.
What this will allow to openSUSE enthusiasts? Being knowledgable, leading community members. Lesser explanations online, just point to document.
The problem for guys that have to write documentation is that developmet has to be frozen for a while, so that they can document changes. It is often far faster do create feature, then to document it. Programming languages are meant to be compressed expression, understandable to people with some training, while documentation has to explain that to people without it.
What this will allow to openSUSE enthusiasts? Being knowledgable, leading community members. Lesser explanations online, just point to document.
An alternative would be to create a simple and unified method documenting features that doesn't take up much time and effort for the developers - and preferably one that enhances the process of development. The problem will be creating one that integrates well with the development environments so that, for example, it is simple to document parameters to programmes or input dialogue boxes, and this documentation travels through the development process with the code. If that is combined with the "requirements" documentation (this feature has been added / changed to answer this problem or requirement), it gives a very good start. Converting mailing lists / discussion fora into useful documentation would also be made easier by suitable (open source) tools, and many people would be happy adding to such documentation (and responding to the question with a link) rather than repeatedly answering the "How do I ..." questions?
This is an area where organisations like openSUSE and Novell are in a stronger position to respond than the general community, which tends to have much shorter term timescales and more limited objectives.
David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-03-10 at 18:24 -0000, Administrator wrote:
An alternative would be to create a simple and unified method documenting features that doesn't take up much time and effort for the developers - and preferably one that enhances the process of development. The problem will be creating one that integrates well with the development environments so that, for example, it is simple to document parameters to programmes or input dialogue boxes, and this documentation travels through the development process with the code.
That kind of "inline" documentation exists, some project use it. But that is only good for other devs, not for users, and is no substitute for a good quality documentation written as such by skilled people (like the SuSE admin book is/was).
- -- Cheers, Carlos E. R.
* Carlos E. R. carlos.e.r@opensuse.org [03-13-09 08:47]:
On Tuesday, 2009-03-10 at 18:24 -0000, Administrator wrote:
An alternative would be to create a simple and unified method documenting features that doesn't take up much time and effort for the developers - and preferably one that enhances the process of development. The problem will be creating one that integrates well with the development environments so that, for example, it is simple to document parameters to programmes or input dialogue boxes, and this documentation travels through the development process with the code.
That kind of "inline" documentation exists, some project use it. But that is only good for other devs, not for users, and is no substitute for a good quality documentation written as such by skilled people (like the SuSE admin book is/was).
Yes, "There *is* no substitute for a good quality documentation written as such by skilled people (like the SuSE admin book is/was)".
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-03-10 at 13:09 -0500, Rajko M. wrote:
I agree that there are changes that is not easy to follow without serious insider help. I don't dare to start putting togeather list of questions that each serious openSUSE user would like to know. Current status of looking around mail lists, forums, wiki, all novel.com URLs etc, for pieces of information is time consuming.
True.
Though, there must be better way to deliver printed media. Not everything is changed from version to version, so ringbook and updated pages might be the way to go. It would be far easier to prepare, cheaper to print, and user will have one current book, and archive for past releases. Beauty of the print has no much value for technical documents.
Interesting idea.
The problem for guys that have to write documentation is that developmet has to be frozen for a while, so that they can document changes. It is often far faster do create feature, then to document it. Programming languages are meant to be compressed expression, understandable to people with some training, while documentation has to explain that to people without it.
Well, books usually get released later than the software.
- -- Cheers, Carlos E. R.
On Friday 13 March 2009 07:46:18 am Carlos E. R. wrote:
True.
Though, there must be better way to deliver printed media. Not everything is changed from version to version, so ringbook and updated pages might be the way to go. It would be far easier to prepare, cheaper to print, and user will have one current book, and archive for past releases. Beauty of the print has no much value for technical documents.
Interesting idea.
If you think about software, how fast it changes, there is no normal book that can follow it, and be able the main advantage of the book, sequential reading. HTML with ability to reference explanations spoiled web writers, not to give a thought about readers ability to follow the matter.
The problem for guys that have to write documentation is that developmet has to be frozen for a while, so that they can document changes. It is often far faster do create feature, then to document it. Programming languages are meant to be compressed expression, understandable to people with some training, while documentation has to explain that to people without it.
Well, books usually get released later than the software.
Not the one in the box ;-)
* Birger Kollstrand birger.kollstrand@googlemail.com [03-10-09 05:42]:
I agree with Carlos, I would expect that quite a lot would like an "openSUSE for Dummies" book. (Me included :-) I guess I would discover new secrets about openSUSE there also)
me 3 :^)
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
Yes, I would.
I think a lot of the value of the boxed edition isn't the physical media - it's the support bundled and the manual. I bought a boxed edition for my first install, and have been using the downloaded version since.
And, if creating a new DVD is expensive, would it be possible to create and include a CD with the updates (or the core updates) which could be added to the box.
David
p.s. this is no worse than MS (if that's a recommendation). I recently had to get a Vista machine in service, and that took 2 hours of OS patches before I started adding in the essential software (Firefox, iTunes, RealPlayer, OpenOffice etc.)...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-03-10 at 10:40 -0000, Administrator wrote:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
Yes, I would.
I think a lot of the value of the boxed edition isn't the physical media
- it's the support bundled and the manual. I bought a boxed edition for
my first install, and have been using the downloaded version since.
Notice that the book currently included with the box is not the thick book that /was/ included with the box 2 or 3 years ago, and which is the one I would like to have in paper now and then.
It would be the one that they include as html or pdf, the "/usr/share/doc/manual/opensuse-manual_en/manual/index.html", I think, that was called the "admin" book.
And, if creating a new DVD is expensive, would it be possible to create and include a CD with the updates (or the core updates) which could be added to the box.
+1
- -- Cheers, Carlos E. R.
On Tuesday 10 March 2009 01:34:06 Cristian Rodríguez wrote:
jdd escribió:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
If the printed manual is as good and complete as it has been in the times of 8.x and partly 9.x, I am sure people will buy it. The price must be reasonable and it must cover advanced topics, too, such as MediaCenter configuration e.g. with MythTV and HomeServer setups.
Btw, you could ask the same for the whole box: both the media and the manual are available online, so that would leave only dial up people as the targeted customers, if you are right.
I am convinced that dropping the who box edition in favor of updated and enhanced downloadable ISO-images and a really good printed manual would greatly enhance the popularity of the distribution.
To give an example: right now, I see the need of an update for the shipped version of KDE 4.1.3 in openSUSE 11.1. The next release of openSUSE will happen in November, and it's naive to think that this situation will satisfy the KDE community/fans of openSUSE. Consider how poor KDE 4.1.3 feels, even with all the openSUSE backports of 4.2. Don't forget KDE is -- still -- the most popular desktop environment, and it's really good to see it is now about to be back to the same quality level as its predecessor.
Many users won't want to wait until November for the recent improvements, and they don't want to use factory, either. They will look elsewhere, and they will find enough options, I am afraid.
Bottom line is: I'd very much vote for intermediate updates to the official releases, and that also means I think we should consider version upgrades, too, in such extrem cases as KDE currently is.
Best regards, Daniel
Daniel Mader a écrit :
I am convinced that dropping the who box edition in favor of updated and enhanced downloadable ISO-images and a really good printed manual would greatly enhance the popularity of the distribution.
see: https://features.opensuse.org/306172 jdd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-03-10 at 10:42 +0100, Daniel Mader wrote:
On Tuesday 10 March 2009 01:34:06 Cristian Rodríguez wrote:
jdd escribió:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
If the printed manual is as good and complete as it has been in the times of 8.x and partly 9.x, I am sure people will buy it. The price must be reasonable and it must cover advanced topics, too, such as MediaCenter configuration e.g. with MythTV and HomeServer setups.
Exactly.
Btw, you could ask the same for the whole box: both the media and the manual are available online, so that would leave only dial up people as the targeted customers, if you are right.
I have friends with no network at home and very limited network on the job. A small download (10 MB) is very problematic. Which means that I burn the iso for them, but they can not do updates at all. And I live in an "priviledged" country like Spain: the situation is even more difficult on many other countries. There, updated DVDs for up to date installation without network should be interesting.
I am convinced that dropping the who box edition in favor of updated and enhanced downloadable ISO-images and a really good printed manual would greatly enhance the popularity of the distribution.
The printed manual could have a copy of the current distribution on a sleeve. And even better if it also includes the updates on another CD. On the plus side, users with broadband could still be interested in getting a good printer book.
- -- Cheers, Carlos E. R.
Cristian Rodríguez wrote:
jdd escribió:
couldn't we *drop* the boxed edition? We could still sell a *manual*
Do you really believe that people interested in the distribution will buy a manual that is available online anyway ?
There have been studies with regard to written textbooks versus e-books and more is retained and understood when the reading is handheld. This means: A book is best A handheld e-book is second An e-book on the PC is third in quality of learning the materials
jdd wrote:
Rajko M. a écrit :
It really wouldn't hurt to have updated media.
this can't be done with the present boxed edition system.
But why do we still have boxed edition??
couldn't we *drop* the boxed edition? We could still sell a *manual* (could even be made for several versions, for example the same one for "11", then "12"..., and sell a "soft bounded" dvd, that is only the dvd, some stickers easy to send by mail and not too expensive.
The box cost more than the dvd and we don't even sell through dealers, so no box needed, so with this system we could have new dvd each quarter?
jdd
This whole soft bounded DVD with Stickers is a "keen" idea, it would be easy to add the opensuse-edu DVD to it and send it to schools!
Il giorno lun, 09/03/2009 alle 08.58 -0500, Rajko M. ha scritto:
On Monday 09 March 2009 07:54:39 am Vincent Untz wrote: ...
Nod. I'm not that worried about missing one GNOME or KDE release. We can always offer it in a build service project, or create a re-spinned Live CD if we want (and I think we will want to do this :-)).
It is nice to hear that you think about. It really wouldn't hurt to have updated media. Installed system without need for massive updates is excellent marketing, for us and it can push other to follow, which will help Linux.
You are right. But it takes time to make working media, and these guys are already overbusy most of the time. So, well, I think we can be happy with patches if no volunteer makes respins.
Regards, A.
On Monday 09 March 2009 11:06:46 am Alberto Passalacqua wrote:
Il giorno lun, 09/03/2009 alle 08.58 -0500, Rajko M. ha scritto:
On Monday 09 March 2009 07:54:39 am Vincent Untz wrote: ...
Nod. I'm not that worried about missing one GNOME or KDE release. We can always offer it in a build service project, or create a re-spinned Live CD if we want (and I think we will want to do this :-)).
It is nice to hear that you think about. It really wouldn't hurt to have updated media. Installed system without need for massive updates is excellent marketing, for us and it can push other to follow, which will help Linux.
You are right. But it takes time to make working media, and these guys are already overbusy most of the time. So, well, I think we can be happy with patches if no volunteer makes respins.
Regards, A.
I'm fine with updates, but as I mentioned elsewhere it is problem when inexperienced user has to look update running 1 or more hours. Fact that it is worse with another OS doesn't help much, because they seldom see how it is to update, for instance XP. Either, they bring computer to service and after a day, or two, pick it up, or they never run any update, just reload XP from vendor's image, which is fast.
It seems good candidate for Geeko needs you! Someone that already did it should take mentorship, to help with problems that prospective volunteers can hit.
Rajko M. escribió:
It really wouldn't hurt to have updated media.
Question: Who will do this ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2009-03-05 at 12:00 +0100, Stephan Kulow wrote:
To give us something to plan around, we would like to propose a fixed release schedule. As a six-month release schedule is not something we consider feasible to maintain high-quality standards, we are proposing a fixed eight- month schedule.
You could consider an eight-month cycle with a bit of leeway. Like delaying one month if that means catching a nice enough release of something upstream. Or if the holidays get in the way, as you just did for 11.2.
November 2009: "Fichte" 11.2
Not September. Good! Thanks.
July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
I'm curious about the version names. Neither against or pro, just curious: why "names" at all, why these names in particular... :-)
Surely someone wrote/bloged about this, I hope.
Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that. We are planning a strict four-week release candidate (RC) phase.
Strict... :-? IMO, bugs, sometimes important, are only found during the RC phase. It's a fact. Some people only test at that point. A little flexibility might be handy to polish those bugs. 11.1 got a lot of them: some were solved just very recently.
The features we have in mind for 11.2 center around these top features:
...
- Ext4 - possibly even as the default filesystem.
Wow.
- Provide YaST Web interface for easier remote adminstration.
Nice! :-)
- Netbook support
Please, consider adding a setting in YaST for machines on battery with all kind of optimizations: cpu freq, cron stop, disk sync delay, package selection, cpu intensive eye candy, etc, etc.
- -- Cheers, Carlos E. R.
Am Donnerstag 05 März 2009 schrieb Carlos E. R.:
On Thursday, 2009-03-05 at 12:00 +0100, Stephan Kulow wrote:
To give us something to plan around, we would like to propose a fixed release schedule. As a six-month release schedule is not something we consider feasible to maintain high-quality standards, we are proposing a fixed eight- month schedule.
Hi Carlos,
You could consider an eight-month cycle with a bit of leeway. Like delaying one month if that means catching a nice enough release of something upstream. Or if the holidays get in the way, as you just did for 11.2.
Yeah, considered and thrown away. We need fixed schedule urgently - and holidays don't jump around much in the year. And we won't wait for upstream as outlined in my mail.
November 2009: "Fichte" 11.2
Not September. Good! Thanks.
July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
I'm curious about the version names. Neither against or pro, just curious: why "names" at all, why these names in particular... :-)
Surely someone wrote/bloged about this, I hope.
Yeah, we had a naming convention summit here and ... NO, I walked this morning with my son and suddenly I wondered if he's already aware of himself or if he needs other subjects to make him aware he's an individual - as he started waving every other person he sees. And as I continued my thinking, I thought that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that. We are planning a strict four-week release candidate (RC) phase.
Strict... :-? IMO, bugs, sometimes important, are only found during the RC phase. It's a fact. Some people only test at that point. A little flexibility might be handy to polish those bugs. 11.1 got a lot of them: some were solved just very recently.
So you're saying we shouldn't have release 11.1 before march? I'm afraid we don't have that kind of flexibility, as a matter of fact some users were already shoked when they didn't get their boxes for christmas.
- Netbook support
Please, consider adding a setting in YaST for machines on battery with all kind of optimizations: cpu freq, cron stop, disk sync delay, package selection, cpu intensive eye candy, etc, etc.
You know about openFate?
Greetings, Stephan
Stephan Kulow a écrit :
that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
should be explained. no idea of what Fichte is :-)
http://en.wikipedia.org/wiki/Fichte ?
I know about Kant and hegel, but never heard about Fichte :-)
jdd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2009-03-05 at 13:51 +0100, jdd wrote:
Stephan Kulow a écrit :
that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
should be explained. no idea of what Fichte is :-)
http://en.wikipedia.org/wiki/Fichte ?
I know about Kant and hegel, but never heard about Fichte :-)
Same here.
- -- Cheers, Carlos E. R.
Am Donnerstag 05 März 2009 schrieb jdd:
Stephan Kulow a écrit :
that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
should be explained. no idea of what Fichte is :-)
http://en.wikipedia.org/wiki/Fichte ?
I know about Kant and hegel, but never heard about Fichte :-)
Then I'm glad I filled your gap ;)
Greetings, Stephan
On Thursday 05 March 2009 06:51:51 am jdd wrote:
Stephan Kulow a écrit :
that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
should be explained. no idea of what Fichte is :-)
Also: http://de.wikipedia.org/wiki/Fichte - a spruce - last name of German writer, theolog, philosoph, actor - sport team http://de.wiktionary.org/wiki/Fichte You'll find French word too.
I know about Kant and hegel, but never heard about Fichte :-)
Whatever it is, I'm bored with fixation on geeko (gecko) names.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2009-03-05 at 13:29 +0100, Stephan Kulow wrote:
Am Donnerstag 05 März 2009 schrieb Carlos E. R.:
Hi Carlos,
You could consider an eight-month cycle with a bit of leeway. Like delaying one month if that means catching a nice enough release of something upstream. Or if the holidays get in the way, as you just did for 11.2.
Yeah, considered and thrown away. We need fixed schedule urgently - and holidays don't jump around much in the year. And we won't wait for upstream as outlined in my mail.
Well, OK.
November 2009: "Fichte" 11.2
Not September. Good! Thanks.
July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
I'm curious about the version names. Neither against or pro, just curious: why "names" at all, why these names in particular... :-)
Surely someone wrote/bloged about this, I hope.
Yeah, we had a naming convention summit here and ... NO, I walked this morning with my son and suddenly I wondered if he's already aware of himself or if he needs other subjects to make him aware he's an individual - as he started waving every other person he sees. And as I continued my thinking, I thought that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
Ok.
Any link on why having names for versions?
Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that. We are planning a strict four-week release candidate (RC) phase.
Strict... :-? IMO, bugs, sometimes important, are only found during the RC phase. It's a fact. Some people only test at that point. A little flexibility might be handy to polish those bugs. 11.1 got a lot of them: some were solved just very recently.
So you're saying we shouldn't have release 11.1 before march? I'm afraid we don't have that kind of flexibility, as a matter of fact some users were already shoked when they didn't get their boxes for christmas.
No, of course not: that's an extreme example. A week or two at most.
But I did propose delaying the boxes in order to get the first month of updates or so. They would be more useful, IMO. An alternative would be a patch CD added to the box if you buy it a month later.
- Netbook support
Please, consider adding a setting in YaST for machines on battery with all kind of optimizations: cpu freq, cron stop, disk sync delay, package selection, cpu intensive eye candy, etc, etc.
You know about openFate?
Faintly O:-)
It is not listed on "http://en.opensuse.org/", "how to participate", for instance:
Suggest New Features or Software
Visit the Wishlists page and pick a category where you can add your suggestion. You can suggest a new application in a special Package Wishlist. Please edit the table there and add your wishes. Only software with an OSI-compliant open-source license will be added to the openSUSE project.
Going to "http://en.opensuse.org/Wishlists" or "http://en.opensuse.org/Package_Wishlist" doesn't mention Fate, either.
And doing a search for Fate or openFate doesn't come out very useful. On the end, I found "http://en.opensuse.org/OpenFATE". I'll have to read it up.
[...]
Mmmm... limited to members? :-?
- -- Cheers, Carlos E. R.
Hey,
great to see there is a plan =)
Am Donnerstag 05 März 2009 13:29:29 schrieb Stephan Kulow:
Am Donnerstag 05 März 2009 schrieb Carlos E. R.:
You could consider an eight-month cycle with a bit of leeway. Like delaying one month if that means catching a nice enough release of something upstream. Or if the holidays get in the way, as you just did for 11.2.
Yeah, considered and thrown away. We need fixed schedule urgently - and holidays don't jump around much in the year. And we won't wait for upstream as outlined in my mail.
Still a release before big holiday seasons like 11.1 should be avoided, people like toying around but nobody wants to fix bugs in the holidays. if that 24months block structure is kept around even in case of delays that's robust then.
Yeah, we had a naming convention summit here and ... NO, I walked this morning with my son and suddenly I wondered if he's already aware of himself or if he needs other subjects to make him aware he's an individual
- as he started waving every other person he sees. And as I continued my
thinking, I thought that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
Uh, I am quite neutral to the release name thing, but should we really announce a list like for 2 years in the future? The Ubuntuguy uses their name announcements to spread the word about plans for the next release.
Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that. We are planning a strict four-week release candidate (RC) phase.
Strict... :-? IMO, bugs, sometimes important, are only found during the RC phase. It's a fact. Some people only test at that point. A little flexibility might be handy to polish those bugs. 11.1 got a lot of them: some were solved just very recently.
So you're saying we shouldn't have release 11.1 before march? I'm afraid we don't have that kind of flexibility, as a matter of fact some users were already shoked when they didn't get their boxes for christmas.
The additional testing time and planned increased stability of factory will hopefully turn up the worst bugs early enough, but stuff like this should have stopped the release: https://bugzilla.novell.com/show_bug.cgi?id=408252 That christmasbox disaster could be accounted to a tight release schedule in front of holidays as well I think.
/me likes the schedule
Best regards, Karsten
Am Donnerstag 05 März 2009 schrieb Karsten König:
Yeah, we had a naming convention summit here and ... NO, I walked this morning with my son and suddenly I wondered if he's already aware of himself or if he needs other subjects to make him aware he's an individual - as he started waving every other person he sees. And as I continued my thinking, I thought that Fichte is a nice nick name for the next release - well, the other 3 I made up in no exact relation to each other.
Uh, I am quite neutral to the release name thing, but should we really announce a list like for 2 years in the future? The Ubuntuguy uses their name announcements to spread the word about plans for the next release.
As I wrote: the other 3 I made up to make clear what I imagine as pattern
Greetings, Stephan
Le jeudi 05 mars 2009, à 12:00 +0100, Stephan Kulow a écrit :
To give us something to plan around, we would like to propose a fixed release schedule. As a six-month release schedule is not something we consider feasible to maintain high-quality standards, we are proposing a fixed eight- month schedule.
Awesome, a fixed X-months schedule will make things easier in tons of areas :-)
Now all teams can work on making solid plans!
Vincent
2009/3/5 Alberto Passalacqua alberto.passalacqua@tin.it:
Hi,
And we came to the conclusion that it's best to adopt the eight-month schedule right away.
Sounds good!
A.
+1
Take your time. You don´t have to be in a hurry. It´s a good decision for quite enough stable distro.
On Mar 5, 2009, at 5:00 AM, Stephan Kulow coolo@novell.com wrote:
Hi,
As you may have noticed, we have yet to publish a roadmap for 11.2. The reason is simple: There are a lot of moving pieces at the moment, and we don't want to commit to a schedule we can't keep -- or keep a schedule that doesn't fit the project's long-term needs.
To give us something to plan around, we would like to propose a fixed release schedule. As a six-month release schedule is not something we consider feasible to maintain high-quality standards, we are proposing a fixed eight- month schedule
Not bad, but there is a bit of flexability in being able to adjust the release date. Do we want to give that up?
We have spent a considerable amount of time asking if we should go with a September release for 11.2 and then adopt an eight-month release schedule, or begin with an eight-month release schedule right away. And we came to the conclusion that it's best to adopt the eight-month schedule right away.
A six-month release cycle is interesting because you "only" have to find two months in the year for a release. Eight months makes it slightly more complicated, as you have a rotating schedule, and lose a month in the summer and winter for holidays
I like the rotating month schedule, that way we release at different times of the year.
So, what we're proposing is this -- the next openSUSE release in November 2009, with the next releases in July 2010, March 2011, and so forth:
November 2009: "Fichte" 11.2 July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
This gives us a single release in 2009 and 2010, and two releases in 2011. The version names and numbers may change, of course.
Sounds good as far as general time releases. But what's with the names? Is this an internal codename, or something we want to start publicly announcing (instead of version numbers)?
Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that.
Again seems a little strict, I don't see why we can't vary the release date.
We are planning a strict four-week release candidate (RC) phase.
This means that the last chance to change _anything_ but really urgent fixes would be the check-in deadline of RC1, which would be released in week 41 in 2009.
The 4-week RC deadline is nice!
The schedule would leave us with whatever software we have at that point. For example, we'll miss KDE 4.5 for 11.3 or the spring version of GNOME for 12.0. If missing these releases is a problem, let's discuss this _now_.
As we're all aware, trying to get the latest releases of everything in every release isn't successful - see the shaft of KDE 4.1 in 11.0 - but being able to adjust the release based on a release of KDE, GNOME, etc. is useful.
Of course, this doesn't mean we can't publish supported or unsupported addons or updated live CDs with the respective desktops or similar software: We just need people willing to do it.
Why such a late release date? Releasing 11.2 in November has some advantages over releasing in September:
- We don't rely on contributions during the summer months that much.
Not complaining or anything, but what exactly does this mean?
- We can easily integrate GNOME 2.28.
Insert smiley face here :-)
- We are more likely to have working drivers for hardware released
in early summer is higher. (This is a weak advantage since the summer release of Intel's graphic chips didn't work out with a December release either.)
- We simply have more time for everything.
As has been proven with the past release, more time and more testing is better for everyone.
The features we have in mind for 11.2 center around these top features:
- Newer and better software, including:
- KDE 4.3
- GNOME 2.28,
- Linux kernel 2.6.30 or higher
- Ext4 - possibly even as the default filesystem.
- Provide YaST Web interface for easier remote adminstration.
- Netbook support
- Offer USB images - possibly even with deployment tool if someone writes it.
- Include free drivers necessary for the netbook support.
- Officially support live updates - we need way more people to use
factory and report problems though.
Live updates?
- Quicker, Faster and more Colourful
Colorful, huh? I guess it's time to reopen the Pixel Pool for art contributions. jimmac, thoughts on this?
OK, I better stop here. This is already a pretty long mail - looking forward to your feedback. The last time we discussed schedules, the feedback was very good - and got us thinking quite a long time. ;)
Thanks Stephan :-) And thanks to the team for making this schedule the most openly planned ever!
On Štvrtok 05 March 2009 17:37:09 Kevin Dupuy wrote:
On Mar 5, 2009, at 5:00 AM, Stephan Kulow coolo@novell.com wrote:
[snip]
The features we have in mind for 11.2 center around these top features:
- Newer and better software, including:
- KDE 4.3
- GNOME 2.28,
- Linux kernel 2.6.30 or higher
- Ext4 - possibly even as the default filesystem.
- Provide YaST Web interface for easier remote adminstration.
- Netbook support
- Offer USB images - possibly even with deployment tool if someone writes it.
- Include free drivers necessary for the netbook support.
- Officially support live updates - we need way more people to use
factory and report problems though.
Live updates?
https://features.opensuse.org/305634
Stano
Stanislav Visnovsky a écrit :
I found the voting system by chance, browsing the page! It's not explained in the help!
it is not obvious at all than one have to put the mouse cusor on the "score" applet
and the help say to add a comment, this is probably why most people add a comment without real reason (and may be don't vote)
jdd
On Thursday 05 March 2009 17:37:09 Kevin Dupuy wrote:
Not bad, but there is a bit of flexability in being able to adjust the release date. Do we want to give that up?
In the past it took us far too long to align to a schedule and therefore we propose a fixed date. There's still some flexibility but it should be the exception. Let's say, we will not release the thursday before easter. But the date is the one we use and will block in our calendars.
If the quality is bad, we still can move the final release.
But I prefer to not have a discussion every time again just because of a single project where we might not hit their release date...
Andreas
Today, I sat and read this entire thread and I have a few comments: 1) It is often forgotten that NO ONE produces a desktop DVD with as much included software and utilities as openSUSE. Moving to 8 months cycle just to support new kernels and all of YaST2 is not that unreasonable. Add two desktops and 3 Gb of software and well, Thank you Team!!!! 2) if printing a cardboard box is keeping us from having a nice boxed set then dump the box and shrink wrap a nice manual with the DVD's ( a sticker would hurt my feelings , make them version agnostic so that we only have to print them when we need more) and a support certificate. 3) consider separating the applications from the distro and spinning regular "live CD's" that install as they do now. With separated applications and a commitment to refining each "live CD" , it could become an upgrade in place option instead of a patch CD and the BS could be asked to recompile all the applications for the new Live CD as we do know when we provide a repo for 11.0>11.1>11x. When a customer needs a new DVD due to bandwidth issues. It would seem that it's a lot cheaper to burn a copy of the BS repo. These "application" DVD's could also be sold separately. I know that a great deal of work goes into what is being done, but if these minor quality issues are keeping us from being number one then I say reduce the workload until the live CD's run perfect on 99% of the hardware and leave the apps to "ADD-ON" media. I repeat myself but the tools seem to already be in YaST to create patch and add-on cd's. Our example of how easy it is could make the technology an outstanding feature that puts us on top.
* James Tremblay aka SLEducator fxrsliberty@opensuse.us [03-12-09 10:03]:
Today, I sat and read this entire thread and I have a few comments:
To my uneducated eye, your suggestions make *good* sense.
tks,
-
Administrator -
Alberto Passalacqua -
Andreas Jaeger -
Birger Kollstrand -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Daniel Mader -
Gerald Pfeifer -
James Tremblay aka SLEducator -
jdd -
Karsten König -
Kevin "Yeaux" Dupuy -
Kevin Dupuy
-
Luis Medinas -
Marcus Meissner -
Martin Schlander -
Michael Loeffler -
Patrick Shanahan -
Rajko M. -
Rastislav Krupanský -
Stanislav Visnovsky -
Stephan Kulow -
Vincent Untz