[opensuse-project] timeline and roadmap
Dear community, The openSUSE team has presented and with you discussed some plans for a more sustainable development project➀. Proposals like working openQA in the openSUSE development workflow, implementing staging projects, making improvements to OBS - and implementing these things will cost a lot of time. Right now, the openSUSE team is or plans to be working on a wide range of things: the openSUSE Conference, the new merchandising program and of course we have the openSUSE release process on our plate. Especially the work on the release takes much time from our team, both in terms of ongoing effort (keep factory working, openQA testing) and of course around the release itself. To implement the proposals we made in a reasonable time frame, we think it makes most sense for us to focus on them. That means, the openSUSE team would work on OBS, openQA etc in a series of sprints over a period of 6-8 months. In that time, we spend little if any time on the release process. Of course, after these changes the team will be back on the job at full speed. What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible. Shoot. What do you think? - The openSUSE Team ➀ http://lists.opensuse.org/opensuse-factory/2013-12/msg00349.html and https://lizards.opensuse.org/2013/12/11/discussing-about-the-future-of-opens...
On Mon, Dec 16, 2013 at 11:32:09AM +0100, Jos Poortvliet wrote:
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible.
I would be happy to help out with the release. Skipping a relase would send a dubious message to our users, it's much better to release it in a simpler form, e.g. with not so many new things. (Hey, releasing some kind of stable update is maybe even what our users want!) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I agree with Michael, skipping a release doesn't send out the right message. A simpler release rather than nothing. On Mon, Dec 16, 2013 at 2:38 PM, Michael Schroeder <mls@suse.de> wrote:
On Mon, Dec 16, 2013 at 11:32:09AM +0100, Jos Poortvliet wrote:
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible.
I would be happy to help out with the release. Skipping a relase would send a dubious message to our users, it's much better to release it in a simpler form, e.g. with not so many new things. (Hey, releasing some kind of stable update is maybe even what our users want!)
Cheers, Michael.
-- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Le lundi 16 décembre 2013 à 14:47 +0400, Ish Sookun a écrit :
I agree with Michael, skipping a release doesn't send out the right message. A simpler release rather than nothing.
You are missing a important point: the amount of work needed to do the release is almost not proportional to the "changes" that goes into the release. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Monday 16 December 2013 12:45:19 Frederic Crozat wrote:
Le lundi 16 décembre 2013 à 14:47 +0400, Ish Sookun a écrit :
I agree with Michael, skipping a release doesn't send out the right message. A simpler release rather than nothing.
You are missing a important point: the amount of work needed to do the release is almost not proportional to the "changes" that goes into the release.
Well, that's not OUR message, although you're not wrong. The thing we set out to do, as Coolo pointed out [1], is to solve some problems that have us chasing our tail all day long. The openSUSE team spends a progressively large portion of its time on 'just keeping things going'. Now that can be enough for some but we'd like to also work on 'extra' things instead of just struggling to keep factory building and getting the iso's out on time. So we came with proposals - which are now being discussed. Some of those proposals will probably be widely considered to be a good idea, others get modified, others get thrown out. That's all fine. But at some point, I do expect we end up with a few plans that we agree are Very Good To Have™. And then - we want to work on implementing them... [1] http://lists.opensuse.org/opensuse-factory/2013-12/msg00358.html
On Mon, Dec 16, 2013 at 12:45:19PM +0100, Frederic Crozat wrote:
Le lundi 16 décembre 2013 à 14:47 +0400, Ish Sookun a écrit :
I agree with Michael, skipping a release doesn't send out the right message. A simpler release rather than nothing.
You are missing a important point: the amount of work needed to do the release is almost not proportional to the "changes" that goes into the release.
What do you mean? The release itself is not that much work. Keeping Factory in a sane state is the time consuming part. And that is also why I don't really understand that "skip a release" talk: the plan is to keep Factory in a good state anyway, right? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Le lundi 16 décembre 2013 à 13:13 +0100, Michael Schroeder a écrit :
On Mon, Dec 16, 2013 at 12:45:19PM +0100, Frederic Crozat wrote:
Le lundi 16 décembre 2013 à 14:47 +0400, Ish Sookun a écrit :
I agree with Michael, skipping a release doesn't send out the right message. A simpler release rather than nothing.
You are missing a important point: the amount of work needed to do the release is almost not proportional to the "changes" that goes into the release.
What do you mean? The release itself is not that much work. Keeping Factory in a sane state is the time consuming part.
Making a release doesn't mean just generating an ISO image, it also mean preparing marketing (writing announcement, etc..), doing a lot of tests (including openQA but not only), work on the repositories, etc (I haven't done any release for openSUSE but I know how much under the work it means, and openSUSE team has done a great job in documenting work needed to do a release). -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, Dec 16, 2013 at 01:33:43PM +0100, Frederic Crozat wrote:
Making a release doesn't mean just generating an ISO image, it also mean preparing marketing (writing announcement, etc..), doing a lot of tests (including openQA but not only)
Marketing/testing is something where anybody can contribute.
work on the repositories, etc (I haven't done any release for openSUSE but I know how much under the work it means, and openSUSE team has done a great job in documenting work needed to do a release).
I know the technical part of doing the release, and I am willing to do that part. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
2013/12/16 Michael Schroeder <mls@suse.de>
On Mon, Dec 16, 2013 at 01:33:43PM +0100, Frederic Crozat wrote:
Making a release doesn't mean just generating an ISO image, it also mean preparing marketing (writing announcement, etc..), doing a lot of tests (including openQA but not only)
Marketing/testing is something where anybody can contribute.
work on the repositories, etc (I haven't done any release for openSUSE but I know how much under the work it means, and openSUSE team has done a great job in documenting work needed to do a release).
I know the technical part of doing the release, and I am willing to do that part.
Cheers, Michael.
Hi, What will the community guys do during this "no Factory time"? For example, what does the KDE/GNOME/etc team will do? Work in the KDE/GNOME version which will not be included in openSUSE? (or at least will not reach much users - addon repos/tumbleweed). Take a 1 year vacation? Release the new versions as updates to 13.1? I think that Michaels idea is a good one. Regards, Luiz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi, On Monday, December 16, 2013 10:40:01 AM Luiz Fernando Ranghetti wrote:
2013/12/16 Michael Schroeder <mls@suse.de>
On Mon, Dec 16, 2013 at 01:33:43PM +0100, Frederic Crozat wrote:
Making a release doesn't mean just generating an ISO image, it also mean preparing marketing (writing announcement, etc..), doing a lot of tests (including openQA but not only)
Marketing/testing is something where anybody can contribute.
work on the repositories, etc (I haven't done any release for openSUSE but I know how much under the work it means, and openSUSE team has done a great job in documenting work needed to do a release).
I know the technical part of doing the release, and I am willing to do that part.
Cheers,
Michael.
Hi,
What will the community guys do during this "no Factory time"? For example, what does the KDE/GNOME/etc team will do? Work in the KDE/GNOME version which will not be included in openSUSE? (or at least will not reach much users - addon repos/tumbleweed). Take a 1 year vacation? Release the new versions as updates to 13.1?
Good questions. Let me rephrase it. How can we work on new things and, at the same time, keep the ship moving? In order to introduce significant changes in factory we need: * Implement them one by one * Look carefully the impact of the introduced changes and refine quickly the possible problems. We all need factory running. But running is one thing, and have it prepared for a Release is another thing, in terms of resources, at least. Tomas (on vacation), Coolo and Ludwig can provide more technical details about this. @Coolo, @Ludwig Will we be able to introduce in factory the desktops in a scenario in which our main focus will be development? Hopefully we will have a "release" in 6/8 months: the new development version... with KDE and GNOME on it. The openSUSE Maintenance Team can provide more details about the possibilities we have in the maintenance area with the current resources. @Marcus, can you provide us light here? Saludos -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, Dec 16, 2013 at 02:43:39PM +0100, Agustin Benito Bethencourt wrote:
Hi,
On Monday, December 16, 2013 10:40:01 AM Luiz Fernando Ranghetti wrote:
2013/12/16 Michael Schroeder <mls@suse.de>
On Mon, Dec 16, 2013 at 01:33:43PM +0100, Frederic Crozat wrote:
Making a release doesn't mean just generating an ISO image, it also mean preparing marketing (writing announcement, etc..), doing a lot of tests (including openQA but not only)
Marketing/testing is something where anybody can contribute.
work on the repositories, etc (I haven't done any release for openSUSE but I know how much under the work it means, and openSUSE team has done a great job in documenting work needed to do a release).
I know the technical part of doing the release, and I am willing to do that part.
Cheers,
Michael.
Hi,
What will the community guys do during this "no Factory time"? For example, what does the KDE/GNOME/etc team will do? Work in the KDE/GNOME version which will not be included in openSUSE? (or at least will not reach much users - addon repos/tumbleweed). Take a 1 year vacation? Release the new versions as updates to 13.1?
Good questions. Let me rephrase it. How can we work on new things and, at the same time, keep the ship moving?
In order to introduce significant changes in factory we need: * Implement them one by one * Look carefully the impact of the introduced changes and refine quickly the possible problems.
We all need factory running.
But running is one thing, and have it prepared for a Release is another thing, in terms of resources, at least. Tomas (on vacation), Coolo and Ludwig can provide more technical details about this.
@Coolo, @Ludwig Will we be able to introduce in factory the desktops in a scenario in which our main focus will be development?
Hopefully we will have a "release" in 6/8 months: the new development version... with KDE and GNOME on it.
The openSUSE Maintenance Team can provide more details about the possibilities we have in the maintenance area with the current resources.
@Marcus, can you provide us light here?
Well, we do push bugfixes and version updates via maintenance already, but the latter only in a small scope. We cannot easily ship new libraries via maintenance, or larger scope restructurings. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Agustin Benito Bethencourt wrote:
On Monday, December 16, 2013 10:40:01 AM Luiz Fernando Ranghetti wrote:
What will the community guys do during this "no Factory time"? For example, what does the KDE/GNOME/etc team will do? Work in the KDE/GNOME version which will not be included in openSUSE? (or at least will not reach much users - addon repos/tumbleweed). Take a 1 year vacation? Release the new versions as updates to 13.1? [...] We all need factory running.
But running is one thing, and have it prepared for a Release is another thing, in terms of resources, at least. Tomas (on vacation), Coolo and Ludwig can provide more technical details about this.
@Coolo, @Ludwig Will we be able to introduce in factory the desktops in a scenario in which our main focus will be development?
Factory keeps going, ie submit requests will still get processed by the Factory maintainers. So yes, the new desktops will be available via Factory if the maintainers submit the packages. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Monday 16 December 2013 13:13:25 Michael Schroeder wrote:
On Mon, Dec 16, 2013 at 12:45:19PM +0100, Frederic Crozat wrote:
Le lundi 16 décembre 2013 à 14:47 +0400, Ish Sookun a écrit :
I agree with Michael, skipping a release doesn't send out the right message. A simpler release rather than nothing.
You are missing a important point: the amount of work needed to do the release is almost not proportional to the "changes" that goes into the release.
What do you mean? The release itself is not that much work. Keeping Factory in a sane state is the time consuming part.
Oh, releasing is a LOT of work, too. Both are ;-)
And that is also why I don't really understand that "skip a release" talk: the plan is to keep Factory in a good state anyway, right?
yes, and to make that possible, we need to build/improve some tools and infrastructure... Chicken-egg, thus.
Cheers, Michael.
Hey, On 16.12.2013 13:13, Michael Schroeder wrote:
On Mon, Dec 16, 2013 at 12:45:19PM +0100, Frederic Crozat wrote:
Le lundi 16 décembre 2013 à 14:47 +0400, Ish Sookun a écrit :
I agree with Michael, skipping a release doesn't send out the right message. A simpler release rather than nothing.
You are missing a important point: the amount of work needed to do the release is almost not proportional to the "changes" that goes into the release.
What do you mean? The release itself is not that much work. Keeping Factory in a sane state is the time consuming part.
[ ] You know what you are talking about. [X] You know only half of it. :-) Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Montag, 16. Dezember 2013, 11:38:23 wrote Michael Schroeder:
On Mon, Dec 16, 2013 at 11:32:09AM +0100, Jos Poortvliet wrote:
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible.
I would be happy to help out with the release. Skipping a relase would send a dubious message to our users, it's much better to release it in a simpler form, e.g. with not so many new things. (Hey, releasing some kind of stable update is maybe even what our users want!)
Just want to agree with Michael here. This sound like you do announce the end of openSUSE as an End-User product here. To avoid this I would also help again with producing an openSUSE release again. Because I do still believe that without the acceptance as end-user product (not equal to a stable developer product) we would loose way to many people. Problem is though that with Michael and me being busy with openSUSE distro, we would not have time for integrating and discussing your OBS ideas at all. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Monday 16 December 2013 13:16:17 Adrian Schröter wrote:
On Montag, 16. Dezember 2013, 11:38:23 wrote Michael Schroeder:
On Mon, Dec 16, 2013 at 11:32:09AM +0100, Jos Poortvliet wrote:
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible.
I would be happy to help out with the release. Skipping a relase would send a dubious message to our users, it's much better to release it in a simpler form, e.g. with not so many new things. (Hey, releasing some kind of stable update is maybe even what our users want!)
Just want to agree with Michael here. This sound like you do announce the end of openSUSE as an End-User product here.
To avoid this I would also help again with producing an openSUSE release again. Because I do still believe that without the acceptance as end-user product (not equal to a stable developer product) we would loose way to many people.
Problem is though that with Michael and me being busy with openSUSE distro, we would not have time for integrating and discussing your OBS ideas at all.
Yeah, that wouldn't help. Thing is - are you sure it would be so bad for users? Note that over half our users hasn't moved to 12.3 yet - let alone 13.1. And a large percentage of our users is still running a release before 12.2 - either evergreen or not supported at all. See https://lizards.opensuse.org/2013/08/23/more-on-statistics/ So I think it is safe to say the majority of our users won't care much about skipping a release. And those who do have plenty of alternatives with OBS and Tumbleweed etc. However, a much more important thing is what Michael said - "Skipping a release would send a dubious message to our users". I agree with that, for certain. Then again, communication is my thing, isn't it? And I believe we have a good story, a good message. Remember, 12.2 had a delay because our processes and tools have not kept up with our growth and ambitions. We have NOT fixed that problem yet - only thrown more manpower at it, at the expense of other things. We're now working on a series of plans to fix that problem and I hope it is clear to everybody that this is needed. in short: I think the numbers show that the real impact on users is limited; especially as we have alternatives. In the area of communication, we have a good story and I think we can get that out in the right way, too. Hugs, J
On Mon, Dec 16, 2013 at 02:48:31PM +0100, Jos Poortvliet wrote:
On Monday 16 December 2013 13:16:17 Adrian Schröter wrote:
Problem is though that with Michael and me being busy with openSUSE distro, we would not have time for integrating and discussing your OBS ideas at all.
Yeah, that wouldn't help.
I sure hope the openSUSE team will not wait until June next year before asking us about the OBS changes they need... ;) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Monday 16 December 2013 15:40:13 Michael Schroeder wrote:
On Mon, Dec 16, 2013 at 02:48:31PM +0100, Jos Poortvliet wrote:
On Monday 16 December 2013 13:16:17 Adrian Schröter wrote:
Problem is though that with Michael and me being busy with openSUSE distro, we would not have time for integrating and discussing your OBS ideas at all.
Yeah, that wouldn't help.
I sure hope the openSUSE team will not wait until June next year before asking us about the OBS changes they need... ;)
Let's say I'm convinced we'll do better in the future for a variety of reasons :D
Cheers, Michael.
On 12/17/2013 12:18 AM, Jos Poortvliet wrote:
On Monday 16 December 2013 13:16:17 Adrian Schröter wrote:
On Montag, 16. Dezember 2013, 11:38:23 wrote Michael Schroeder:
On Mon, Dec 16, 2013 at 11:32:09AM +0100, Jos Poortvliet wrote:
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible. I would be happy to help out with the release. Skipping a relase would send a dubious message to our users, it's much better to release it in a simpler form, e.g. with not so many new things. (Hey, releasing some kind of stable update is maybe even what our users want!) Just want to agree with Michael here. This sound like you do announce the end of openSUSE as an End-User product here.
To avoid this I would also help again with producing an openSUSE release again. Because I do still believe that without the acceptance as end-user product (not equal to a stable developer product) we would loose way to many people.
Problem is though that with Michael and me being busy with openSUSE distro, we would not have time for integrating and discussing your OBS ideas at all. Yeah, that wouldn't help.
Thing is - are you sure it would be so bad for users? Note that over half our users hasn't moved to 12.3 yet - let alone 13.1. And a large percentage of our users is still running a release before 12.2 - either evergreen or not supported at all. See https://lizards.opensuse.org/2013/08/23/more-on-statistics/
So I think it is safe to say the majority of our users won't care much about skipping a release. And those who do have plenty of alternatives with OBS and Tumbleweed etc.
However, a much more important thing is what Michael said - "Skipping a release would send a dubious message to our users". I agree with that, for certain. Then again, communication is my thing, isn't it? And I believe we have a good story, a good message. Remember, 12.2 had a delay because our processes and tools have not kept up with our growth and ambitions. We have NOT fixed that problem yet - only thrown more manpower at it, at the expense of other things. We're now working on a series of plans to fix that problem and I hope it is clear to everybody that this is needed.
in short: I think the numbers show that the real impact on users is limited; especially as we have alternatives. In the area of communication, we have a good story and I think we can get that out in the right way, too.
Hugs, J
I guess looking at it from the outside could you change the release cycle for the next 2 releases to yearly, that would in theory give the team 8 month's (2 lots of 4) to focus on non release work before starting the release process. From a user perspective waiting a year instead of 8 months seems better then skipping a release. If we skip a release we also miss out on all the publicity generated by a release and a release half way through would give a chance to test some of the stuff that had already been done. If it worked for the next 2 releases maybe it cold be kept long term so the tea can keep improving openSUSE. Just my thoughts Simon -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 17.12.2013 23:46, schrieb Simon:
I guess looking at it from the outside could you change the releasen cycle for the next 2 releases to yearly, that would in theory give the team 8 month's (2 lots of 4) to focus on non release work before starting the release process. From a user perspective waiting a year instead of 8 months seems better then skipping a release. If we skip a release we also miss out on all the publicity generated by a release and a release half way through would give a chance to test some of the stuff that had already been done. If it worked for the next 2 releases maybe it cold be kept long term so the tea can keep improving openSUSE.
This is something I considered proposing too, so I support it. The last release in July (12.2) was not our strongest one - you have trouble starting into the new year, then there is the openSUSE conference and suddenly you find yourself in July with a not so great release that no one actually cares for because the journalists are already in summer vacation mode. So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 18 December 2013 07:09:13 Stephan Kulow wrote:
Am 17.12.2013 23:46, schrieb Simon:
I guess looking at it from the outside could you change the releasen cycle for the next 2 releases to yearly, that would in theory give the team 8 month's (2 lots of 4) to focus on non release work before starting the release process. From a user perspective waiting a year instead of 8 months seems better then skipping a release. If we skip a release we also miss out on all the publicity generated by a release and a release half way through would give a chance to test some of the stuff that had already been done. If it worked for the next 2 releases maybe it cold be kept long term so the tea can keep improving openSUSE.
This is something I considered proposing too, so I support it. The last release in July (12.2) was not our strongest one - you have trouble starting into the new year, then there is the openSUSE conference and suddenly you find yourself in July with a not so great release that no one actually cares for because the journalists are already in summer vacation mode.
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October?
Sounds very good to me, too - a October (or November) release is better from a whole bunch of reasons ;-) So, +1
Greetings, Stephan
On 18 December 2013 09:55, Jos Poortvliet <jos@opensuse.org> wrote:
On Wednesday 18 December 2013 07:09:13 Stephan Kulow wrote:
Am 17.12.2013 23:46, schrieb Simon:
I guess looking at it from the outside could you change the releasen cycle for the next 2 releases to yearly, that would in theory give the team 8 month's (2 lots of 4) to focus on non release work before starting the release process. From a user perspective waiting a year instead of 8 months seems better then skipping a release. If we skip a release we also miss out on all the publicity generated by a release and a release half way through would give a chance to test some of the stuff that had already been done. If it worked for the next 2 releases maybe it cold be kept long term so the tea can keep improving openSUSE.
This is something I considered proposing too, so I support it. The last release in July (12.2) was not our strongest one - you have trouble starting into the new year, then there is the openSUSE conference and suddenly you find yourself in July with a not so great release that no one actually cares for because the journalists are already in summer vacation mode.
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October?
Sounds very good to me, too - a October (or November) release is better from a whole bunch of reasons ;-)
So, +1
I've lost count of the times I've suggested a yearly cycle for releases, and Oct/Nov releases always seem to go smoother for us, so +1 for me for 13.2 coming out in October with an expectation that 13.3 would come out October 2015 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Skipping a relase would send a dubious message to our users, it's much better to release it in a simpler form, e.g. with not so many new things
I agree with that and there are some facts that we should consider before moving forward. These facts are the numbers and also some metrics concerning the each release. From my point of view (and research) the number of downloads show as a fact but there other numbers-metrics missing and those are : 1) Number of bug (opened/closed) -- Bug ratio 2) Number of installations/downloads -- Already known 3) Number of Features -- We should measure the number of Feature in each release (release notes could be our friend ;)) These number can be easily "correlated" . For instance we can correlate the number of installations with the number of features and the bug ratio. If in 12.1 we had 100k downloads , 300 features and Bug ratio = 0.60 and in the next release the name of features increases 10 % , the number of downloads decreases 5 % but the bug ratio raises up (e.g 0.70) that should mean that people did not install/upgrade to 12.3 due to the fact that more bugs are opened than closed. More calculations and metrics can be gathered (you can have a look on Eclipse example [1]) but the point is how willing are to use these number in order to decide a possible change in the release cycle of openSUSE...
The last release in July (12.2) was not our strongest one - you have trouble
This fact can be verified from this paper as well [2]. For people who are willing to read more, they could have a look on a very interesting PhD dissertation about release cycle models in FOSS projects [3] (Chapter 3). Geekings, Ilias R. [1] https://polarsys.org/wiki/index.php/EclipseMetrics [2] http://tux.gseis.ucla.edu/WSL2013_papers/Robles_sentiment_analysis_of_openSU... [3] http://www.cyrius.com/publications/michlmayr-phd.pdf On Wed, Dec 18, 2013 at 10:40 AM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 18 December 2013 09:55, Jos Poortvliet <jos@opensuse.org> wrote:
On Wednesday 18 December 2013 07:09:13 Stephan Kulow wrote:
Am 17.12.2013 23:46, schrieb Simon:
I guess looking at it from the outside could you change the releasen cycle for the next 2 releases to yearly, that would in theory give the team 8 month's (2 lots of 4) to focus on non release work before starting the release process. From a user perspective waiting a year instead of 8 months seems better then skipping a release. If we skip a release we also miss out on all the publicity generated by a release and a release half way through would give a chance to test some of the stuff that had already been done. If it worked for the next 2 releases maybe it cold be kept long term so the tea can keep improving openSUSE.
This is something I considered proposing too, so I support it. The last release in July (12.2) was not our strongest one - you have trouble starting into the new year, then there is the openSUSE conference and suddenly you find yourself in July with a not so great release that no one actually cares for because the journalists are already in summer vacation mode.
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October?
Sounds very good to me, too - a October (or November) release is better from a whole bunch of reasons ;-)
So, +1
I've lost count of the times I've suggested a yearly cycle for releases, and Oct/Nov releases always seem to go smoother for us, so +1 for me for 13.2 coming out in October with an expectation that 13.3 would come out October 2015 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- Ilias R. (Zoumpis) -- About Me-- http://zoumpis.wordpress.com https://github.com/athanrous -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 2013-12-18 at 11:45 +0100, Ilias R.(Zoumpis) wrote:
These number can be easily "correlated" . For instance we can correlate the number of installations with the number of features and the bug ratio. If in 12.1 we had 100k downloads , 300 features and Bug ratio = 0.60 and in the next release the name of features increases 10 % , the number of downloads decreases 5 % but the bug ratio raises up (e.g 0.70) that should mean that people did not install/upgrade to 12.3 due to the fact that more bugs are opened than closed. More calculations and metrics can be gathered (you can have a look on Eclipse example [1]) but the point is how willing are to use these number in order to decide a possible change in the release cycle of openSUSE...
I think your logic is based on false assumptions 'Bug ratio' is a useful measure of product quality only when the number of "Bug finders" and "Bug fixers" and their productivity is roughly stable - ie. It works fine in a commercial company where these variables can be controlled and/or measured and therefore factored into your metrics. As we're a volunteer project, that's impossible in our case. Any value in looking at the Bug Ratio is going to be lost in the variable nature of our contributors and their available time to find and/or fix bugs. Bug Ratio goes up? It's just as safe to conclude that "More people are finding bugs rather than fixing them". That does not lead to a safe conclusion that "Product is more buggy" Features also I think is relatively meaningless, as our 'features' are often something we inherit from chosen upstream packages we've been including for a long while. The only 'valid' features I'd think are useful to the kind of analysis you propose are the sort we rarely have, original, openSUSE originated "I have a new idea for a Feature, lets do this". I don't think an Community-driven Open Source project can be effectively modelled by numbers, and I value 'human intelligence', gut feeling, and honest feedback from real people far more than cold hard numbers. Too much numerical navel gazing can often lead to very warped and inappropriate conclusions, we've seen a lot of them lately. I'd like to think we can move forward in a way that reflects we're a community of human beings and not a collection of numbers on a graph :) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 18 December 2013 12:00:41 Richard Brown wrote:
On Wed, 2013-12-18 at 11:45 +0100, Ilias R.(Zoumpis) wrote:
These number can be easily "correlated" . For instance we can correlate the number of installations with the number of features and the bug ratio. If in 12.1 we had 100k downloads , 300 features and Bug ratio = 0.60 and in the next release the name of features increases 10 % , the number of downloads decreases 5 % but the bug ratio raises up (e.g 0.70) that should mean that people did not install/upgrade to 12.3 due to the fact that more bugs are opened than closed. More calculations and metrics can be gathered (you can have a look on Eclipse example [1]) but the point is how willing are to use these number in order to decide a possible change in the release cycle of openSUSE...
I think your logic is based on false assumptions
'Bug ratio' is a useful measure of product quality only when the number of "Bug finders" and "Bug fixers" and their productivity is roughly stable - ie. It works fine in a commercial company where these variables can be controlled and/or measured and therefore factored into your metrics.
As we're a volunteer project, that's impossible in our case. Any value in looking at the Bug Ratio is going to be lost in the variable nature of our contributors and their available time to find and/or fix bugs. Bug Ratio goes up? It's just as safe to conclude that "More people are finding bugs rather than fixing them". That does not lead to a safe conclusion that "Product is more buggy"
Features also I think is relatively meaningless, as our 'features' are often something we inherit from chosen upstream packages we've been including for a long while. The only 'valid' features I'd think are useful to the kind of analysis you propose are the sort we rarely have, original, openSUSE originated "I have a new idea for a Feature, lets do this".
I don't think an Community-driven Open Source project can be effectively modelled by numbers, and I value 'human intelligence', gut feeling, and honest feedback from real people far more than cold hard numbers.
Too much numerical navel gazing can often lead to very warped and inappropriate conclusions, we've seen a lot of them lately. I'd like to think we can move forward in a way that reflects we're a community of human beings and not a collection of numbers on a graph :)
I don't want to piss on numbers TOO MUCH, though - there is information you can get from them. As long as you keep in mind that you have to apply some intelligence to interpreting them to avoid the pitfalls you point at... Things are usually gray. remember ;-) On a personal note, I really appreciate the insights that Ilias has produced in his thesis and with other numbers. I'm sure you and others agree that a graph like these is at the very least motivating: http://susepaste.org/36783018 This one is the direct result of Ilias' hard work, both alone when it comes to gathering the statistics and together with many happy geekos managing our social media accounts http://susepaste.org/54640315 The second graph shows that we've got our marketing in order for the releases - AND that we've reached a plateau, imho, in how much we can improve our marketing for the release. It is time to move marketing efforts in other area's. I've shown the very sad numbers for merchandising and (non-release related) marketing in general. Luckily, our awesome marketing team is working on planning and such (see the ML) - while at SUSE we're preparing a booth box. Hopefully we can start sending materials again in the 2nd or 3rd quarter next year. Better late than never! But now I'm going TERRIBLY off-topic :D
On 18/12/13 12:00, Richard Brown wrote:
On Wed, 2013-12-18 at 11:45 +0100, Ilias R.(Zoumpis) wrote:
These number can be easily "correlated" . For instance we can correlate the number of installations with the number of features and the bug ratio. If in 12.1 we had 100k downloads , 300 features and Bug ratio = 0.60 and in the next release the name of features increases 10 % , the number of downloads decreases 5 % but the bug ratio raises up (e.g 0.70) that should mean that people did not install/upgrade to 12.3 due to the fact that more bugs are opened than closed. More calculations and metrics can be gathered (you can have a look on Eclipse example [1]) but the point is how willing are to use these number in order to decide a possible change in the release cycle of openSUSE...
I think your logic is based on false assumptions
'Bug ratio' is a useful measure of product quality only when the number of "Bug finders" and "Bug fixers" and their productivity is roughly stable - ie. It works fine in a commercial company where these variables can be controlled and/or measured and therefore factored into your metrics.
As we're a volunteer project, that's impossible in our case. Any value in looking at the Bug Ratio is going to be lost in the variable nature of our contributors and their available time to find and/or fix bugs. Bug Ratio goes up? It's just as safe to conclude that "More people are finding bugs rather than fixing them". That does not lead to a safe conclusion that "Product is more buggy"
Features also I think is relatively meaningless, as our 'features' are often something we inherit from chosen upstream packages we've been including for a long while. The only 'valid' features I'd think are useful to the kind of analysis you propose are the sort we rarely have, original, openSUSE originated "I have a new idea for a Feature, lets do this".
I don't think an Community-driven Open Source project can be effectively modelled by numbers, and I value 'human intelligence', gut feeling, and honest feedback from real people far more than cold hard numbers.
Too much numerical navel gazing can often lead to very warped and inappropriate conclusions, we've seen a lot of them lately. I'd like to think we can move forward in a way that reflects we're a community of human beings and not a collection of numbers on a graph :)
+1000 Will -- Will Stephenson SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Richard Brown <RBrownCCB@opensuse.org> [Dec 18. 2013 12:00]:
I don't think an Community-driven Open Source project can be effectively modelled by numbers, and I value 'human intelligence', gut feeling, and honest feedback from real people far more than cold hard numbers.
Too much numerical navel gazing can often lead to very warped and inappropriate conclusions, we've seen a lot of them lately. I'd like to think we can move forward in a way that reflects we're a community of human beings and not a collection of numbers on a graph :)
Richard, while I agree on your statement in general, gut feeling alone does not help to measure improvement. Still we need some kind of measurement in order to judge the effectiveness of any kind of change. This starts with defining a set of measurable indicators, define a baseline (where are these indicators now ?), and a set of goals (where do we want them to be ?). With this in place, start with a small change, measure improvement. Then adapt or do another change, measure again, etc. pp. Note I'm not saying that the indicators need to be numbers. But it need to be something measurable and comparable. Just my $0.02 ;-) Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 18 December 2013 09:55, Jos Poortvliet <jos@opensuse.org> wrote:
On Wednesday 18 December 2013 07:09:13 Stephan Kulow wrote:
Am 17.12.2013 23:46, schrieb Simon:
I guess looking at it from the outside could you change the releasen cycle for the next 2 releases to yearly, that would in theory give the team 8 month's (2 lots of 4) to focus on non release work before starting the release process. From a user perspective waiting a year instead of 8 months seems better then skipping a release. If we skip a release we also miss out on all the publicity generated by a release and a release half way through would give a chance to test some of the stuff that had already been done. If it worked for the next 2 releases maybe it cold be kept long term so the tea can keep improving openSUSE. This is something I considered proposing too, so I support it. The last release in July (12.2) was not our strongest one - you have trouble starting into the new year, then there is the openSUSE conference and suddenly you find yourself in July with a not so great release that no one actually cares for because the journalists are already in summer vacation mode.
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October? Sounds very good to me, too - a October (or November) release is better from a whole bunch of reasons ;-)
So, +1
I've lost count of the times I've suggested a yearly cycle for releases, and Oct/Nov releases always seem to go smoother for us, so +1 for me for 13.2 coming out in October with an expectation that 13.3 would come out October 2015 Hi all, I meant to hit send on this last night but i didn't so apologies i see
On 12/18/2013 08:10 PM, Richard Brown wrote: there was another proposal for a respin since. Another thought i just had that i don't really care about either way. If we were to go to a yearly release why not incorporate 1 or 2 "tumbleweed snapshots". The release schedule could look something like. October openSUSE 14.0 - openSUSE release March openSUSE 14.1 - tumbleweed snapshot 1 July openSUSE 14.2 - tumbleweed snapshot 2 Or alternatively October openSUSE 13.2 - openSUSE release March openSUSE 13.2 sp 1 - tumbleweed snapshot 1 July openSUSE 13.2 sp 2 - tumbleweed snapshot 2 14.0 could also be 14.1 but that doesn't really matter there could equally just be one snapshot. The tumbleweed snapshots would basically be the previous release + tumbleweed to that point on a DVD, the tumbleweed policies would apply as would branding marketing etc. As tumbleweed is used by a large number of people testing shouldn't theoretically be much of a issue. If nothing else it would make life easier for tumbleweed users as hopefully we would be able to get updated video drivers etc, and they wouldn't need to download a DVD install then re download half there system. Cheers Simon -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 19 Dec 2013 07:23:24 +1030 Simon <simon@simotek.net> wrote:
Or alternatively October openSUSE 13.2 - openSUSE release March openSUSE 13.2 sp 1 - tumbleweed snapshot 1 July openSUSE 13.2 sp 2 - tumbleweed snapshot 2
We can use 13.{1,2,3) to mark release and then next two snapshots. That will finally make use of .{1,2,3} in a way that is consistent with other software. There is another reason to release snapshots. People that download CD, or DVD, have huge pile of updates right after installation. Snapshots will cut down on that. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
In data mercoledì 18 dicembre 2013 07:09:13, Stephan Kulow ha scritto:
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October?
Greetings, Stephan
Ok for me but why don't do one or two respin of 13.1 ? I mean a 13.1.1 or 13.1b, that is basically a 13.1 with all updates and maybe some minor upgrades in leaf packages. I'm not sure but you only need to rebuild the media and the ftp tree. No marketing, packaging, pr. Just an "hey! opensuse 13.1 is out !" Daniele. -- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Daniele - 18:44 18.12.13 wrote:
In data mercoledì 18 dicembre 2013 07:09:13, Stephan Kulow ha scritto:
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October?
Greetings, Stephan
Ok for me but why don't do one or two respin of 13.1 ? I mean a 13.1.1 or 13.1b, that is basically a 13.1 with all updates and maybe some minor upgrades in leaf packages.
I'm not sure but you only need to rebuild the media and the ftp tree. No marketing, packaging, pr. Just an "hey! opensuse 13.1 is out !"
Sounds like something like GNOME/KDE Reloaded that can be done easily in SUSE Studio and I think somebody is already doing that... -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
In data mercoledì 18 dicembre 2013 20:02:21, Michal Hrusecky ha scritto:
Daniele - 18:44 18.12.13 wrote:
In data mercoledì 18 dicembre 2013 07:09:13, Stephan Kulow ha scritto:
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October?
Greetings, Stephan
Ok for me but why don't do one or two respin of 13.1 ? I mean a 13.1.1 or 13.1b, that is basically a 13.1 with all updates and maybe some minor upgrades in leaf packages.
I'm not sure but you only need to rebuild the media and the ftp tree. No marketing, packaging, pr. Just an "hey! opensuse 13.1 is out !"
Sounds like something like GNOME/KDE Reloaded that can be done easily in SUSE Studio and I think somebody is already doing that... Something more and a "respin by me" does not worth like "openSUSE 13.1.1".
Bye. -- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Daniele - 19:09 19.12.13 wrote:
In data mercoledì 18 dicembre 2013 20:02:21, Michal Hrusecky ha scritto:
Daniele - 18:44 18.12.13 wrote:
In data mercoledì 18 dicembre 2013 07:09:13, Stephan Kulow ha scritto:
So with the additional risks involved with others taking over the tasks the openSUSE team did for the last releases, it's not too unlikely the same slip might happen again - so why not plan with it and always release in October?
Greetings, Stephan
Ok for me but why don't do one or two respin of 13.1 ? I mean a 13.1.1 or 13.1b, that is basically a 13.1 with all updates and maybe some minor upgrades in leaf packages.
I'm not sure but you only need to rebuild the media and the ftp tree. No marketing, packaging, pr. Just an "hey! opensuse 13.1 is out !"
Sounds like something like GNOME/KDE Reloaded that can be done easily in SUSE Studio and I think somebody is already doing that...
Something more and a "respin by me" does not worth like "openSUSE 13.1.1".
What more? Respin by that cool guy if marketing is behind him... -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
"Jos" == Jos Poortvliet <jospoortvliet@gmail.com> writes:
Jos> Dear community, Jos> The openSUSE team has presented and with you discussed some plans for a more Jos> sustainable development project➀. Proposals like working openQA in the Jos> openSUSE development workflow, implementing staging projects, making Jos> improvements to OBS - and implementing these things will cost a lot of time. Jos> Right now, the openSUSE team is or plans to be working on a wide Jos> range of things: the openSUSE Conference, the new merchandising Jos> program and of course we have the openSUSE release process on our Jos> plate. Especially the work on the release takes much time from our Jos> team, both in terms of ongoing effort (keep factory working, openQA Jos> testing) and of course around the release itself. Jos> To implement the proposals we made in a reasonable time frame, we Jos> think it makes most sense for us to focus on them. That means, the Jos> openSUSE team would work on OBS, openQA etc in a series of sprints Jos> over a period of 6-8 months. In that time, we spend little if any Jos> time on the release process. Of course, after these changes the team Jos> will be back on the job at full speed. Jos> What does this mean for the project? Either the release should be Jos> done by others or in another way, or openSUSE will essentially skip a Jos> release. The project can still get updates to its users - there is Jos> tumbleweed and OBS of course, and perhaps we can do a simpler/preview Jos> release. Many things are possible. Jos> Shoot. What do you think? How about providing an executive summary for each of the proposals sent by the team. I may have missed but I do not recall any fixed agreements that the community reached. Thanks Togan -- Life is endless possibilities -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Monday 16 December 2013 12:16:59 Togan Muftuoglu wrote:
"Jos" == Jos Poortvliet <jospoortvliet@gmail.com> writes: Jos> Dear community, Jos> The openSUSE team has presented and with you discussed some plans for a more Jos> sustainable development project➀. Proposals like working openQA in the Jos> openSUSE development workflow, implementing staging projects, making Jos> improvements to OBS - and implementing these things will cost a lot of time.
Jos> Right now, the openSUSE team is or plans to be working on a wide Jos> range of things: the openSUSE Conference, the new merchandising Jos> program and of course we have the openSUSE release process on our Jos> plate. Especially the work on the release takes much time from our Jos> team, both in terms of ongoing effort (keep factory working, openQA Jos> testing) and of course around the release itself.
Jos> To implement the proposals we made in a reasonable time frame, we Jos> think it makes most sense for us to focus on them. That means, the Jos> openSUSE team would work on OBS, openQA etc in a series of sprints Jos> over a period of 6-8 months. In that time, we spend little if any Jos> time on the release process. Of course, after these changes the team Jos> will be back on the job at full speed.
Jos> What does this mean for the project? Either the release should be Jos> done by others or in another way, or openSUSE will essentially skip a Jos> release. The project can still get updates to its users - there is Jos> tumbleweed and OBS of course, and perhaps we can do a simpler/preview Jos> release. Many things are possible.
Jos> Shoot. What do you think?
How about providing an executive summary for each of the proposals sent by the team. I may have missed but I do not recall any fixed agreements that the community reached.
For links to the proposals, see the links I gave on the bottom. I'm not saying we have agreement, on either proposals or strategy. When it comes to decision making - that is of course not done. But many people seem to agree that something needs to be done in a variety of areas - so it is good to think about the consequences of that. We can't do this stuff 'on the side', at least - not if we want to benefit from it before the decade is over :D /J
Thanks
Togan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16.12.2013 13:02, Jos Poortvliet wrote:
For links to the proposals, see the links I gave on the bottom.
I'm not saying we have agreement, on either proposals or strategy. When it comes to decision making - that is of course not done. But many people seem to agree that something needs to be done in a variety of areas - so it is good to think about the consequences of that. We can't do this stuff 'on the side', at least - not if we want to benefit from it before the decade is over :D
I think we should agree on doing Factory aside for the next months and revisit in april the state of it to see if we can release it. If Adrian, Michael and others agree to put more effort in having openSUSE releaseable, it's perfectly reasonable that we can release something. If we keep up the effort level in twitter and articles I leave up to the experts - if the numbers say people don't care, perhaps we should listen ;) Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSrxRzwFSBhlBjoJYRApaiAJ0aGoFmOtoiPS2QVFenMkLhU8WDAQCeKInW dAPn0rrEPuOWTiCTS1fJUco= =z/Oa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 16/12/13 15:55, Stephan Kulow wrote:
On 16.12.2013 13:02, Jos Poortvliet wrote:
For links to the proposals, see the links I gave on the bottom.
I'm not saying we have agreement, on either proposals or strategy. When it comes to decision making - that is of course not done. But many people seem to agree that something needs to be done in a variety of areas - so it is good to think about the consequences of that. We can't do this stuff 'on the side', at least - not if we want to benefit from it before the decade is over :D
I think we should agree on doing Factory aside for the next months and revisit in april the state of it to see if we can release it.
If Adrian, Michael and others agree to put more effort in having openSUSE releaseable, it's perfectly reasonable that we can release something.
I'd also like to step up for the 'shadow openSUSE team' when release time runs around. As Jos' backup for 12.2 and 12.3 PR I should be able to organise articles and feature lists. Will -- Will Stephenson SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
That means, the openSUSE team
would work on OBS, openQA etc in a series of sprints over a period of 6-8 months. In that time, we spend little if any time on the release process. Of course, after these changes the team will be back on the job at full speed.
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible.
Shoot. What do you think?
Jos, What is the proposed status of factory for the next 15 months? Tumbleweed for instance currently depends on factory as a place to cherry pick packages from. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Greg Freemyer wrote:
What is the proposed status of factory for the next 15 months?
Tumbleweed for instance currently depends on factory as a place to cherry pick packages from.
Factory won't stop or get worse than it is today so Tumbleweed can continue to work as it always did. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Le 16/12/2013 11:32, Jos Poortvliet a écrit :
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The
I'm a bit surprised by this post, coming *after* all the proposals done on this "project" list. shouldn't this have been done *before*? It's perfectly OK IMHO to say: we should stop moving and organise better, but then what is the matter of the questions asked since 15 days? I'm not subscribed on factory, not a developper, I only can help for marketting or text writing... may I also add than I was surprised to see in the recent days pretty significant differences in position from people all having suse related signatures. May be it's in fact time to stop moving in too man y directions and seriously discuss how openSUSE can be organised *as a hole project*. If this discussion is done (in a positive and solution oriented manner) the release date have little importance. sincerely jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi, On Monday, December 16, 2013 08:05:15 PM jdd wrote:
Le 16/12/2013 11:32, Jos Poortvliet a écrit :
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The
I'm a bit surprised by this post, coming *after* all the proposals done on this "project" list.
shouldn't this have been done *before*?
talking about efforts and timelines are better understood, in my opinion, if you know what are you willing to work on.
It's perfectly OK IMHO to say: we should stop moving and organise better, but then what is the matter of the questions asked since 15 days?
I'm not subscribed on factory, not a developper, I only can help for marketting or text writing...
may I also add than I was surprised to see in the recent days pretty significant differences in position from people all having suse related signatures.
Is this a bad thing in your opinion? Agustin -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Le 17/12/2013 12:08, Agustin Benito Bethencourt a écrit :
Hi,
On Monday, December 16, 2013 08:05:15 PM jdd wrote:
may I also add than I was surprised to see in the recent days pretty significant differences in position from people all having suse related signatures.
Is this a bad thing in your opinion?
yes and no. no because everybody is allowed to give his opinion :-) yes because the openSUSE team is (one of?) the main openSUSE support and if there is not a minium agreement, this is a problem. the last weeks discussions seems to show openSUSE is trying to eat a too big fish. So make a stop and think is a good idea. what could be done is: * inventory of all tasks and who do them right now * try to find a way to have them done by somebody else or decide they are not to be continued * then and only then see if other tasks can be also done for example, I thouhgt of reviving weekly news, but may be I can help in something more urgently needed :-) being back after a two years break I wonder why all this was not discussed at OSC13? thanks anyway for having made this publicly available jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 12/16/2013 05:32 AM, Jos Poortvliet wrote:
Dear community,
The openSUSE team has presented and with you discussed some plans for a more sustainable development project➀. Proposals like working openQA in the openSUSE development workflow, implementing staging projects, making improvements to OBS - and implementing these things will cost a lot of time.
Right now, the openSUSE team is or plans to be working on a wide range of things: the openSUSE Conference, the new merchandising program and of course we have the openSUSE release process on our plate. Especially the work on the release takes much time from our team, both in terms of ongoing effort (keep factory working, openQA testing) and of course around the release itself.
To implement the proposals we made in a reasonable time frame, we think it makes most sense for us to focus on them. That means, the openSUSE team would work on OBS, openQA etc in a series of sprints over a period of 6-8 months. In that time, we spend little if any time on the release process. Of course, after these changes the team will be back on the job at full speed.
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible.
Shoot. What do you think?
I think the "stop what we're doing and do something different" approach has a bad track record. Over the last 1-2 years this approach has been used in a number of areas and the results have not been very satisfactory. Following the same approach is therefore, probably not the direction that will inspire much confidence that things will actually "get better." On the numbers side I tend to lean towards Richard's direction. Just relying on the numbers and boldly proclaiming that "So I think it is safe to say the majority of our users won't care much about skipping a release" neglects the fact that people cannot be summed in up in simple mathematical equations. That what we are doing is not a zero sum game. Although a given user my not upgrade a given machine that does not imply that a regular release cycle is not important to that user. The reasons for not upgrading are probably as diverse as the users we have and say nothing about the importance of having a regular cadence for the releases, rather than "randomly" deciding to skipping a release. I very much like the more moderate and measured approach Stephan has proposed of running things in parallel and taking a state of affairs early next year March/April to see where we are with the next release. If we succeed with the "more stable factory" idea it should have a positive effect on shortening the end game of the release process. Maybe we can also get more people involved now that many things have been enumerated in progress that were previously opaque. We can also take another look at the testing effort that has significantly increased over the last couple of releases. We all know that in the software world one can very easily get roped into testing nirvana but that returns on that investment are diminishing and do not justify the ever increasing effort required. I think 13.1 is a very good case study in that area. I think we will have more success with a more moderate approach that lets things run in parallel. If the changes we are talking about take 3 or 4 years instead of 1 year, is that really a big deal? Obviously some things are more pressing than others, like generating some relieve in the release process and making the busfactor greater than 1. Many of our problems are still rooted in accessibility of information and visibility of stuff that needs to get done, IMHO. For most people it is still difficult to understand/figure out how a release gets out the door and all the things that go into the process, plus how they can potentially contribute one piece of the puzzle. While there's been an effort to lift the veil, more work is necessary. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Robert Schweikert wrote:
Many of our problems are still rooted in accessibility of information and visibility of stuff that needs to get done, IMHO. For most people it is still difficult to understand/figure out how a release gets out the door and all the things that go into the process, plus how they can potentially contribute one piece of the puzzle. While there's been an effort to lift the veil, more work is necessary.
Couldn't agree more. -- Per Jessen, Zürich (-0.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 30 Dec 2013 21:12:33 +0100, Per Jessen wrote:
Robert Schweikert wrote:
Many of our problems are still rooted in accessibility of information and visibility of stuff that needs to get done, IMHO. For most people it is still difficult to understand/figure out how a release gets out the door and all the things that go into the process, plus how they can potentially contribute one piece of the puzzle. While there's been an effort to lift the veil, more work is necessary.
Couldn't agree more.
Same here. Is there a checklist that's used by the team that handles the release that could be cleaned up and posted somewhere? I'd be really surprised if each release is handled without some sort of even rudimentary checklist. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 12/30/2013 10:03 PM, Jim Henderson wrote:
On Mon, 30 Dec 2013 21:12:33 +0100, Per Jessen wrote:
Robert Schweikert wrote:
Many of our problems are still rooted in accessibility of information and visibility of stuff that needs to get done, IMHO. For most people it is still difficult to understand/figure out how a release gets out the door and all the things that go into the process, plus how they can potentially contribute one piece of the puzzle. While there's been an effort to lift the veil, more work is necessary. Couldn't agree more. Same here. Is there a checklist that's used by the team that handles the release that could be cleaned up and posted somewhere?
Yes, there is. https://progress.opensuse.org/projects/opensuse-13-1-release/issues?f[]=status_id&op[status_id]=* Cheers. -- Ancor González Sosa openSUSE Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 30/12/13 21:11, Ancor Gonzalez Sosa wrote:
Same here. Is there a checklist that's used by the team that handles the
release that could be cleaned up and posted somewhere? Yes, there is.
https://progress.opensuse.org/projects/opensuse-13-1-release/issues?f[]=status_id&op[status_id]=*
Cheers.
That doesn't seem like a 'Checklist' to me (a list of actions that can/must be repeated to achieve completion in a Task), but an collection of tasks which appears to be added to in an ad-hoc fashion Useful, but I don't think it addresses Jim's request for a clear picture of what work is required every release (as opposed to unexpected tasks that were specific to this last one) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 30 Dec 2013 22:13:58 +0000, Richard Brown wrote:
On 30/12/13 21:11, Ancor Gonzalez Sosa wrote:
Same here. Is there a checklist that's used by the team that handles the
release that could be cleaned up and posted somewhere? Yes, there is.
https://progress.opensuse.org/projects/opensuse-13-1-release/issues?f []=status_id&op[status_id]=*
Cheers.
That doesn't seem like a 'Checklist' to me (a list of actions that can/must be repeated to achieve completion in a Task), but an collection of tasks which appears to be added to in an ad-hoc fashion
Useful, but I don't think it addresses Jim's request for a clear picture of what work is required every release (as opposed to unexpected tasks that were specific to this last one)
Yes, it is useful, but it isn't a structured process (as you said, Richard). Most complex software that goes through a alpha/beta/rc/ release cycle has a more formal process than just an issues list. I'm probably singing to the choir here, but to be useful, a process needs to be repeatable - and all but the simplest processes need to be documented in order to be repeatable. We certainly don't need something that's ISO-9001 certified in terms of process, but the old adage "plan your work, and then work your plan" comes to mind. I'm pretty sure there is something a bit more formal, because there are groups (like the press) that get their hands on the GM before general release in order to be prepared with articles and to support the release. But overall, I think the project could use better-documented processes. We talked about 12-18 months ago (maybe longer, time seems to have gone more quickly) about documenting bug reporting processes and such, and I was going to try to pull something together, but paid work got in the way and the project fizzled out. I'm hoping in 2014 to be back to working some sort of "regular" job so my free time is more predictable, and hopefully I can pick that back up again (along with a few other projects that I'd been working on that have stalled). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Monday 30 December 2013 22:32:05 Jim Henderson wrote:
On Mon, 30 Dec 2013 22:13:58 +0000, Richard Brown wrote:
On 30/12/13 21:11, Ancor Gonzalez Sosa wrote:
Same here. Is there a checklist that's used by the team that handles the
release that could be cleaned up and posted somewhere?
Yes, there is.
https://progress.opensuse.org/projects/opensuse-13-1-release/issues?f
[]=status_id&op[status_id]=*
Cheers.
That doesn't seem like a 'Checklist' to me (a list of actions that can/must be repeated to achieve completion in a Task), but an collection of tasks which appears to be added to in an ad-hoc fashion
Useful, but I don't think it addresses Jim's request for a clear picture of what work is required every release (as opposed to unexpected tasks that were specific to this last one)
Yes, it is useful, but it isn't a structured process (as you said, Richard). Most complex software that goes through a alpha/beta/rc/ release cycle has a more formal process than just an issues list.
I'm probably singing to the choir here, but to be useful, a process needs to be repeatable - and all but the simplest processes need to be documented in order to be repeatable.
We certainly don't need something that's ISO-9001 certified in terms of process, but the old adage "plan your work, and then work your plan" comes to mind. I'm pretty sure there is something a bit more formal, because there are groups (like the press) that get their hands on the GM before general release in order to be prepared with articles and to support the release.
But overall, I think the project could use better-documented processes. We talked about 12-18 months ago (maybe longer, time seems to have gone more quickly) about documenting bug reporting processes and such, and I was going to try to pull something together, but paid work got in the way and the project fizzled out. I'm hoping in 2014 to be back to working some sort of "regular" job so my free time is more predictable, and hopefully I can pick that back up again (along with a few other projects that I'd been working on that have stalled).
If you follow the openSUSE factory list or read our openSUSE team blog, you'd know we extensively documented our development- and release processes; they are on the wiki: https://en.opensuse.org/openSUSE:Release_process https://en.opensuse.org/openSUSE:Factory_development_model https://en.opensuse.org/openSUSE:Development_Process And indeed, the vast majority of tasks is described and planned on redmine.
Jim
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sat, 04 Jan 2014 19:03:18 +0100, Jos Poortvliet wrote:
If you follow the openSUSE factory list or read our openSUSE team blog, you'd know we extensively documented our development- and release processes; they are on the wiki:
https://en.opensuse.org/openSUSE:Release_process https://en.opensuse.org/openSUSE:Factory_development_model https://en.opensuse.org/openSUSE:Development_Process
And indeed, the vast majority of tasks is described and planned on redmine.
Thanks, Jos - I haven't followed the factory list very closely and wasn't aware of the team blog. Thanks for the references. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 12/30/2013 11:13 PM, Richard Brown wrote:
On 30/12/13 21:11, Ancor Gonzalez Sosa wrote:
Same here. Is there a checklist that's used by the team that handles the
release that could be cleaned up and posted somewhere? Yes, there is.
https://progress.opensuse.org/projects/opensuse-13-1-release/issues?f[]=status_id&op[status_id]=*
Cheers.
That doesn't seem like a 'Checklist' to me (a list of actions that can/must be repeated to achieve completion in a Task), but an collection of tasks which appears to be added to in an ad-hoc fashion
Useful, but I don't think it addresses Jim's request for a clear picture of what work is required every release (as opposed to unexpected tasks that were specific to this last one)
In fact, some tasks are added "on demand" to react to some situation, but the core of tasks are created, scheduled and assigned in advance from the very first day, with the previous release as template. Maybe it looks better like this: https://progress.opensuse.org/projects/opensuse-13-1-release/roadmap?complet... Or like this (in which is easier to appreciate the relation between tasks): https://progress.opensuse.org/projects/opensuse-13-1-release/issues/gantt?utf8=%E2%9C%93&set_filter=1&f[]=&months=8&month=4&year=2013 Cheers. -- Ancor González Sosa openSUSE Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
participants (27)
-
Adrian Schröter -
Agustin Benito Bethencourt -
Ancor Gonzalez Sosa -
Daniele -
Frederic Crozat -
Greg Freemyer -
Henne Vogelsang -
Ilias R.(Zoumpis) -
Ish Sookun -
jdd -
Jim Henderson -
Jos Poortvliet -
Jos Poortvliet -
Klaus Kaempf -
Ludwig Nussel -
Luiz Fernando Ranghetti -
Marcus Meissner -
Michael Schroeder -
Michal Hrusecky -
Per Jessen -
Rajko -
Richard Brown -
Robert Schweikert -
Simon -
Stephan Kulow -
Togan Muftuoglu -
Will Stephenson