AN OPEN PROPOSAL ON openSUSE VERSION NUMBERING:
I have been giving the openSUSE version numbering issue some serious thought lately. I have come up with an interesting solution to the issue that I would like to propose to the community. I am in no way married to this idea but I do feel it is the best solution out of everything else that has been proposed.
The core idea of the model that I am proposing is to have a set of minor number releases within an 8 month major number release cycle. I have outlined my idea to illustrate what I mean by this.
1) Every 8 months we should launch a major version number release. This would be kind of like Fedora does with their number every 6 months but ours would be every 8. (e.g. openSUSE 12.0)
2) After launch, we should release a new image(GoldMaster) with the updates/patches applied as a minor version number release, once a month for the next 4 months. This will help people who have not installed the major version release because of a bug to install a minor number release as bugs get patched. Also this will help to denote stability and maturity in the release (e.g. openSUSE 12.1, 12.2, 12.3, 12.4)
3) 2 months from the last minor number release we should release one more minor number(this will be 6 months from the original release of our major number)… this will mean the x.5 releases of openSUSE will earn a reputation and respect for being very stable (e.g. openSUSE 12.5)
4) After the x.5 release we should not release any more minor number images in preparation for our next major version number launch!
I think this model would make our 8 month cycle more competitive while providing a more structured meaning to our version numbering and, more importantly, maintaining an identity of our own. Also this will show the fast development of our 8 month cycle.
Some things to consider before deciding on or implementing this for our project:
1) The increased frequency of version numbering will mean we will have more opportunities to make noise about our distribution in a marketing sense. Also, the transition and change to this model will give use marketing opportunities to ensure the FOSS community knows of the changes before implementation. Keep in mind that more noise means more energy from our marketing team and ambassadors.
2) This is something that CAN be done however, we would need volunteers from the community to help with the added man power it will take to crank out the minor number releases. Though it may take some added effort to achieve this model, we have the infrastructure in place to help facilitate it (OBS, openFATE, Connect, Lizards blogs, Wiki pages, Forums, etc.).
3) The frequency of the minor number releases proposed above is NOT the heart of this proposal. Rather, it is a personal opinion on how the idea of interim(minor number) patched releases within our 8 month cycle can look.
A NOTE: I know some will have an issue with this thinking that it abandons the 8 month development cycle but in my opinion this enhances it.
On 04/11/2011 09:00 AM, Drew Adams wrote:
AN OPEN PROPOSAL ON openSUSE VERSION NUMBERING:
I have been giving the openSUSE version numbering issue some serious thought lately. I have come up with an interesting solution to the issue that I would like to propose to the community. I am in no way married to this idea but I do feel it is the best solution out of everything else that has been proposed.
The core idea of the model that I am proposing is to have a set of minor number releases within an 8 month major number release cycle. I have outlined my idea to illustrate what I mean by this.
- Every 8 months we should launch a major version number release. This would
be kind of like Fedora does with their number every 6 months but ours would be every 8. (e.g. openSUSE 12.0)
- After launch, we should release a new image(GoldMaster) with the
updates/patches applied as a minor version number release, once a month for the next 4 months. This will help people who have not installed the major version release because of a bug to install a minor number release as bugs get patched. Also this will help to denote stability and maturity in the release (e.g. openSUSE 12.1, 12.2, 12.3, 12.4)
- 2 months from the last minor number release we should release one more
minor number(this will be 6 months from the original release of our major number)… this will mean the x.5 releases of openSUSE will earn a reputation and respect for being very stable (e.g. openSUSE 12.5)
- After the x.5 release we should not release any more minor number images in
preparation for our next major version number launch!
I think this model would make our 8 month cycle more competitive while providing a more structured meaning to our version numbering and, more importantly, maintaining an identity of our own. Also this will show the fast development of our 8 month cycle.
Some things to consider before deciding on or implementing this for our project:
- The increased frequency of version numbering will mean we will have more
opportunities to make noise about our distribution in a marketing sense. Also, the transition and change to this model will give use marketing opportunities to ensure the FOSS community knows of the changes before implementation. Keep in mind that more noise means more energy from our marketing team and ambassadors.
- This is something that CAN be done however, we would need volunteers from
the community to help with the added man power it will take to crank out the minor number releases. Though it may take some added effort to achieve this model, we have the infrastructure in place to help facilitate it (OBS, openFATE, Connect, Lizards blogs, Wiki pages, Forums, etc.).
- The frequency of the minor number releases proposed above is NOT the heart
of this proposal. Rather, it is a personal opinion on how the idea of interim(minor number) patched releases within our 8 month cycle can look.
A NOTE: I know some will have an issue with this thinking that it abandons the 8 month development cycle but in my opinion this enhances it.
Drew there's two aspects : First numbering is now fixed, and please don't come back to this before 2020 :-) (cf the several threads on ML, this http://news.opensuse.org/2011/04/06/plus-ca-change-plus-cest-la-meme-chose/ and http://lizards.opensuse.org/2011/04/06/versionitis/ )
Your proposal is pretty good (should have been proposed two months ago), but imply human power to release each iso. So such future proposal, should be made, once a real team of people is able to manage it, and for several years. (ask coolo how much time / work is needed for each release) Otherwise we will just make a new long thread of words.
I'm feel so sorry now :-)
On Monday, April 11, 2011 03:46:06 AM Bruno Friedmann wrote: ...
Drew there's two aspects : First numbering is now fixed, and please don't come back to this before 2020 :-)
...
Your proposal is pretty good (should have been proposed two months ago), but imply human power to release each iso. So such future proposal, should be made, once a real team of people is able to manage it, and for several years. (ask coolo how much time / work is needed for each release) Otherwise we will just make a new long thread of words.
I'm feel so sorry now :-)
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
Making release with software that already has patches and patches are tested as good is not that much work as stabilizing factory.
For me major improvement is that users downloading media will get one installation media to download plus modest number of patches that are released since last version, which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
On 04/11/2011 11:13 AM, Rajko M. wrote:
On Monday, April 11, 2011 03:46:06 AM Bruno Friedmann wrote: ...
Drew there's two aspects : First numbering is now fixed, and please don't come back to this before 2020 :-)
...
Your proposal is pretty good (should have been proposed two months ago), but imply human power to release each iso. So such future proposal, should be made, once a real team of people is able to manage it, and for several years. (ask coolo how much time / work is needed for each release) Otherwise we will just make a new long thread of words.
I'm feel so sorry now :-)
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
Making release with software that already has patches and patches are tested as good is not that much work as stabilizing factory.
For me major improvement is that users downloading media will get one installation media to download plus modest number of patches that are released since last version, which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
+100, yes I can change my mind ... As I've said, if it's REALLY feasible, and his better than the actual or near future. Do it!
Hello,
the proposal does not look feasible to me at all. The multiplication of effort required to do what you propose is huge, and the advantages are nothing more than a "service pack", which users can get by simply installing online updates, which seems more rational to me.
The eight month release cycle was decide some time ago to *reduce* the workload and to improve the quality of the release. I think it is working in this direction, as a consequence I don't believe that adding intermediate releases will improve the global quality of the release.
Best, Alberto
2011/4/11 Bruno Friedmann bruno@ioda-net.ch:
On 04/11/2011 11:13 AM, Rajko M. wrote:
On Monday, April 11, 2011 03:46:06 AM Bruno Friedmann wrote: ...
Drew there's two aspects : First numbering is now fixed, and please don't come back to this before 2020 :-)
...
Your proposal is pretty good (should have been proposed two months ago), but imply human power to release each iso. So such future proposal, should be made, once a real team of people is able to manage it, and for several years. (ask coolo how much time / work is needed for each release) Otherwise we will just make a new long thread of words.
I'm feel so sorry now :-)
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
Making release with software that already has patches and patches are tested as good is not that much work as stabilizing factory.
For me major improvement is that users downloading media will get one installation media to download plus modest number of patches that are released since last version, which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
+100, yes I can change my mind ... As I've said, if it's REALLY feasible, and his better than the actual or near future. Do it!
--
Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
I am with AlbertoP on this one, we do not have enough people to get this worked out.
Regards Manu
On Mon, Apr 11, 2011 at 9:43 PM, Alberto Passalacqua albert.passalacqua@gmail.com wrote:
Hello,
the proposal does not look feasible to me at all. The multiplication of effort required to do what you propose is huge, and the advantages are nothing more than a "service pack", which users can get by simply installing online updates, which seems more rational to me.
The eight month release cycle was decide some time ago to *reduce* the workload and to improve the quality of the release. I think it is working in this direction, as a consequence I don't believe that adding intermediate releases will improve the global quality of the release.
Best, Alberto
2011/4/11 Bruno Friedmann bruno@ioda-net.ch:
On 04/11/2011 11:13 AM, Rajko M. wrote:
On Monday, April 11, 2011 03:46:06 AM Bruno Friedmann wrote: ...
Drew there's two aspects : First numbering is now fixed, and please don't come back to this before 2020 :-)
...
Your proposal is pretty good (should have been proposed two months ago), but imply human power to release each iso. So such future proposal, should be made, once a real team of people is able to manage it, and for several years. (ask coolo how much time / work is needed for each release) Otherwise we will just make a new long thread of words.
I'm feel so sorry now :-)
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
Making release with software that already has patches and patches are tested as good is not that much work as stabilizing factory.
For me major improvement is that users downloading media will get one installation media to download plus modest number of patches that are released since last version, which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
+100, yes I can change my mind ... As I've said, if it's REALLY feasible, and his better than the actual or near future. Do it!
--
Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- Alberto Passalacqua -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday, April 11, 2011 11:13:06 AM Alberto Passalacqua wrote:
Hello,
the proposal does not look feasible to me at all. The multiplication of effort required to do what you propose is huge, and the advantages are nothing more than a "service pack", which users can get by simply installing online updates, which seems more rational to me.
Multiplication of effort saved on distro side, goes with price. Effort is shifted from distro to each user and mirror infrastructure. Once for installation media and then few hundred of megabytes right after the installation.
Besides, you don't release new packages, you are replacing original rpms with patched, and create iso image. How much effort is to copy update repo to main and run kiwi image creator - the very same that was used for original iso?
The eight month release cycle was decide some time ago to *reduce* the workload and to improve the quality of the release. I think it is working in this direction, as a consequence I don't believe that adding intermediate releases will improve the global quality of the release.
It will be improved user experience, if that matters. Specially in cases where original disk will not boot at all for some reason and online patches will stay where they are, on the server. If memory serves me, you had such experience with some releases.
2011/4/11 Rajko M. rmatov101@charter.net:
Multiplication of effort saved on distro side, goes with price. Effort is shifted from distro to each user and mirror infrastructure. Once for installation media and then few hundred of megabytes right after the installation.
This is not true. You put *more* load on mirrors, since you have to upload the new ISO's, and most probably users will download them thinking it's a new release.
Besides, you don't release new packages, you are replacing original rpms with patched, and create iso image. How much effort is to copy update repo to main and run kiwi image creator - the very same that was used for original iso?
Again, not so easy. You have to test.
It will be improved user experience, if that matters. Specially in cases where original disk will not boot at all for some reason and online patches will stay where they are, on the server. If memory serves me, you had such experience with some releases.
User experience can and should be improved in the main release. What you are suggesting justifies lower quality releases, since there will be a new updated release.
Best, Alberto
On Monday, April 11, 2011 07:54:31 AM Bruno Friedmann wrote:
On 04/11/2011 11:13 AM, Rajko M. wrote:
On Monday, April 11, 2011 03:46:06 AM Bruno Friedmann wrote: ...
Drew there's two aspects : First numbering is now fixed, and please don't come back to this before 2020 :-)
...
Your proposal is pretty good (should have been proposed two months ago), but imply human power to release each iso. So such future proposal, should be made, once a real team of people is able to manage it, and for several years. (ask coolo how much time / work is needed for each release) Otherwise we will just make a new long thread of words.
I'm feel so sorry now :-)
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
Making release with software that already has patches and patches are tested as good is not that much work as stabilizing factory.
For me major improvement is that users downloading media will get one installation media to download plus modest number of patches that are released since last version, which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
+100, yes I can change my mind ... As I've said, if it's REALLY feasible, and his better than the actual or near future. Do it!
Well Bruno,
I think its good that you and Rajko see the value in this idea. I think the important thing to do is to find out if this is possible... even if the frequency of the minor releases would be signifgently lower than what I had proposed (maybe we only do a minor every 2 months between majors - 12.1, 12.2, 12.3)
I know that making a release is work (that's why I actually did run this by Coolo before presenting it here. He told me to Propose it... only adding that he will not be available to work on additional releases.). Keep in mind that the minor releases wold NOT be a FULL release as it would only add the patches to the major release. Adding these shouldnt be too hard with KIWI if we have the right volunteer. It's like Rajko said, it's not like we would have to stabilize factory with every minor as the patches are already deemed good.
Do you know how long it would take to create a working image with the current patches applied? If that is something that can be estimated I would love to see a rough idea on how long it would take.
2011/4/11 Rajko M. rmatov101@charter.net:
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
How do you consider this proposal realistic? You perfectly know the difficulties in terms of resources the project has.
Making release with software that already has patches and patches are tested as good is not that much work as stabilizing factory.
For me major improvement is that users downloading media will get one installation media to download plus modest number of patches that are released since last version, which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
It might be for places where connection speed is low. For others it is really not a big deal, since updates can be installed during the installation process.
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Actually we have something that offers this: SUSE Studio, if you really cannot wait some time to install patches.
Best, Alberto
On Monday, April 11, 2011 11:18:01 AM Alberto Passalacqua wrote:
2011/4/11 Rajko M. rmatov101@charter.net:
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
How do you consider this proposal realistic? You perfectly know the difficulties in terms of resources the project has.
Effort is not equal to making a complete new release. It is at the level of tell me once how to do it and I can do it, with all time constrains I have right now.
... which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
It might be for places where connection speed is low. For others it is really not a big deal, since updates can be installed during the installation process.
It is download that is slower then DVD, or even better USB stick. I did installations of this type, and I know that I lost each end every user attention after some 2 hours. It is simply too long to keep them focused. School hour is not limited to 45 minutes without reason.
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Actually we have something that offers this: SUSE Studio, if you really cannot wait some time to install patches.
Already answered in another email.
Best, Alberto
Hi,
2011/4/11 Rajko M. rmatov101@charter.net:
Effort is not equal to making a complete new release. It is at the level of tell me once how to do it and I can do it, with all time constrains I have right now.
Preparing the ISO is not enough. You have to prepare different installation media, *test* them, because it's not that what comes out from Studio works every time, and then update mirrors. A lot of work that seems not justified, considering that many upgrade every eight months anyway.
... which is substantial improvement over current system where installation of released version is followed with hundreds of MB of download for updates.
It might be for places where connection speed is low. For others it is really not a big deal, since updates can be installed during the installation process.
It is download that is slower then DVD, or even better USB stick. I did installations of this type, and I know that I lost each end every user attention after some 2 hours. It is simply too long to keep them focused. School hour is not limited to 45 minutes without reason.
Well honestly that is a very specific purpose. It does not take two hours to have a fully installed and updated system. On a recent machine it takes about 10-15 minutes to install, and with a broadband connection and delta RPM's updates come quickly.
Best, Alberto
On Monday, April 11, 2011 18:18:01 Alberto Passalacqua wrote:
2011/4/11 Rajko M. rmatov101@charter.net:
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
How do you consider this proposal realistic? You perfectly know the difficulties in terms of resources the project has.
If a few step up and say we'll do it, it suddenly becomes possible ;). If you put this burden on those that already are engaged, it indeed becomes difficult,
Andreas
I'm maintaining Studio versions of the Live GNOME & Live KDE desktops:
http://susegallery.com/a/R8DAbW/live-gnome-32-bit http://susegallery.com/a/R8DAbW/live-kde-32-bit
I can update these on a monthly basis with current updates if that is the community's preference. The only issue I see is that the Studio CD format is larger than the well-tuned ISo on download - the Studio ISOs will *not* fit on a CD.
- James Mason 'bear454'
On Tue, Apr 12, 2011 at 5:15 AM, Andreas Jaeger aj@novell.com wrote:
On Monday, April 11, 2011 18:18:01 Alberto Passalacqua wrote:
2011/4/11 Rajko M. rmatov101@charter.net:
If someone comes with good idea before versions are applied is still good time, specially that current decision is made between our own identity and accepting numbering applied by other distros, nothing that really improves user experience.
How do you consider this proposal realistic? You perfectly know the difficulties in terms of resources the project has.
If a few step up and say we'll do it, it suddenly becomes possible ;). If you put this burden on those that already are engaged, it indeed becomes difficult,
Andreas
Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
I will have a look at the Jasons distro and maybe try to make it smaller so that it fits on a CD. Is there a branch-system for SUSE Studio yet, so that I can make a merge-request to him?
thanks
Am 11.04.2011 11:13, schrieb Rajko M.:
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Well, this can you have with *SUSE Studio*. Just download the latest packages, create your own repository or load the rpms on a archive up and tick them for being used for your appliance. Then you create a live CD/DVD and go to your friend and install it there.
I don´t see any problem in this thanks
PS: Just a suggestion: Test the appliance in a virtual machine and _then_ go to the friend and install it there.
On Monday, April 11, 2011 09:32:35 AM Kim Leyendecker wrote:
Am 11.04.2011 11:13, schrieb Rajko M.:
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Well, this can you have with *SUSE Studio*. Just download the latest packages, create your own repository or load the rpms on a archive up and tick them for being used for your appliance. Then you create a live CD/DVD and go to your friend and install it there.
I don´t see any problem in this thanks
PS: Just a suggestion: Test the appliance in a virtual machine and _then_ go to the friend and install it there.
So in other-words Kim... this is something that is easy to do? If so, it makes the point that, if it is so easy to do, why would we not implement this idea so the community can benafit from someone going through the process you outlined. Would there be a better way other than that to achive this idea with KIWI or any other tool to streamline the process?
On Mon, Apr 11, 2011 at 3:44 PM, Drew Adams Druonysus@aol.com wrote:
On Monday, April 11, 2011 09:32:35 AM Kim Leyendecker wrote:
Am 11.04.2011 11:13, schrieb Rajko M.:
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Well, this can you have with *SUSE Studio*. Just download the latest packages, create your own repository or load the rpms on a archive up and tick them for being used for your appliance. Then you create a live CD/DVD and go to your friend and install it there.
I don´t see any problem in this thanks
PS: Just a suggestion: Test the appliance in a virtual machine and _then_ go to the friend and install it there.
So in other-words Kim... this is something that is easy to do? If so, it makes the point that, if it is so easy to do, why would we not implement this idea so the community can benafit from someone going through the process you outlined. Would there be a better way other than that to achive this idea with KIWI or any other tool to streamline the process? -- Drew Adams
I have openSUSE on several servers. I never even consider upgrading them in the first 2 months of a release, so I certainly understand the difference between the day zero release and a day 60 release + updates.
And for server use, I don't like even the window of time between performing a baseline upgrade and when I get the patches applied.
So, I for one like the idea of doing at a minimum a major release every 8-months and a sub-release 2 months later.
But I'd be happy with:
11.4 - March '11 11.4.1 - May '11 12.1 - Nov '11 12.1.1 - Dec '12
etc.
And if that could be handled with minimal manpower, I for one would find myself keeping "x.x.1" releases in my physical archives, but tossing the x.x releases.
So while I like the basic idea Drew has a lot, I'd like to keep to exactly the current numbering for "major releases" and add a 3rd digit for sub-releases.
Greg
On Monday, April 11, 2011 01:08:42 PM you wrote:
On Mon, Apr 11, 2011 at 3:44 PM, Drew Adams Druonysus@aol.com wrote:
On Monday, April 11, 2011 09:32:35 AM Kim Leyendecker wrote:
Am 11.04.2011 11:13, schrieb Rajko M.:
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Well, this can you have with *SUSE Studio*. Just download the latest packages, create your own repository or load the rpms on a archive up and tick them for being used for your appliance. Then you create a live CD/DVD and go to your friend and install it there.
I don´t see any problem in this thanks
PS: Just a suggestion: Test the appliance in a virtual machine and _then_ go to the friend and install it there.
So in other-words Kim... this is something that is easy to do? If so, it makes the point that, if it is so easy to do, why would we not implement this idea so the community can benafit from someone going through the process you outlined. Would there be a better way other than that to achive this idea with KIWI or any other tool to streamline the process? -- Drew Adams
I have openSUSE on several servers. I never even consider upgrading them in the first 2 months of a release, so I certainly understand the difference between the day zero release and a day 60 release + updates.
And for server use, I don't like even the window of time between performing a baseline upgrade and when I get the patches applied.
So, I for one like the idea of doing at a minimum a major release every 8-months and a sub-release 2 months later.
But I'd be happy with:
11.4 - March '11 11.4.1 - May '11 12.1 - Nov '11 12.1.1 - Dec '12
etc.
And if that could be handled with minimal manpower, I for one would find myself keeping "x.x.1" releases in my physical archives, but tossing the x.x releases.
So while I like the basic idea Drew has a lot, I'd like to keep to exactly the current numbering for "major releases" and add a 3rd digit for sub-releases.
Greg
Greg,
I think that sounds like a fine implementation of the idea as well... especially since there seem to be some that really like the other numbering that was decided upon before my proposal. I do think that if we were to only do one patched "sub-release" it should be 4 months after the major release. This way it would be in the middle of our 8 month cycle and would include more patches... but either way is good.
On Mon, Apr 11, 2011 at 5:21 PM, Drew Adams Druonysus@aol.com wrote:
On Monday, April 11, 2011 01:08:42 PM you wrote:
On Mon, Apr 11, 2011 at 3:44 PM, Drew Adams Druonysus@aol.com wrote:
On Monday, April 11, 2011 09:32:35 AM Kim Leyendecker wrote:
Am 11.04.2011 11:13, schrieb Rajko M.:
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Well, this can you have with *SUSE Studio*. Just download the latest packages, create your own repository or load the rpms on a archive up and tick them for being used for your appliance. Then you create a live CD/DVD and go to your friend and install it there.
I don´t see any problem in this thanks
PS: Just a suggestion: Test the appliance in a virtual machine and _then_ go to the friend and install it there.
So in other-words Kim... this is something that is easy to do? If so, it makes the point that, if it is so easy to do, why would we not implement this idea so the community can benafit from someone going through the process you outlined. Would there be a better way other than that to achive this idea with KIWI or any other tool to streamline the process? -- Drew Adams
I have openSUSE on several servers. I never even consider upgrading them in the first 2 months of a release, so I certainly understand the difference between the day zero release and a day 60 release + updates.
And for server use, I don't like even the window of time between performing a baseline upgrade and when I get the patches applied.
So, I for one like the idea of doing at a minimum a major release every 8-months and a sub-release 2 months later.
But I'd be happy with:
11.4 - March '11 11.4.1 - May '11 12.1 - Nov '11 12.1.1 - Dec '12
etc.
And if that could be handled with minimal manpower, I for one would find myself keeping "x.x.1" releases in my physical archives, but tossing the x.x releases.
So while I like the basic idea Drew has a lot, I'd like to keep to exactly the current numbering for "major releases" and add a 3rd digit for sub-releases.
Greg
Greg,
I think that sounds like a fine implementation of the idea as well... especially since there seem to be some that really like the other numbering that was decided upon before my proposal. I do think that if we were to only do one patched "sub-release" it should be 4 months after the major release. This way it would be in the middle of our 8 month cycle and would include more patches... but either way is good. -- Drew Adams
Drew,
In this do-ocracy, I think only the numbering needs to be agreed upon now.
Then anytime someone actually creates a sub-release it gets the next sub-release version number.
So if tomorrow someone creates, 11.4.1, then it is done. All that is needed is to track the sub-releases on the wiki and have a place for people to download them.
If then 2 months from now, another sub-release is done, it gets 11.4.2.
Thus, the schedule is not preset, and a new sub-release can be made whenever the people doing the work feel is the right time.
For me in general, I would wait to upgrade a server until a sub-release came out out that had at least a couple months of patches in it. But I'm just one user and I'm not volunteering to create the sub-releases. Whoever does the work gets to set the timing.
Greg
On Monday, April 11, 2011 02:33:26 PM you wrote:
On Mon, Apr 11, 2011 at 5:21 PM, Drew Adams Druonysus@aol.com wrote:
On Monday, April 11, 2011 01:08:42 PM you wrote:
On Mon, Apr 11, 2011 at 3:44 PM, Drew Adams Druonysus@aol.com
wrote:
On Monday, April 11, 2011 09:32:35 AM Kim Leyendecker wrote:
Am 11.04.2011 11:13, schrieb Rajko M.:
This may not be a problem at home where you have thick download pipe and hours to do installation and updates, but at friends site shorter is better. You come with patched DVD and in one hour you are done, including first steps how to use. No distribution offers this now, and as they don't have OBS they will need some time to catch up.
Well, this can you have with *SUSE Studio*. Just download the latest packages, create your own repository or load the rpms on a archive up and tick them for being used for your appliance. Then you create a live CD/DVD and go to your friend and install it there.
I don´t see any problem in this thanks
PS: Just a suggestion: Test the appliance in a virtual machine and _then_ go to the friend and install it there.
So in other-words Kim... this is something that is easy to do? If so, it makes the point that, if it is so easy to do, why would we not implement this idea so the community can benafit from someone going through the process you outlined. Would there be a better way other than that to achive this idea with KIWI or any other tool to streamline the process? -- Drew Adams
I have openSUSE on several servers. I never even consider upgrading them in the first 2 months of a release, so I certainly understand the difference between the day zero release and a day 60 release + updates.
And for server use, I don't like even the window of time between performing a baseline upgrade and when I get the patches applied.
So, I for one like the idea of doing at a minimum a major release every 8-months and a sub-release 2 months later.
But I'd be happy with:
11.4 - March '11 11.4.1 - May '11 12.1 - Nov '11 12.1.1 - Dec '12
etc.
And if that could be handled with minimal manpower, I for one would find myself keeping "x.x.1" releases in my physical archives, but tossing the x.x releases.
So while I like the basic idea Drew has a lot, I'd like to keep to exactly the current numbering for "major releases" and add a 3rd digit for sub-releases.
Greg
Greg,
I think that sounds like a fine implementation of the idea as well... especially since there seem to be some that really like the other numbering that was decided upon before my proposal. I do think that if we were to only do one patched "sub-release" it should be 4 months after the major release. This way it would be in the middle of our 8 month cycle and would include more patches... but either way is good. -- Drew Adams
Drew,
In this do-ocracy, I think only the numbering needs to be agreed upon now.
Then anytime someone actually creates a sub-release it gets the next sub-release version number.
So if tomorrow someone creates, 11.4.1, then it is done. All that is needed is to track the sub-releases on the wiki and have a place for people to download them.
If then 2 months from now, another sub-release is done, it gets 11.4.2.
Thus, the schedule is not preset, and a new sub-release can be made whenever the people doing the work feel is the right time.
For me in general, I would wait to upgrade a server until a sub-release came out out that had at least a couple months of patches in it. But I'm just one user and I'm not volunteering to create the sub-releases. Whoever does the work gets to set the timing.
Greg
I agree with every word. I think that would work GREAT with less effert. Thanks for the constructive input.
On Monday, April 11, 2011 03:08:42 PM Greg Freemyer wrote:
So while I like the basic idea Drew has a lot, I'd like to keep to exactly the current numbering for "major releases" and add a 3rd digit for sub-releases.
While I see that your idea with subreleases numbering can easily get traction as it doesn't change what was agreed upon in recent pools, I still consider Drew's idea as final solution to get rid of complex numbering that servers nothing, but to confuse people.
In his proposal minor numbers finally get meaning as usual, minor improvements to base release.
2011/4/11 Greg Freemyer greg.freemyer@gmail.com:
I have openSUSE on several servers. I never even consider upgrading them in the first 2 months of a release, so I certainly understand the difference between the day zero release and a day 60 release + updates.
All old-time users of any distro know this difference. However I believe the effort should be oriented in improving the "0-day" release instead than releasing every two months. In other words, *test* during the development stage. :-)
Then of course, if someone does an unofficial set of releases of this type, it is fine. However there are a lot of solutions that make it much simpler, especially for server use: local patch repo (download one, use forever), if applicable, AutoYaST, or a pre-built image.
Alberto
On Monday, April 11, 2011 09:20:36 PM Alberto Passalacqua wrote:
All old-time users of any distro know this difference. However I believe the effort should be oriented in improving the "0-day" release instead than releasing every two months. In other words, test during the development stage. :-)
You can test it as much as you want, any open source project is notorious producer of patches, in a few months you will have hundreds of megabytes, even when 0 day was perfect, but of course 0 day should be improved.
Hi Rajko,
2011/4/11 Rajko M. rmatov101@charter.net:
You can test it as much as you want, any open source project is notorious producer of patches, in a few months you will have hundreds of megabytes, even when 0 day was perfect, but of course 0 day should be improved.
I don't want to discourage the initiative (as someone might think). My point is that resources in the project are limited, and not that many test the development releases already. This approach will favor that behavior, because two months after release there will be a patched ISO.
In an ideal world ISO's would be updated constantly, but in the real one, where the project struggles to release a good "zero day" (well 11.4 is good :-)), I would really invite who wants to create images with patches to first test milestones, if capable to provide patches, and/or work with developers.
My two cents,
Alberto
Am 11.04.2011 21:44, schrieb Drew Adams:
So in other-words Kim... this is something that is easy to do? If so, it makes the point that, if it is so easy to do, why would we not implement this idea so the community can benafit from someone going through the process you outlined.
Well, it´s not necessary for the project. The most users download the image from download.opensuse.org and update with zypper or the update tool. Then other users remastered openSUSE with SUSE Studio and use *their* version of openSUSE. So why should the project do this, whereas the users, who have the knowledge for that, do it on their own? Another point is, that SUSE Studio & SUSE Gallery give you the chance to download the published appliances or clone them. For me, I personally do some "remastered"-series of openSUSE products (My latest is 11.1 remastered with the almost latest software and bugfixes) and published them to SUSE Galllery so that everybody can download the iso-file and install it.
To come back to your question: It´s not "Why we would not do this?", it´s "Why I haven´t got realized the idea yet?" I think the people at SUSE and Novell and the people who work on openSUSE in their spare time have enough to do, and don´t think about such solutions (If so, please send me a link with the appliance.)
Would there be a better way other than that to achive this idea with KIWI or any other tool to streamline the process?
KIWI is the tool to import your own openSUSE/SUSE-installation to SUSE Studio, right? If you got a up-to-date system that you want to share, it might be better....
thanks
On Monday, April 11, 2011 11:32:35 AM Kim Leyendecker wrote:
Well, this can you have with *SUSE Studio*. Just download the latest packages, create your own repository or load the rpms on a archive up and tick them for being used for your appliance. Then you create a live CD/DVD and go to your friend and install it there.
I don´t see any problem in this
I see the problem.
I make appliance, you make another and hundred other people make their, all the same or with minor changes.
That is 100 times more space and build load to SUSE Studio, then it would be with one time creation of subrelease and publishing it in OBS for everyone.
Not to mention support nightmare where helpers would have to guess what is installed. Although, even now we have problems with unknown system state and no system to solve them.
-
Alberto Passalacqua -
Andreas Jaeger -
Bruno Friedmann -
Drew Adams -
Greg Freemyer -
James Mason -
Kim Leyendecker -
Manu Gupta -
Rajko M.