[opensuse-project] 12.3 Schedule and development
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment? Every time I've been involved in a project without a schedule, we've had a long period of (probably highly satisfying for developers) of 'undirected hacking' followed by crisis, followed by a rush to 'get it out before people forget who we are' which inevitably had some fallout (I'm thinking of the period leading up to KDE 4.0 here ;). So I'd like to start the discussion now before we lose a month waiting to discuss it at osc12, where only a fraction of the active members of the project are is going to be present anyway. You don't want everything to be decided by German Engineers* for you do you? Some ideas to start the ball rolling: * openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates * openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip * Extend the release cycle keeping same process and longer stabilization period (effective 12.2 release process; leads to shipping 'outdated' stuff) * Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these Please, save your 'my vote is for this' type of replies. And if you're an armchair general willing to type paragraphs of email here but not a single OBS checkin, meeting participaton or wiki update to 12.3, go do something more pleasurable with your fingers instead. This discussion is not about your favourite kind of icecream, as if that will change anything. This need a reasoned discussion on what to do in future, to get a majority of the actors in the project to agree to act together, and then action. Otherwise we will default to an arbitrary schedule, several months of undirected hacking and taking what comes from upstream, reactive release management to get the result bootable and not too likely to blow up in users' faces, and frantic analysis of the brew by -marketing to make it sound like a consistent whole offering an attractive narrative of improvement (Guess what I did for the last few weeks). Will (* Something Pascal was moping about on IRC last week, I'm hoping to tempt him out of his cave) -- Will Stephenson, openSUSE Board, Booster, KDE Developer 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 11.09.2012 11:23, Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment?
Every time I've been involved in a project without a schedule, we've had a long period of (probably highly satisfying for developers) of 'undirected hacking' followed by crisis, followed by a rush to 'get it out before people forget who we are' which inevitably had some fallout (I'm thinking of the period leading up to KDE 4.0 here ;).
Hi, Good idea, let's see what comes out of it - it's actually the first time in my memory where I didn't have to boss the list around to come up with some *reactions* about proposed release schedules.
So I'd like to start the discussion now before we lose a month waiting to discuss it at osc12, where only a fraction of the active members of the project are is going to be present anyway. You don't want everything to be decided by German Engineers* for you do you?
Some ideas to start the ball rolling:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
Aehm, March is 6 months away and that might be a short cycle for openSUSE, it's a business as usual for many other distributions. This would be my choice - especially as factory development already happened during 12.2 release. E.g. we integrated a new kernel, a new texlive, two new KDE versions, ... basically all before 12.2 was out.
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
And then? This is the biggest question in this concept - Release 13.1 in January 2014? No, thanks. - Release always in may afterwards with tumbleweed included in the process? Possible, but will need more drastic changes and I'm not sure we're there yet
* Extend the release cycle keeping same process and longer stabilization period (effective 12.2 release process; leads to shipping 'outdated' stuff)
12.2 has no outdated stuff, it has tested stuff. I beg to differ. But the stabilization period was not the problem with 12.2, the problem was that the time before that was for many "undirected hacking" and it was up to very few to get it together. A tendency that happens with long schedules I'm afraid.
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
As much as I like feature driven releases, they are just not relatistic to agree on in the project we're in. No matter what schedule we had in the past, there were always the voices to delay for X or Y. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 11 September 2012 10:36, Stephan Kulow <coolo@suse.de> wrote:
On 11.09.2012 11:23, Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment?
Every time I've been involved in a project without a schedule, we've had a long period of (probably highly satisfying for developers) of 'undirected hacking' followed by crisis, followed by a rush to 'get it out before people forget who we are' which inevitably had some fallout (I'm thinking of the period leading up to KDE 4.0 here ;).
Hi,
Good idea, let's see what comes out of it - it's actually the first time in my memory where I didn't have to boss the list around to come up with some *reactions* about proposed release schedules.
So I'd like to start the discussion now before we lose a month waiting to discuss it at osc12, where only a fraction of the active members of the project are is going to be present anyway. You don't want everything to be decided by German Engineers* for you do you?
Some ideas to start the ball rolling:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
Aehm, March is 6 months away and that might be a short cycle for openSUSE, it's a business as usual for many other distributions. This would be my choice - especially as factory development already happened during 12.2 release. E.g. we integrated a new kernel, a new texlive, two new KDE versions, ... basically all before 12.2 was out.
OK so what you're saying is we have until the end of September to make our mind up, and look to release in March - effectively a 7month cycle taking into account that Factory has already bumped versions etc? This deviates from what the original plan was for 12.2 - 8 month cycle. One of the advantages that our peers have is predictability, you know what month a Fedora or Ubuntu release will be in and can plan accordingly, if we start shuffling lead times people will get confused and switch off.
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
And then? This is the biggest question in this concept - Release 13.1 in January 2014? No, thanks. - Release always in may afterwards with tumbleweed included in the process? Possible, but will need more drastic changes and I'm not sure we're there yet
* Extend the release cycle keeping same process and longer stabilization period (effective 12.2 release process; leads to shipping 'outdated' stuff)
12.2 has no outdated stuff, it has tested stuff. I beg to differ. But the stabilization period was not the problem with 12.2, the problem was that the time before that was for many "undirected hacking" and it was up to very few to get it together. A tendency that happens with long schedules I'm afraid.
Is it feasible to have an alternating schedule? As in .1 8month, .2 6month, .3 8month?
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
As much as I like feature driven releases, they are just not relatistic to agree on in the project we're in. No matter what schedule we had in the past, there were always the voices to delay for X or Y.
We will never be able to fit in all feature releases at the same time, so I don't think this is a good approach. Having a schedule that we stick to and leverage things like Tumbleweed and re-spins/key repos should catch most things. The key is to set a time scale and stick to it. Just my tuppence haypenny's worth. Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 11 Sep 2012 11:36:59 Stephan Kulow wrote:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
Aehm, March is 6 months away and that might be a short cycle for openSUSE, it's a business as usual for many other distributions. This would be my choice - especially as factory development already happened during 12.2 release. E.g. we integrated a new kernel, a new texlive, two new KDE versions, ... basically all before 12.2 was out.
My bad, it was a long night last night. 6 Month cycle.
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
And then? This is the biggest question in this concept - Release 13.1 in January 2014? No, thanks. - Release always in may afterwards with tumbleweed included in the process? Possible, but will need more drastic changes and I'm not sure we're there yet
* Extend the release cycle keeping same process and longer stabilization period (effective 12.2 release process; leads to shipping 'outdated' stuff)
12.2 has no outdated stuff, it has tested stuff. I beg to differ. But the stabilization period was not the problem with 12.2, the problem was that the time before that was for many "undirected hacking" and it was up to very few to get it together. A tendency that happens with long schedules I'm afraid.
Agreed, 'outdated' is just how your 'tested' gets perceived by the press and users.
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
As much as I like feature driven releases, they are just not relatistic to agree on in the project we're in. No matter what schedule we had in the past, there were always the voices to delay for X or Y.
I'll read that as "realistic" - although I would like to know what a relativistic release process would look like ;). Having some kind of feature planning is one area where I grudgingly envy Fedora (and to a lesser extent Ubuntu, although planning by diktat is easy). I don't want to break the discipline given by a time-based release, but I naively believe that the teams in the project can state what their upstreams will deliver, plus what they would like to engineer themselves, assign people to those and coordinate the impact with other teams, in a more structured way than mentioning something on -factory and then submitting an implementation to o:F at some later date. But I'm not arguing for some suffocating product design process either. Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer 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 2012/09/11 12:08 (GMT+0200) Will Stephenson composed:
12.2 has no outdated stuff, it has tested stuff.
Agreed, 'outdated' is just how your 'tested' gets perceived by the press and users.
Particularly when bugfix releases made prior to version freeze don't get into the distro. Has anyone ever entertained the notion of a dual release system, where the initial release would be English only, followed as many weeks later as prudent by another with no changes other than localizations? To me, lead time for localizing is too long, leading to too many cases of stale versions in the GM release. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/11/2012 11:23 AM, Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment?
Every time I've been involved in a project without a schedule, we've had a long period of (probably highly satisfying for developers) of 'undirected hacking' followed by crisis, followed by a rush to 'get it out before people forget who we are' which inevitably had some fallout (I'm thinking of the period leading up to KDE 4.0 here ;).
Man plans God laughs but anyway
So I'd like to start the discussion now before we lose a month waiting to discuss it at osc12, where only a fraction of the active members of the project are is going to be present anyway. You don't want everything to be decided by German Engineers* for you do you?
Some ideas to start the ball rolling:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
Do you think that would give enough time so cease out sysV-init and switch to systemd without major headaches ???
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
That would also give some breathing zone to the release team. However if we can have Factory in such a stage that it is not broken by major players (ie. gcc-XYZ glibc-XXX), then release should not be an issue. But the release team should have some room to breathe in between the releases. Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday, September 11, 2012 11:45:14 Togan Muftuoglu wrote:
[...] That would also give some breathing zone to the release team. However if we can have Factory in such a stage that it is not broken by major players (ie. gcc-XYZ glibc-XXX), then release should not be an issue.
We updated already glibc - and I don't think it cased any issues... With separate staging projects, we can do this. But yes, it needs planning and might need some process changes to avoid breakage, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/11/2012 12:03 PM, Andreas Jaeger wrote:
On Tuesday, September 11, 2012 11:45:14 Togan Muftuoglu wrote:
[...] That would also give some breathing zone to the release team. However if we can have Factory in such a stage that it is not broken by major players (ie. gcc-XYZ glibc-XXX), then release should not be an issue.
We updated already glibc - and I don't think it cased any issues...
The names were just examples not that glibc caused an issue.
With separate staging projects, we can do this. But yes, it needs planning and might need some process changes to avoid breakage,
That was what I meant Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday, September 11, 2012 11:23:19 Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment?
Every time I've been involved in a project without a schedule, we've had a long period of (probably highly satisfying for developers) of 'undirected hacking' followed by crisis, followed by a rush to 'get it out before people forget who we are' which inevitably had some fallout (I'm thinking of the period leading up to KDE 4.0 here ;).
So I'd like to start the discussion now before we lose a month waiting to discuss it at osc12, where only a fraction of the active members of the project are is going to be present anyway. You don't want everything to be decided by German Engineers* for you do you?
Some ideas to start the ball rolling:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
We already have many changes in Factory, so it's more than 4 months of development.
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
We've done the 8months cycle with these months so that it rolls perfectly round. If we stay with 8months and go to May it's: May, January, September. And January and September are both bad months for releases since the months before nothing happens.
* Extend the release cycle keeping same process and longer stabilization period (effective 12.2 release process; leads to shipping 'outdated' stuff)
We always tried extending the release cycle - let's fix the problems and not extend it any further.
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
Independed on the schedule, I think it's a good idea to discuss what features we do for the next release. The systemd discussion on opensuse- factory already lead to this webpage: http://en.opensuse.org/openSUSE:Goals_12.3 I'm fine with some more planning and goals. It's not only shipping what upstream delivers but also changing defaults and how to integrate upstream stuff. BUT I see one project that IMO needs to be in the next release - UEFI secure boot. I would make a schedule that allows that one to go in and even slip if it's not in. So the question to Olaf and Vojtech: When do you expect that we have something in openSUSE? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 11 Sep 2012 11:53:08 Andreas Jaeger wrote:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
We already have many changes in Factory, so it's more than 4 months of development.
:D
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
We've done the 8months cycle with these months so that it rolls perfectly round. If we stay with 8months and go to May it's: May, January, September. And January and September are both bad months for releases since the months before nothing happens.
A very good reason for keeping and sticking to the cycle we have, and one that that people easily forget.
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
Independed on the schedule, I think it's a good idea to discuss what features we do for the next release. The systemd discussion on opensuse- factory already lead to this webpage: http://en.opensuse.org/openSUSE:Goals_12.3
Takeaway from that to all teams: discuss your goals for 12.3 on Factory then add the outcome to that page; it's all the process we have for now.
I'm fine with some more planning and goals. It's not only shipping what upstream delivers but also changing defaults and how to integrate upstream stuff.
BUT I see one project that IMO needs to be in the next release - UEFI secure boot. I would make a schedule that allows that one to go in and even slip if it's not in. So the question to Olaf and Vojtech: When do you expect that we have something in openSUSE?
Coolo: QED ;) AJ: why is this so important that you would sacrifice the time based release? Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer 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 Tuesday, September 11, 2012 12:31:57 Will Stephenson wrote:
On Tuesday 11 Sep 2012 11:53:08 Andreas Jaeger wrote:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
We already have many changes in Factory, so it's more than 4 months of development. : :D :
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
We've done the 8months cycle with these months so that it rolls perfectly round. If we stay with 8months and go to May it's: May, January, September. And January and September are both bad months for releases since the months before nothing happens.
A very good reason for keeping and sticking to the cycle we have, and one that that people easily forget.
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
Independed on the schedule, I think it's a good idea to discuss what features we do for the next release. The systemd discussion on opensuse- factory already lead to this webpage: http://en.opensuse.org/openSUSE:Goals_12.3
Takeaway from that to all teams: discuss your goals for 12.3 on Factory then add the outcome to that page; it's all the process we have for now.
I'm fine with some more planning and goals. It's not only shipping what upstream delivers but also changing defaults and how to integrate upstream stuff.
BUT I see one project that IMO needs to be in the next release - UEFI secure boot. I would make a schedule that allows that one to go in and even slip if it's not in. So the question to Olaf and Vojtech: When do you expect that we have something in openSUSE?
Coolo: QED ;)
AJ: why is this so important that you would sacrifice the time based release?
This is IMO a critical hardware feature. I expect that all new hardware in the lifetime of 12.3 will have UEFI Secure Boot enabled and we need to solve that. Releasing - like 12.2 - with only the option to go into the BIOS and disable it - is IMO the wrong approach. I expect 12.3 to have an implementation - and 13.1 further improvements based on the experience we made with UEFI secure boot, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Andreas Jaeger wrote:
On Tuesday, September 11, 2012 12:31:57 Will Stephenson wrote:
AJ: why is this so important that you would sacrifice the time based release?
This is IMO a critical hardware feature.
I expect that all new hardware in the lifetime of 12.3 will have UEFI Secure Boot enabled and we need to solve that. Releasing - like 12.2 - with only the option to go into the BIOS and disable it - is IMO the wrong approach.
I agree UEFI support is important, but it is really a marketing feature. The number of new openSUSE 12.3 installations on new hardware with a requirement to coexist with Windows8 is going to be somewhat limited, but the awareness of the issue is much bigger, so having UEFI support would be quite a coup, marketing-wise. -- Per Jessen, Zürich (20.1°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 11 September 2012 21:37:10 Per Jessen wrote:
Andreas Jaeger wrote:
On Tuesday, September 11, 2012 12:31:57 Will Stephenson wrote:
AJ: why is this so important that you would sacrifice the time based release?
This is IMO a critical hardware feature.
I expect that all new hardware in the lifetime of 12.3 will have UEFI Secure Boot enabled and we need to solve that. Releasing - like 12.2 - with only the option to go into the BIOS and disable it - is IMO the wrong approach.
I agree UEFI support is important, but it is really a marketing feature. The number of new openSUSE 12.3 installations on new hardware with a requirement to coexist with Windows8 is going to be somewhat limited, but the awareness of the issue is much bigger, so having UEFI support would be quite a coup, marketing-wise.
Remember that 12.3 will not just be relevant the day it is released but at least the 8 months after that and up to another year after that... By that time, lots of hardware might be UEFI-only.
On Tuesday, September 11, 2012 12:31:57 Will Stephenson wrote:
On Tuesday 11 Sep 2012 11:53:08 Andreas Jaeger wrote:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
We already have many changes in Factory, so it's more than 4 months of development. : :D :
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
We've done the 8months cycle with these months so that it rolls perfectly round. If we stay with 8months and go to May it's: May, January, September. And January and September are both bad months for releases since the months before nothing happens.
A very good reason for keeping and sticking to the cycle we have, and one that that people easily forget.
Btw. we have two ways to go back to the normal iteration - going to March 2013 or even July 2013, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 2012-09-12 at 09:53 +0200, Andreas Jaeger wrote:
Btw. we have two ways to go back to the normal iteration - going to March 2013 or even July 2013,
That would redefine what the .x means, although it has no technical impact and perhaps we shouldn't spend too much time worrying about it, but here's what .x currently means. .1 = November .2 = July .3 = March Pushing back 12.3 to July 2013 would obliterate what the .x means. Again, no technical impact, just a marketing one, which should be the least of our concerns in this context right now. In fact, I think in the long term, we're going to have to drop what .x means logically because our lesson learned here is that the new definition we voted upon became broken after only just one successful release date (12.1). Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Sorry for trolling... But please consider making only one release per year... 9 months is odd enough... and resource wise it sounds like it makes things harder. With OBS backing up, people would still be able to update or install extra repos easilly. NM 2012/9/12 Bryen M Yunashko <suserocks@bryen.com>:
On Wed, 2012-09-12 at 09:53 +0200, Andreas Jaeger wrote:
Btw. we have two ways to go back to the normal iteration - going to March 2013 or even July 2013,
That would redefine what the .x means, although it has no technical impact and perhaps we shouldn't spend too much time worrying about it, but here's what .x currently means.
.1 = November .2 = July .3 = March
Pushing back 12.3 to July 2013 would obliterate what the .x means. Again, no technical impact, just a marketing one, which should be the least of our concerns in this context right now.
In fact, I think in the long term, we're going to have to drop what .x means logically because our lesson learned here is that the new definition we voted upon became broken after only just one successful release date (12.1).
Bryen
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 12 September 2012 15:53:57 Nelson Marques wrote:
Sorry for trolling... But please consider making only one release per year... 9 months is odd enough... and resource wise it sounds like it makes things harder. With OBS backing up, people would still be able to update or install extra repos easilly.
I don't think it's trolling, I think it's a legitimate idea and it has been brought up before. We have essentially two main target user groups of openSUSE: people who want something solid and stable (for servers or home systems). These are the folks running 11.4 or 11.1 even, still. Then we have people who want the latest and greatest. They run tumbleweed and/or have lots of OBS repo's. I still feel we would do both groups more justice with more emphasis on tumbleweed and a 1-year release cycle.
NM
2012/9/12 Bryen M Yunashko <suserocks@bryen.com>:
On Wed, 2012-09-12 at 09:53 +0200, Andreas Jaeger wrote:
Btw. we have two ways to go back to the normal iteration - going to March 2013 or even July 2013,
That would redefine what the .x means, although it has no technical impact and perhaps we shouldn't spend too much time worrying about it, but here's what .x currently means.
.1 = November .2 = July .3 = March
Pushing back 12.3 to July 2013 would obliterate what the .x means. Again, no technical impact, just a marketing one, which should be the least of our concerns in this context right now.
In fact, I think in the long term, we're going to have to drop what .x means logically because our lesson learned here is that the new definition we voted upon became broken after only just one successful release date (12.1).
Bryen
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 2012-09-12 at 18:43 +0200, Jos Poortvliet wrote:
I don't think it's trolling, I think it's a legitimate idea and it has been brought up before.
We have essentially two main target user groups of openSUSE: people who want something solid and stable (for servers or home systems). These are the folks running 11.4 or 11.1 even, still.
Then we have people who want the latest and greatest. They run tumbleweed and/or have lots of OBS repo's.
I still feel we would do both groups more justice with more emphasis on tumbleweed and a 1-year release cycle.
There is some validity to this idea. I fully admit that I purposely am not one of those who is willing to go out and convince their neighbors and grandmothers and everyone else to install openSUSE on their home machines. I'll advocate to the masses, but not to the individuals. Two reasons: One) I don't want to be the support guy everyone calls all the time to fix their computers. I remember this very well back in my Windows days when every friend of mine seemed to drop off their computer at my house to work on. And Two) the frequency of releases means I'd be kept pretty busy keeping their systems updated. Spreading to once-a-year release would alleviate the second concern for many who wish to advocate openSUSE without becoming a full-time free technician for family and friends. The 1-year+Tumbleweed idea may just be the perfect solution for many people. It may also free us up as a Project to focus on promoting other benefits of openSUSE beyond just the distro. We do a pretty piss-poor job of promoting things like OBS, OpenQA, etc. They just don't get the limelight like distro does. Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I dont know how much I am understanding from this discussion, but I will give my little contribution.. Today I have a feel of 11.4, 12.1 and 12.2 appliances built with Susestudio all using some alternative repositories to get alternative versions of KDE, YAST, Samba.. The thing is that OpenSuse (different from other distro) is very flexible and even if you have a 12.2 with KDE4.8 you can simple add the KDE4.9 repository to get a 12.2 with KDE4.9 that is what most of Rolling Release fans want applications and desktop updated in the last version. In this way the "base" will keep "stable". Maybe OpenSuse can be broken in just 1 small distro and people can add repos that with software versions that they want thx, sauLo On Wed, Sep 12, 2012 at 1:53 PM, Bryen M Yunashko <suserocks@bryen.com> wrote:
On Wed, 2012-09-12 at 18:43 +0200, Jos Poortvliet wrote:
I don't think it's trolling, I think it's a legitimate idea and it has been brought up before.
We have essentially two main target user groups of openSUSE: people who want something solid and stable (for servers or home systems). These are the folks running 11.4 or 11.1 even, still.
Then we have people who want the latest and greatest. They run tumbleweed and/or have lots of OBS repo's.
I still feel we would do both groups more justice with more emphasis on tumbleweed and a 1-year release cycle.
There is some validity to this idea. I fully admit that I purposely am not one of those who is willing to go out and convince their neighbors and grandmothers and everyone else to install openSUSE on their home machines. I'll advocate to the masses, but not to the individuals.
Two reasons: One) I don't want to be the support guy everyone calls all the time to fix their computers. I remember this very well back in my Windows days when every friend of mine seemed to drop off their computer at my house to work on. And Two) the frequency of releases means I'd be kept pretty busy keeping their systems updated.
Spreading to once-a-year release would alleviate the second concern for many who wish to advocate openSUSE without becoming a full-time free technician for family and friends.
The 1-year+Tumbleweed idea may just be the perfect solution for many people. It may also free us up as a Project to focus on promoting other benefits of openSUSE beyond just the distro. We do a pretty piss-poor job of promoting things like OBS, OpenQA, etc. They just don't get the limelight like distro does.
Bryen
-- 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
The 1-year+Tumbleweed idea may just be the perfect solution for many people. It may also free us up as a Project to focus on promoting other benefits of openSUSE beyond just the distro. We do a pretty piss-poor job of promoting things like OBS, OpenQA, etc. They just don't get the limelight like distro does.
Bryen, Marketing wise, a service like openSUSE Linux Distribution is meant to contemplate, not only the main part of the service, the linux distribution itself, but also all the support services, which should include: - community support (wiki, irc, etc) - OBS software distribution capabilities - etc etc So, in my reading of your words; the root of the problem is actually a matter of concept and not of efforts (which no one can deny that most people do 100% and then some more). Getting off-topic // feel free to fork out this to another thread if needed. --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am Mittwoch, 12. September 2012, 11:53:21 schrieb Bryen M Yunashko:
The 1-year+Tumbleweed idea may just be the perfect solution for many people. It may also free us up as a Project to focus on promoting other benefits of openSUSE beyond just the distro. We do a pretty piss-poor job of promoting things like OBS, OpenQA, etc. They just don't get the limelight like distro does.
What's the reason for people to call for Tumbleweed etc.? IMO it's not that most people do really want/need a rolling distro but only some rolling projects, e.g. desktop environments, LibreOffice etc. If they bought new hardware they might want a rolling kernel until everything works, but most of the time people do not think about the base distro when it comes to rolling distros but the latest upstream release of Gnome, KDE, app x or y. I can only speak for KDE but I'm sure one way or another it can be applied to other projects as well. KDE has a repo for each major upstream release. This means that community members invest time on packaging and testing packages, resulting in the availability of upstream bugfix minor releases for openSUE KDE users. Are those fixes shipped to the user? Seldom, if at all. openSUSE wastes the effort community members have put into packaging upstream fixes instead of using it to the benefit of its users. Backports are possible in theory, yet do only happen seldom if at all in practice and if so, consume time that could be used elsewhere. Regarding KDE, backporting is doubling the work somebody else did already upstream. Packaging that backport is doubling the work a community member did already do on obs. The killer argument against shipping upstream bugfix releases is the regression myth. Again, I can only speak for KDE. There is certainly the possibility for regressions, but when was the last time a serious regression was introduced by an upstream bugfix release? A long, long time ago. And fixing that regression would taken only a fraction of the time that was spent on backporting and other double work. Plus, even if there is a regression, people can always revert to the oss version or if one enables obs to keep some versions of a package and not only one, the version before the regression. Not shipping upstream releases does often annoy upstream because people report bugs that have already been fixed or even worse, report issues that result from backporting and are thus very hard to understand by upstream, since those reporting often do not have a clue that they are not actually using version x.y but x.y+openSUSE "fixes". This wastes the time of upstream devs. So while in theory users would be better off with tons of backports and thus a stable distro, reality shows that there is no time for backports and openSUSE does not use the potential of the efforts done upstream and by community members. The real myth is that fixes are backported regularly and shipped to the user. Simply because openSUSE staff is busy with boosting all sorts of things but caring about Gnome, KDE etc. leaving alone spending time on a substantial contribution to those projects. So my idea is to ship openSUSE as base distro and integrate an official tool that allows the user to sign-up for upstream bugfix releases for projects such as Gnome, KDE, LibreOffice etc. I know that a community repo list exists, but it is not quite what is needed and not official. So to sum-up: Release a base distro every x months, save the (lack of) time for backporting, acknowledge the backporting myth and let openSUSE users benefit from upstream devs fixing bugs and the community's effort of packaging upstream bugfix releases. Sven -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thursday, September 13, 2012 13:30:59 Sven Burmeister wrote:
Am Mittwoch, 12. September 2012, 11:53:21 schrieb Bryen M Yunashko:
The 1-year+Tumbleweed idea may just be the perfect solution for many people. It may also free us up as a Project to focus on promoting other benefits of openSUSE beyond just the distro. We do a pretty piss-poor job of promoting things like OBS, OpenQA, etc. They just don't get the limelight like distro does.
What's the reason for people to call for Tumbleweed etc.? IMO it's not that most people do really want/need a rolling distro but only some rolling projects, e.g. desktop environments, LibreOffice etc.
If they bought new hardware they might want a rolling kernel until everything works, but most of the time people do not think about the base distro when it comes to rolling distros but the latest upstream release of Gnome, KDE, app x or y.
I can only speak for KDE but I'm sure one way or another it can be applied to other projects as well.
KDE has a repo for each major upstream release. This means that community members invest time on packaging and testing packages, resulting in the availability of upstream bugfix minor releases for openSUE KDE users. Are those fixes shipped to the user? Seldom, if at all. openSUSE wastes the effort community members have put into packaging upstream fixes instead of using it to the benefit of its users.
Backports are possible in theory, yet do only happen seldom if at all in practice and if so, consume time that could be used elsewhere. Regarding KDE, backporting is doubling the work somebody else did already upstream. Packaging that backport is doubling the work a community member did already do on obs.
The killer argument against shipping upstream bugfix releases is the regression myth. Again, I can only speak for KDE. There is certainly the possibility for regressions, but when was the last time a serious regression was introduced by an upstream bugfix release? A long, long time ago. And fixing that regression would taken only a fraction of the time that was spent on backporting and other double work. Plus, even if there is a regression, people can always revert to the oss version or if one enables obs to keep some versions of a package and not only one, the version before the regression.
Not shipping upstream releases does often annoy upstream because people report bugs that have already been fixed or even worse, report issues that result from backporting and are thus very hard to understand by upstream, since those reporting often do not have a clue that they are not actually using version x.y but x.y+openSUSE "fixes". This wastes the time of upstream devs.
So while in theory users would be better off with tons of backports and thus a stable distro, reality shows that there is no time for backports and openSUSE does not use the potential of the efforts done upstream and by community members. The real myth is that fixes are backported regularly and shipped to the user. Simply because openSUSE staff is busy with boosting all sorts of things but caring about Gnome, KDE etc. leaving alone spending time on a substantial contribution to those projects.
So my idea is to ship openSUSE as base distro and integrate an official tool that allows the user to sign-up for upstream bugfix releases for projects such as Gnome, KDE, LibreOffice etc. I know that a community repo list exists, but it is not quite what is needed and not official.
So to sum-up: Release a base distro every x months, save the (lack of) time for backporting, acknowledge the backporting myth and let openSUSE users benefit from upstream devs fixing bugs and the community's effort of packaging upstream bugfix releases.
Love the idea. This could work very well - most of this we already have, right? It would need the app, mostly. Might be a job for a quick QML thingy :D
Sven
2012/9/14 Jos Poortvliet <jos@opensuse.org>:
On Thursday, September 13, 2012 13:30:59 Sven Burmeister wrote:
Am Mittwoch, 12. September 2012, 11:53:21 schrieb Bryen M Yunashko:
The 1-year+Tumbleweed idea may just be the perfect solution for many people. It may also free us up as a Project to focus on promoting other benefits of openSUSE beyond just the distro. We do a pretty piss-poor job of promoting things like OBS, OpenQA, etc. They just don't get the limelight like distro does.
What's the reason for people to call for Tumbleweed etc.? IMO it's not that most people do really want/need a rolling distro but only some rolling projects, e.g. desktop environments, LibreOffice etc.
If they bought new hardware they might want a rolling kernel until everything works, but most of the time people do not think about the base distro when it comes to rolling distros but the latest upstream release of Gnome, KDE, app x or y.
I can only speak for KDE but I'm sure one way or another it can be applied to other projects as well.
KDE has a repo for each major upstream release. This means that community members invest time on packaging and testing packages, resulting in the availability of upstream bugfix minor releases for openSUE KDE users. Are those fixes shipped to the user? Seldom, if at all. openSUSE wastes the effort community members have put into packaging upstream fixes instead of using it to the benefit of its users.
Backports are possible in theory, yet do only happen seldom if at all in practice and if so, consume time that could be used elsewhere. Regarding KDE, backporting is doubling the work somebody else did already upstream. Packaging that backport is doubling the work a community member did already do on obs.
The killer argument against shipping upstream bugfix releases is the regression myth. Again, I can only speak for KDE. There is certainly the possibility for regressions, but when was the last time a serious regression was introduced by an upstream bugfix release? A long, long time ago. And fixing that regression would taken only a fraction of the time that was spent on backporting and other double work. Plus, even if there is a regression, people can always revert to the oss version or if one enables obs to keep some versions of a package and not only one, the version before the regression.
Not shipping upstream releases does often annoy upstream because people report bugs that have already been fixed or even worse, report issues that result from backporting and are thus very hard to understand by upstream, since those reporting often do not have a clue that they are not actually using version x.y but x.y+openSUSE "fixes". This wastes the time of upstream devs.
So while in theory users would be better off with tons of backports and thus a stable distro, reality shows that there is no time for backports and openSUSE does not use the potential of the efforts done upstream and by community members. The real myth is that fixes are backported regularly and shipped to the user. Simply because openSUSE staff is busy with boosting all sorts of things but caring about Gnome, KDE etc. leaving alone spending time on a substantial contribution to those projects.
So my idea is to ship openSUSE as base distro and integrate an official tool that allows the user to sign-up for upstream bugfix releases for projects such as Gnome, KDE, LibreOffice etc. I know that a community repo list exists, but it is not quite what is needed and not official.
So to sum-up: Release a base distro every x months, save the (lack of) time for backporting, acknowledge the backporting myth and let openSUSE users benefit from upstream devs fixing bugs and the community's effort of packaging upstream bugfix releases.
Love the idea. This could work very well - most of this we already have, right? It would need the app, mostly. Might be a job for a quick QML thingy :D
This sounds nice and could bring other benefits; if a few more love in making decent patterns / software groups for zypper and meta installer would allow allow great customization under Studio... Cook and bake your stuff... With this I mean big projects like KDE and GNOME could spare things like: * favorite-desktop-full (full install) * favorite-desktop-custom (customized install, pre defined by project) * favorite-desktop-minimal (minimal install) * favorite-desktop-extras (adiitonal stuff like theme, engines, docks, etc) I mean forking a .xml file into several pre-defined defaults would contribute a great step for sure endeavour (as the one proposed), boost the tools notoriety and probably would introduce such diferentiation point big enough for much ink to be spent... The kind of dangerous thing I like :) Best of luck. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/13/2012 02:30 PM, Sven Burmeister wrote:
The 1-year+Tumbleweed idea may just be the perfect solution for many people. It may also free us up as a Project to focus on promoting other benefits of openSUSE beyond just the distro. We do a pretty piss-poor job of promoting things like OBS, OpenQA, etc. They just don't get the limelight like distro does. What's the reason for people to call for Tumbleweed etc.? IMO it's not that most people do really want/need a rolling distro but only some rolling
Am Mittwoch, 12. September 2012, 11:53:21 schrieb Bryen M Yunashko: projects, e.g. desktop environments, LibreOffice etc.
If they bought new hardware they might want a rolling kernel until everything works, but most of the time people do not think about the base distro when it comes to rolling distros but the latest upstream release of Gnome, KDE, app x or y.
I can only speak for KDE but I'm sure one way or another it can be applied to other projects as well.
KDE has a repo for each major upstream release. This means that community members invest time on packaging and testing packages, resulting in the availability of upstream bugfix minor releases for openSUE KDE users. Are those fixes shipped to the user? Seldom, if at all. openSUSE wastes the effort community members have put into packaging upstream fixes instead of using it to the benefit of its users.
Backports are possible in theory, yet do only happen seldom if at all in practice and if so, consume time that could be used elsewhere. Regarding KDE, backporting is doubling the work somebody else did already upstream. Packaging that backport is doubling the work a community member did already do on obs.
The killer argument against shipping upstream bugfix releases is the regression myth. Again, I can only speak for KDE. There is certainly the possibility for regressions, but when was the last time a serious regression was introduced by an upstream bugfix release? A long, long time ago. And fixing that regression would taken only a fraction of the time that was spent on backporting and other double work. Plus, even if there is a regression, people can always revert to the oss version or if one enables obs to keep some versions of a package and not only one, the version before the regression.
Not shipping upstream releases does often annoy upstream because people report bugs that have already been fixed or even worse, report issues that result from backporting and are thus very hard to understand by upstream, since those reporting often do not have a clue that they are not actually using version x.y but x.y+openSUSE "fixes". This wastes the time of upstream devs.
So while in theory users would be better off with tons of backports and thus a stable distro, reality shows that there is no time for backports and openSUSE does not use the potential of the efforts done upstream and by community members. The real myth is that fixes are backported regularly and shipped to the user. Simply because openSUSE staff is busy with boosting all sorts of things but caring about Gnome, KDE etc. leaving alone spending time on a substantial contribution to those projects.
So my idea is to ship openSUSE as base distro and integrate an official tool that allows the user to sign-up for upstream bugfix releases for projects such as Gnome, KDE, LibreOffice etc. I know that a community repo list exists, but it is not quite what is needed and not official.
So to sum-up: Release a base distro every x months, save the (lack of) time for backporting, acknowledge the backporting myth and let openSUSE users benefit from upstream devs fixing bugs and the community's effort of packaging upstream bugfix releases.
Sven This is a good list of arguments about moving to 1 year release plan. But then again, this sounds to me like banning Tumbleweed from updating new kernel (and perhaps gcc, libc) and allowing kernel updates every 1 year.
What would be the reason not to do this while updating kernel every 6 months? Marketing? Stability? Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Fri, 14 Sep 2012 03:40:57 +0300 Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
and allowing kernel updates every 1 year.
What would be the reason not to do this while updating kernel every 6 months? Marketing? Stability?
The idea to avoid backporting applied to the base system will actually make possible shorter release periods. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/14/2012 07:07 AM, Rajko wrote:
On Fri, 14 Sep 2012 03:40:57 +0300 Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
and allowing kernel updates every 1 year.
What would be the reason not to do this while updating kernel every 6 months? Marketing? Stability? The idea to avoid backporting applied to the base system will actually make possible shorter release periods.
Just to be clear, I am not in favor of a 6 month release plan, I personally enjoy not having to upgrade twice a year my systems :) I am just trying to point out that avoiding backports is almost here with Tumbleweed with the difference being just the kernel updates (and some help Greg would need from us to keep things up). -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
2012/9/12 Jos Poortvliet <jos@opensuse.org>:
On Wednesday 12 September 2012 15:53:57 Nelson Marques wrote:
Sorry for trolling... But please consider making only one release per year... 9 months is odd enough... and resource wise it sounds like it makes things harder. With OBS backing up, people would still be able to update or install extra repos easilly.
I don't think it's trolling, I think it's a legitimate idea and it has been brought up before.
My idea is that people who want a stable desktop don't want to do upgrades often... This means that even 1 year might be too low, but far more acceptable than 6 months or 9 months. This will also reinforce the identity of openSUSE around stability. If people who want more update applications, either GNOME or KDE do provide off-cycle updated repositories. So users actually have a a load of options and can 'customize' their systems according to their needs through OBS openSUSE project This sounds like a win to me :)
We have essentially two main target user groups of openSUSE: people who want something solid and stable (for servers or home systems). These are the folks running 11.4 or 11.1 even, still.
Then we have people who want the latest and greatest. They run tumbleweed and/or have lots of OBS repo's.
Tumbleweed is the most visible product from the openSUSE umbrella outside openSUSE; I value Greg's efforts and will to keep pushing, but Tumbleweed needs a bit more of love from everyone. Evergreen needs a bit more of love and covers the server needs... probably awesome for headless.
I still feel we would do both groups more justice with more emphasis on tumbleweed and a 1-year release cycle.
It's a community option; Good luck finding out the path... I for sure do encourage to add a bit more of differentiation; If we change release cycles, I would advice to prepare a massive marketing effort... (germans forgive me for the terminology) we need desperatly a bit more of 'blitzkrieg' attitude around openSUSE; while the tech oriented people are doing it with systemd, plymouth and other upgrades (gcc also to mention), marketing is staying behi'nd. Its about time openSUSE goes into the offensive instead of trying to defend it's small niche. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 2012-09-12 19:53, Nelson Marques wrote:
2012/9/12 Jos Poortvliet <jos@opensuse.org>:
On Wednesday 12 September 2012 15:53:57 Nelson Marques wrote:
Sorry for trolling... But please consider making only one release per year... 9 months is odd enough... and resource wise it sounds like it makes things harder. With OBS backing up, people would still be able to update or install extra repos easilly.
I don't think it's trolling, I think it's a legitimate idea and it has been brought up before.
My idea is that people who want a stable desktop don't want to do upgrades often... This means that even 1 year might be too low, but far more acceptable than 6 months or 9 months. This will also reinforce the identity of openSUSE around stability.
You are mixing stability with upgrades, which is a shortsighted thing to assume I think. Upgrades do not automatically mean loss of stability. Stability of 12.1 was, you could say, "impacted" by the introduction of 12.1. That took some more testing, and bug reporting. Stability of 12.2 was only impacted for me by one Xfce bug that I hit and then circumvented as it was a one-time occurrence. On the other hand, having to do an upgrade incurs other costs: I need to plan upgrades somewhat because I have openSUSE-derived packages (i.e. modifications to aaa_base, coreutils, etc.) that need rebasing for a new release, hence I don't want to do that too often. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sunday 23 September 2012 11:11:57 Jan Engelhardt wrote:
On Wednesday 2012-09-12 19:53, Nelson Marques wrote:
2012/9/12 Jos Poortvliet <jos@opensuse.org>:
On Wednesday 12 September 2012 15:53:57 Nelson Marques wrote:
Sorry for trolling... But please consider making only one release per year... 9 months is odd enough... and resource wise it sounds like it makes things harder. With OBS backing up, people would still be able to update or install extra repos easilly.
I don't think it's trolling, I think it's a legitimate idea and it has been brought up before.
My idea is that people who want a stable desktop don't want to do upgrades often... This means that even 1 year might be too low, but far more acceptable than 6 months or 9 months. This will also reinforce the identity of openSUSE around stability.
You are mixing stability with upgrades, which is a shortsighted thing to assume I think. Upgrades do not automatically mean loss of stability.
Stability of 12.1 was, you could say, "impacted" by the introduction of 12.1. That took some more testing, and bug reporting.
I don't understand the sentence above.
Stability of 12.2 was only impacted for me by one Xfce bug that I hit and then circumvented as it was a one-time occurrence.
On the other hand, having to do an upgrade incurs other costs: I need to plan upgrades somewhat because I have openSUSE-derived packages (i.e. modifications to aaa_base, coreutils, etc.) that need rebasing for a new release, hence I don't want to do that too often.
Agreed that upgrades don't have to result in instability - but they DO invariably mean change. And change, as you argue, is the bad thing (to some extend). A longer release cycle brings less change (or, with OBS, only change where the user wants it). In any case. Point still stands: many users would appreciate a slower release cycle, for various reasons. It would also probably help release management as we could introduce longer freeze periods. It might make development more boring and will result in a more outdated openSUSE - but we can counter that probably with OBS fu. /Jos
On Monday 2012-09-24 20:41, Jos Poortvliet wrote:
Agreed that upgrades don't have to result in instability - but they DO invariably mean change. And change, as you argue, is the bad thing (to some extend). A longer release cycle brings less change (or, with OBS, only change where the user wants it).
Change isn't bad, bugs are.
In any case. Point still stands: many users would appreciate a slower release cycle, for various reasons.
I'll wait for a poll to show the actual numbers. :) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 24 Sep 2012 21:03:21 +0200, Jan Engelhardt wrote:
In any case. Point still stands: many users would appreciate a slower release cycle, for various reasons.
I'll wait for a poll to show the actual numbers. :)
So if we want to construct a poll, probably the first (and most important step) is determining how many users we have - even a rough estimate (not a guess, though) will help us identify if the sample is representative enough of our overall userbase. If we don't know the size of our userbase, then it's difficult to know if we've got a large enough sample for the poll to be valid. Even just knowing within an order of magnitude should be sufficient (though a better estimate should help us). 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, September 24, 2012 20:41:54 Jos Poortvliet wrote:
On Sunday 23 September 2012 11:11:57 Jan Engelhardt wrote:
On Wednesday 2012-09-12 19:53, Nelson Marques wrote:
2012/9/12 Jos Poortvliet <jos@opensuse.org>:
On Wednesday 12 September 2012 15:53:57 Nelson Marques wrote:
Sorry for trolling... But please consider making only one release per year... 9 months is odd enough... and resource wise it sounds like it makes things harder. With OBS backing up, people would still be able to update or install extra repos easilly.
I don't think it's trolling, I think it's a legitimate idea and it has been brought up before.
My idea is that people who want a stable desktop don't want to do upgrades often... This means that even 1 year might be too low, but far more acceptable than 6 months or 9 months. This will also reinforce the identity of openSUSE around stability.
You are mixing stability with upgrades, which is a shortsighted thing to assume I think. Upgrades do not automatically mean loss of stability.
Stability of 12.1 was, you could say, "impacted" by the introduction of 12.1. That took some more testing, and bug reporting.
I don't understand the sentence above.
Stability of 12.2 was only impacted for me by one Xfce bug that I hit and then circumvented as it was a one-time occurrence.
On the other hand, having to do an upgrade incurs other costs: I need to plan upgrades somewhat because I have openSUSE-derived packages (i.e. modifications to aaa_base, coreutils, etc.) that need rebasing for a new release, hence I don't want to do that too often.
Agreed that upgrades don't have to result in instability - but they DO invariably mean change. And change, as you argue, is the bad thing (to some extend). A longer release cycle brings less change (or, with OBS, only change where the user wants it).
In any case. Point still stands: many users would appreciate a slower release cycle, for various reasons. It would also probably help release management as we could introduce longer freeze periods. It might make development more boring and will result in a more outdated openSUSE - but we can counter that probably with OBS fu.
We have already very long freeze periods and always increased them. This cannot be our answer each and every time - we need find to ways better so that we can freeze less. And this is the whole discussion about: How to improve our processes so that we have a better factory and release all the time? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/25/2012 11:49 AM, Andreas Jaeger wrote:
On Monday, September 24, 2012 20:41:54 Jos Poortvliet wrote:
In any case. Point still stands: many users would appreciate a slower release cycle, for various reasons. It would also probably help release management as we could introduce longer freeze periods. It might make development more boring and will result in a more outdated openSUSE - but we can counter that probably with OBS fu.
We have already very long freeze periods and always increased them. This cannot be our answer each and every time - we need find to ways better so that we can freeze less. And this is the whole discussion about: How to improve our processes so that we have a better factory and release all the time?
1) Promote the use of Factory rather than Tumbleweed. The more people use factory more opportunity to fix bugs. Factory is the actual rolling release. 2) Rather then keeping things in separate project repos encourage maintainers to send their package to factory (sorry for the factory-review and factory-maintainer people ) because the more people start adding more repos to their zypper configuration the more problems begin. As some do blindly install packages rather then selectively making choices. Look at Debian how many repos do they have (unless one wants to be always on the edge no need to add tons of repos to deb sources) 3) The version scheme was discussed and if I remember correctly was voted. Just because there were some bumps this time does not necessarily mean it should be changed. The same goes for the timeline, there will be always some one wanting a longer cycle and those who favor a shorter cycle. For those wanting a longer cycle support the Evergreen project concept, and for those in need of shorter release use Factory as that is the true rolling release Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 25 September 2012 12:11:51 Togan Muftuoglu wrote:
On 09/25/2012 11:49 AM, Andreas Jaeger wrote:
On Monday, September 24, 2012 20:41:54 Jos Poortvliet wrote:
In any case. Point still stands: many users would appreciate a slower release cycle, for various reasons. It would also probably help release management as we could introduce longer freeze periods. It might make development more boring and will result in a more outdated openSUSE - but we can counter that probably with OBS fu.
We have already very long freeze periods and always increased them. This cannot be our answer each and every time - we need find to ways better so that we can freeze less. And this is the whole discussion about: How to improve our processes so that we have a better factory and release all the time?
<snip 1, 2 and 3 that make no sense> What use scenarios do you have in mind for openSUSE, I wonder? Let me lay out a few here for you. * Ad Min knows what he's doing. He's an experienced sysadmin and does some testing of openSUSE milestones when he has spare time. * Grand Ma knows not know much of computers but as long as she can print pictures from her grand children she's quite happy. * Yo Ung is new to the world of computing but she wants to learn to program. * Dev Elop has been developing software for a few years and has recently starting to package. Usage: * Ad Min has openSUSE on a few servers, his laptop and his desktop. * Yo Ung has picked up a openSUSE DVD at a conference as she heard about cool projects like OBS and tumbleweed and is going to play with it. * Grand Ma just has her one computer. Ad takes care of it, however! * Dev Elop has a computer for work and one for packaging. What do they run? Ad runs openSUSE Stable on the servers and on his laptop. On the laptop he has a bunch of OBS repo's to have the latest tools, but as he takes the laptop to customers, Factory or even Tumbleweed are no option. The desktop can be more up-to-date but is also for work so Factory gets installed in a VM while the system runs Tumbleweed or stable. Dev would run Factory on one computer but the other one is for work - Tumbleweed (or stable with a bunch of OBS repo's), as he's an enthusiast. Yo Ung wants to learn to program so she would take Tumbleweed or another distro like Arch Linux. Stable is too boring, Factory too unstable. Grand Ma wants a stable system and as Ad also has to take care of the computers of 8 other family members and wants as little maintenance, he only upgrades when he HAS to - and complains loudly that the openSUSE release cycle is too short. You see, Factory is no competitor for Tumbleweed. They have nothing to do with each other: people who would consider Tumbleweed don't consider Factory. Tumbleweed is for people who consider the 8 month release cycle too slow (like myself) and run many, many OBS repo's (which gets messy). Meanwhile, the 8 months release cycle is too short for other people like Ad and his servers and the systems he maintains for his family. So, yes, Coolo is right: 8 months is both too short and too long. THAT is why I proposed to have a 12 month cycle with more emphasis on OBS and Tumbleweed: that is NO longer too short AND too long. Right now, we have "meat nor fish" as the dutch would say: a real compromise, good for nobody. *Factory doesn't care* Yes, for development, all this doesn't matter. It won't make openSUSE Factory more stable - it probably won't make much difference, other than that we get less freezes so less stability on average (but that doesn't matter: it is the release which matters). For the users, this makes a huge difference: it makes openSUSE a much more viable choice for pretty much EVERY use case out there. That's why I argue for a 12 month cycle: better for ALL our users. So if it doesn't impact development much (as in - the final result would be as stable and getting it out the door is not any harder) I think we should try to move to this. *getting more factory testers* The key to getting more people to use Factory is to get more users AND get those users more involved in openSUSE: mentoring, better documentation, articles to engage people, openSUSE ambassadors at conferences, install fests, a better atmosphere in the project etcetera. You'll never get Grand Ma to use factory, she'll just move to Ubuntu LTS, same with Ad. Yo - you need to teach her how to contribute, than, yes, she'll start helping out. But we chase her away with our boring 8 month stability - tumbleweed is what attracts people to our distro! Please try to look outside of the folks on this mailing list to those hundreds of potential NEW people for this list... openSUSE will always continue to loose contributors (people leave, that's a fact of life) and if we don't have a distro which is actually good for some things as well as some exciting projects (like tumbleweed!) we'll simply fade into obscurity. And no, you won't get more Factory testers with that 'strategy'. /Jos
Togan
On Tue, 2012-09-25 at 21:15 +0200, Jos Poortvliet wrote:
That's why I argue for a 12 month cycle: better for ALL our users. So if it doesn't impact development much (as in - the final result would be as stable and getting it out the door is not any harder) I think we should try to move to this.
+1 to this, with a *HEAVY* emphasis that we get a clearer picture of how this will impact development. Yesterday, I read in some point in this thread that a poll should be conducted about what our release cycle should be. I'm opposed to such a poll because I think ultimately it is up to the Factory team and contributors to decide what is realistically do-able for them. Creating a poll where those of us who believe in 12-month cycle wins and yet Factory says "Wait, we can't do it this way." is a waste of time and would ultimately cause more friction. Instead, I'd like to hear more from Factory folks explaining what is doable, and what isn't. We should be supporting options based on their say-so, not based on our wishlist. But, if we're told 12-month release + 24 month support cycle is doable, you'll already know where my vote lies. :-D Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
+1 to this, with a *HEAVY* emphasis that we get a clearer picture of how this will impact development. Yesterday, I read in some point in this thread that a poll should be conducted about what our release cycle should be. I'm opposed to such a poll because I think ultimately it is up to the Factory team and contributors to decide what is realistically do-able for them.
It's a rare, but it seems I do agree with you; Coolo and his people/staff voice can't be ignored on this, afterall, they are the ones which place the ultimate effort in openSUSE... This is one of the rare cases which should weighted carefully, and I don't believe that Coolo and his people will ignore some of the arguments, though they should have the ultimate leverage power in this. Just grab representatives of the biggest projects with the release team and see what can be improved; In my opinion, I don't care if it takes one year... As long as the decision once it's taken it's for a long period of time... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 25.09.2012 21:27, Bryen M Yunashko wrote:
On Tue, 2012-09-25 at 21:15 +0200, Jos Poortvliet wrote:
That's why I argue for a 12 month cycle: better for ALL our users. So if it doesn't impact development much (as in - the final result would be as stable and getting it out the door is not any harder) I think we should try to move to this.
+1 to this, with a *HEAVY* emphasis that we get a clearer picture of how this will impact development. Yesterday, I read in some point in this thread that a poll should be conducted about what our release cycle should be. I'm opposed to such a poll because I think ultimately it is up to the Factory team and contributors to decide what is realistically do-able for them.
Creating a poll where those of us who believe in 12-month cycle wins and yet Factory says "Wait, we can't do it this way." is a waste of time and would ultimately cause more friction.
Instead, I'd like to hear more from Factory folks explaining what is doable, and what isn't. We should be supporting options based on their say-so, not based on our wishlist.
This is what bothers me too - there is just too little input from people actually working on the issues. Jos has his dream picture of what the user experience with tumbleweed should look like, but in fact we will have more people testing RC kernels then ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 2012-09-26 at 11:14 +0200, Stephan Kulow wrote:
On 25.09.2012 21:27, Bryen M Yunashko wrote:
On Tue, 2012-09-25 at 21:15 +0200, Jos Poortvliet wrote:
That's why I argue for a 12 month cycle: better for ALL our users. So if it doesn't impact development much (as in - the final result would be as stable and getting it out the door is not any harder) I think we should try to move to this.
+1 to this, with a *HEAVY* emphasis that we get a clearer picture of how this will impact development. Yesterday, I read in some point in this thread that a poll should be conducted about what our release cycle should be. I'm opposed to such a poll because I think ultimately it is up to the Factory team and contributors to decide what is realistically do-able for them.
Creating a poll where those of us who believe in 12-month cycle wins and yet Factory says "Wait, we can't do it this way." is a waste of time and would ultimately cause more friction.
Instead, I'd like to hear more from Factory folks explaining what is doable, and what isn't. We should be supporting options based on their say-so, not based on our wishlist.
This is what bothers me too - there is just too little input from people actually working on the issues. Jos has his dream picture of what the user experience with tumbleweed should look like, but in fact we will have more people testing RC kernels then ;(
Greetings, Stephan
Ok, so how do we move this discussion forward and more productively? What do we do to get more input? Perhaps this discussion needs to be held on -factory ML instead of -project? We could easily make the claim "speak now or forever hold your peace" but if those folks aren't paying attention to -project, then we're missing many boats. :-) And in that spirit, can you enlighten us what you mean by more people testing the RC kernels? What will take people away from testing pre-RC kernels. And with many people typically testing only when it reaches RC phase currently, how does this differ in the new proposed scheme? Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Wow! Following this suggestion is like watching Obama try and push for health care reform! Has anyone taken any steps to "ASK" persons of Factory and "regular" testers of the annual release feasibility? On Wed, Sep 26, 2012 at 3:10 AM, Bryen M Yunashko <suserocks@bryen.com> wrote:
On Wed, 2012-09-26 at 11:14 +0200, Stephan Kulow wrote:
On 25.09.2012 21:27, Bryen M Yunashko wrote:
On Tue, 2012-09-25 at 21:15 +0200, Jos Poortvliet wrote:
That's why I argue for a 12 month cycle: better for ALL our users. So if it doesn't impact development much (as in - the final result would be as stable and getting it out the door is not any harder) I think we should try to move to this.
+1 to this, with a *HEAVY* emphasis that we get a clearer picture of how this will impact development. Yesterday, I read in some point in this thread that a poll should be conducted about what our release cycle should be. I'm opposed to such a poll because I think ultimately it is up to the Factory team and contributors to decide what is realistically do-able for them.
Creating a poll where those of us who believe in 12-month cycle wins and yet Factory says "Wait, we can't do it this way." is a waste of time and would ultimately cause more friction.
Instead, I'd like to hear more from Factory folks explaining what is doable, and what isn't. We should be supporting options based on their say-so, not based on our wishlist.
This is what bothers me too - there is just too little input from people actually working on the issues. Jos has his dream picture of what the user experience with tumbleweed should look like, but in fact we will have more people testing RC kernels then ;(
Greetings, Stephan
Ok, so how do we move this discussion forward and more productively? What do we do to get more input? Perhaps this discussion needs to be held on -factory ML instead of -project? We could easily make the claim "speak now or forever hold your peace" but if those folks aren't paying attention to -project, then we're missing many boats. :-)
And in that spirit, can you enlighten us what you mean by more people testing the RC kernels? What will take people away from testing pre-RC kernels. And with many people typically testing only when it reaches RC phase currently, how does this differ in the new proposed scheme?
Bryen
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 26 Sep 2012 20:57:54 -0700 "DuBois, Scott L." <ranger@roguehorse.com> wrote:
Has anyone taken any steps to "ASK" persons of Factory and "regular" testers of the annual release feasibility?
No one is in a rush to ask them is because they have process that obviously doesn't give expected results, so some new ideas should be offered and then ask guys for feasibility. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thursday 2012-09-27 05:57, DuBois, Scott L. wrote:
Wow! Following this suggestion is like watching Obama try and push for health care reform!
Looks more like Republicans going for a (further) relaxation of gun laws.
On Wed, Sep 26, 2012 at 3:10 AM, Bryen M Yunashko <suserocks@bryen.com> wrote:
On Wed, 2012-09-26 at 11:14 +0200, Stephan Kulow wrote:
On 25.09.2012 21:27, Bryen M Yunashko wrote:
On Tue, 2012-09-25 at 21:15 +0200, Jos Poortvliet wrote:
That's why I argue for a 12 month cycle: better for ALL our users. So if it doesn't impact development much (as in - the final result would be as stable and getting it out the door is not any harder) I think we should try to move to this. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Wow!? Bravo! I vote for stability. Remember: 80% Use MS 7.5% Use Apple 1.5% Use Linux which is divided into how many variations of which we are one? Focus on Grandma, but offer up to Ad. On Tue, Sep 25, 2012 at 12:15 PM, Jos Poortvliet <jos@opensuse.org> wrote:
On Tuesday 25 September 2012 12:11:51 Togan Muftuoglu wrote:
On 09/25/2012 11:49 AM, Andreas Jaeger wrote:
On Monday, September 24, 2012 20:41:54 Jos Poortvliet wrote:
In any case. Point still stands: many users would appreciate a slower release cycle, for various reasons. It would also probably help release management as we could introduce longer freeze periods. It might make development more boring and will result in a more outdated openSUSE - but we can counter that probably with OBS fu.
We have already very long freeze periods and always increased them. This cannot be our answer each and every time - we need find to ways better so that we can freeze less. And this is the whole discussion about: How to improve our processes so that we have a better factory and release all the time?
<snip 1, 2 and 3 that make no sense>
What use scenarios do you have in mind for openSUSE, I wonder? Let me lay out a few here for you.
* Ad Min knows what he's doing. He's an experienced sysadmin and does some testing of openSUSE milestones when he has spare time. * Grand Ma knows not know much of computers but as long as she can print pictures from her grand children she's quite happy. * Yo Ung is new to the world of computing but she wants to learn to program. * Dev Elop has been developing software for a few years and has recently starting to package.
Usage: * Ad Min has openSUSE on a few servers, his laptop and his desktop. * Yo Ung has picked up a openSUSE DVD at a conference as she heard about cool projects like OBS and tumbleweed and is going to play with it. * Grand Ma just has her one computer. Ad takes care of it, however! * Dev Elop has a computer for work and one for packaging.
What do they run?
Ad runs openSUSE Stable on the servers and on his laptop. On the laptop he has a bunch of OBS repo's to have the latest tools, but as he takes the laptop to customers, Factory or even Tumbleweed are no option. The desktop can be more up-to-date but is also for work so Factory gets installed in a VM while the system runs Tumbleweed or stable. Dev would run Factory on one computer but the other one is for work - Tumbleweed (or stable with a bunch of OBS repo's), as he's an enthusiast. Yo Ung wants to learn to program so she would take Tumbleweed or another distro like Arch Linux. Stable is too boring, Factory too unstable. Grand Ma wants a stable system and as Ad also has to take care of the computers of 8 other family members and wants as little maintenance, he only upgrades when he HAS to - and complains loudly that the openSUSE release cycle is too short.
You see, Factory is no competitor for Tumbleweed. They have nothing to do with each other: people who would consider Tumbleweed don't consider Factory. Tumbleweed is for people who consider the 8 month release cycle too slow (like myself) and run many, many OBS repo's (which gets messy). Meanwhile, the 8 months release cycle is too short for other people like Ad and his servers and the systems he maintains for his family.
So, yes, Coolo is right: 8 months is both too short and too long. THAT is why I proposed to have a 12 month cycle with more emphasis on OBS and Tumbleweed: that is NO longer too short AND too long. Right now, we have "meat nor fish" as the dutch would say: a real compromise, good for nobody.
*Factory doesn't care* Yes, for development, all this doesn't matter. It won't make openSUSE Factory more stable - it probably won't make much difference, other than that we get less freezes so less stability on average (but that doesn't matter: it is the release which matters). For the users, this makes a huge difference: it makes openSUSE a much more viable choice for pretty much EVERY use case out there.
That's why I argue for a 12 month cycle: better for ALL our users. So if it doesn't impact development much (as in - the final result would be as stable and getting it out the door is not any harder) I think we should try to move to this.
*getting more factory testers* The key to getting more people to use Factory is to get more users AND get those users more involved in openSUSE: mentoring, better documentation, articles to engage people, openSUSE ambassadors at conferences, install fests, a better atmosphere in the project etcetera. You'll never get Grand Ma to use factory, she'll just move to Ubuntu LTS, same with Ad. Yo - you need to teach her how to contribute, than, yes, she'll start helping out. But we chase her away with our boring 8 month stability - tumbleweed is what attracts people to our distro!
Please try to look outside of the folks on this mailing list to those hundreds of potential NEW people for this list... openSUSE will always continue to loose contributors (people leave, that's a fact of life) and if we don't have a distro which is actually good for some things as well as some exciting projects (like tumbleweed!) we'll simply fade into obscurity. And no, you won't get more Factory testers with that 'strategy'.
/Jos
Togan
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 2012-09-26 08:32, DuBois, Scott L. wrote:
Wow!? Bravo! I vote for stability.
Remember:
80% Use MS 7.5% Use Apple 1.5% Use Linux which is divided into how many variations of which we are one?
Focus on Grandma, but offer up to Ad.
Don't focus too much on grandma - Ad does not want to be treated like a senile person. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Bryen M Yunashko <suserocks@bryen.com> [09-12-12 10:34]:
On Wed, 2012-09-12 at 09:53 +0200, Andreas Jaeger wrote:
Btw. we have two ways to go back to the normal iteration - going to March 2013 or even July 2013,
That would redefine what the .x means, although it has no technical impact and perhaps we shouldn't spend too much time worrying about it, but here's what .x currently means.
.1 = November .2 = July .3 = March
Pushing back 12.3 to July 2013 would obliterate what the .x means. Again, no technical impact, just a marketing one, which should be the least of our concerns in this context right now.
In fact, I think in the long term, we're going to have to drop what .x means logically because our lesson learned here is that the new definition we voted upon became broken after only just one successful release date (12.1).
Or, perhaps pass on 12.3 and go to 13.1? -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 12 Sep 2012 09:33:32 -0500 Bryen M Yunashko <suserocks@bryen.com> wrote:
In fact, I think in the long term, we're going to have to drop what .x means logically because our lesson learned here is that the new definition we voted upon became broken after only just one successful release date (12.1).
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle. Put obstacle(s) in a people way and it will happen what always happened, they will change path to avoid it. Make that obstacle course and they will avoid whole area. The only advantage that Ubuntu and Mint have over the rest of us is that they are trying to level ground for their users, and they go as far as to think about paper cuts: http://en.wikipedia.org/wiki/Paper_cut_%28Ubuntu%29 . What I would propose as development goal for next release is to stop pretending that we are some kind of elite club for hackers that can solve any problem with a release. While it can appear good to developers, it results in a smaller number of users, and consequently in lesser contributors, testing, documenting, marketing etc. And, we should really think about releasing patch levels between major releases. Tumbleweed is example how that should work. Release newer stable version, if it works keep it, if not revert to last working. When amount of updates is few hundreds MB, release patch level media. Keep old on own servers as fallback solution, give new to mirrors. Tell MirrorBrain how to handle requests. This will improve user experience: 1. Updates will not keep system busy hours after fresh installation. 2. Installation will be smoother over time allowing lesser adventurous to use openSUSE. 3. Users will have fallback option without major installation effort; fallback to release, then block offending software, now update all. ---- 1. Law of energy preservation in physics is perfectly applicable to all our activities, and it will be for as long as we are part of material world. 2. Paper cuts - small injuries that are just annoying, or in Ubuntu it means http://en.wikipedia.org/wiki/Paper_cut_%28Ubuntu%29 -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sun, 2012-09-16 at 00:25 -0500, Rajko wrote:
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle.
The reason why we re-defined our versioning was precisely because of what you said. From a marketing standpoint, we noticed a decrease in media coverage of our releases after .0's were released. People (particularly journalists) tended to perceive .1, .2, and .3 as updates to the "major release." They saw .0 as major revision and thus didn't bother to cover as much. But in fact, .0, .1, .2, and .3 were meaningless in that concept. They were just simply releases. Just as you point out. .1, .2, .3 has meaning now, but as recently proven, that meaning became broken quite easily. This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL) The more I have been thinking about the benefits of an annual release (even before the .x issue came into discussion) the more I find I *like* the idea of a once-a year release. It makes a lot of sense, at least in my corner. And literally, if things go haywire like it did with 12.2 release, you actually have a 12-month window within your release date. You could delay and still be "on-time." :-) So, I join the bandwagon to support an annual release plus a 2-year support lifecycle for each release. Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sun, Sep 16, 2012 at 8:07 PM, Bryen M Yunashko <suserocks@bryen.com> wrote:
The more I have been thinking about the benefits of an annual release (even before the .x issue came into discussion) the more I find I *like* the idea of a once-a year release. It makes a lot of sense, at least in my corner.
When explained this way, I second this motion for annual release. openSUSE-12 or openSUSE-13 and so on and so forth seems intuitive. Not to throw too much of a monkey wrench at the subject, but as I understand it, the folks at Ubuntu use the year.month as in 11.04 would be 2011.April if anyone would be interested in going that route. However, if we just have the release year then things are a bit more simplified. Simple is good and easy to follow (IMHO). On Sun, Sep 16, 2012 at 8:07 PM, Bryen M Yunashko <suserocks@bryen.com> wrote:
On Sun, 2012-09-16 at 00:25 -0500, Rajko wrote:
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle.
The reason why we re-defined our versioning was precisely because of what you said. From a marketing standpoint, we noticed a decrease in media coverage of our releases after .0's were released. People (particularly journalists) tended to perceive .1, .2, and .3 as updates to the "major release." They saw .0 as major revision and thus didn't bother to cover as much.
But in fact, .0, .1, .2, and .3 were meaningless in that concept. They were just simply releases. Just as you point out. .1, .2, .3 has meaning now, but as recently proven, that meaning became broken quite easily.
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
The more I have been thinking about the benefits of an annual release (even before the .x issue came into discussion) the more I find I *like* the idea of a once-a year release. It makes a lot of sense, at least in my corner.
And literally, if things go haywire like it did with 12.2 release, you actually have a 12-month window within your release date. You could delay and still be "on-time." :-)
So, I join the bandwagon to support an annual release plus a 2-year support lifecycle for each release.
Bryen
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Quoting Bryen M Yunashko <suserocks@bryen.com>:
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
If we want to consider it (not advocating for or against here): The 'upcoming release' (currently named 12.3, scheduled 'some-when in 2013' would be the perfect candidate to introduce it: - If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme) and is > 12.2, which was the latest release, thus not breaking the 'counting scheme' - If we call it openSUSE 2013, then well, the point is a bit moot.. this would always work. A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then. Simple example: GNOME has 2 releases per year; if we happen to release openSUSE 13 (assumed name) with GNOME 3.8 (assumed based on releases), waiting a whole year for a new release will make a lot of users' frustrated' (for not having the latest and greatest). Offering 'official respins' of openSUSE 13 + GNOME 3.10 (or whatever it will be called...) could help us focus the main resource on openSUSE 14 after the release, yet allow for some more media coverage during the year we bake the new release. Of course, the most 'difficult' part with those respins would be compatibility with 'other desktops'; I could foresee issues with updates that could potentially break other stuff (think new gtk, new glib, new NetworkManager, new <name anything>). And no, I simply use GNOME as example here as I'm much closer to this development, but I'm sure the same counts for KDE, LXDE, XFCE, MATE, [...] Best regards, Dominique -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/17/2012 09:59 AM, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Bryen M Yunashko <suserocks@bryen.com>:
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
If we want to consider it (not advocating for or against here): The 'upcoming release' (currently named 12.3, scheduled 'some-when in 2013' would be the perfect candidate to introduce it: - If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme) and is > 12.2, which was the latest release, thus not breaking the 'counting scheme' - If we call it openSUSE 2013, then well, the point is a bit moot.. this would always work.
A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then. Simple example: GNOME has 2 releases per year; if we happen to release openSUSE 13 (assumed name) with GNOME 3.8 (assumed based on releases), waiting a whole year for a new release will make a lot of users' frustrated' (for not having the latest and greatest).
Offering 'official respins' of openSUSE 13 + GNOME 3.10 (or whatever it will be called...) could help us focus the main resource on openSUSE 14 after the release, yet allow for some more media coverage during the year we bake the new release. Of course, the most 'difficult' part with those respins would be compatibility with 'other desktops'; I could foresee issues with updates that could potentially break other stuff (think new gtk, new glib, new NetworkManager, new <name anything>). And no, I simply use GNOME as example here as I'm much closer to this development, but I'm sure the same counts for KDE, LXDE, XFCE, MATE, [...]
Best regards, Dominique
This plan could be easily implemented with Tumbleweed releasing stable versions of KDE, GNOME etc while kernel updates happen only once a year during release. Perhaps Tumbleweed can be split to Tumbleweed and Tumbleweed:Kernel repositories. +1 on the openSUSE 13 naming scheme, vs openSUSE 2013 -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 17 Sep 2012 08:59:41 +0200 "Dominique Leuenberger a.k.a DimStar" <DimStar@openSUSE.org> wrote: ...
- If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme)...
:) Even further as 100 to 999 is just fine. First time our offspring will have to discuss new version scheme is next millennium. ( There will be no buffer overflow when third digit is added :)
A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then.
With one years release cycle it is actually mandatory to have respins. What that will bring: * Obviously, buzz for a whole year :) * Users will get newer software in a Tumbleweed fashion; unchanged base system with newer software including kernel device drivers. Respins can be Tumbleweed snapshots, which will have additional positive effect; in a case of problems that will require fallback to previous state, change will be not so drastic as it is now. * Software integrators will have more time for a base system as more software updates will happen without backporting effort. * More users will be able to try openSUSE when is well debugged and more suitable for them. * From that group some will move to earlier releases, which at the end, when they come to the Factory, will increase integration support base - testers, bug reporters and debuggers. * This will also correct current situation where installation mediums are always with some defects and always some group of users can't install without serious help. * Problem-less installation will lower pressure on support channels for basic installation help, opening opportunity to discuss other software issues and improve quality of distribution. In short, one year cycle and respins will solve few problem that project is facing right now, and at the same time increase user satisfaction. ...
Offering 'official respins' of openSUSE 13 + GNOME 3.10 (or whatever it will be called...)
The name for respins should be simple and in accordance with expectations of people that follow software development with major.minor part. I don't buy in total simplification as the best option and the reason is exactly your example. * How to address release in a short form "13 + GNOME" instead of 13.1. * Also it is telling KDE users they don't have to look there, while it can be some improved software that they can use. A bit of mystery is good. ...
Of course, the most 'difficult' part with those respins would be compatibility with 'other desktops';
If we follow Tumbleweed example, then incompatible software that break other can't enter the main repo. Either, it must wait next release, or it can be offered as an unofficial Live CD, with clear statement that is not suitable to install another desktops and give a reason for that. I don't think that many will complain about that limitation.
Best regards, Dominique
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
From what I'm reading in this thread, it sounds like an annual release would be beneficial all around starting with next years first annual kick-off of openSUSE 13.
With the exception of some logistics of how to handle the releases of associated software, (IMHO) these are after all separate from our OS. When GNOME or KDE releases their next version prior to the release of our OS, it will be handled just as any other software separate from the OS itself. Just as Firefox or LibreOffice or GIMP or any other software which is commonly used and packaged with our distribution, if a user chooses to upgrade those individual identities as they are made available from their respective development community then of course they may do so and we (openSUSE) should provide all reasonable support to help facilitate their operation on our platform without undue hardship to our programming team. Otherwise, as usual, an officially supported version of the same popular software will be provided with the next release as it always has been in the past. A good example of this is KDE 4.8 "officially" supported with 12.2 when 4.9 is out and available for those souls who wish to be "bleeding edge". On Mon, Sep 17, 2012 at 7:21 PM, Rajko <rmatov101@charter.net> wrote:
On Mon, 17 Sep 2012 08:59:41 +0200 "Dominique Leuenberger a.k.a DimStar" <DimStar@openSUSE.org> wrote:
...
- If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme)...
:)
Even further as 100 to 999 is just fine. First time our offspring will have to discuss new version scheme is next millennium. ( There will be no buffer overflow when third digit is added :)
A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then.
With one years release cycle it is actually mandatory to have respins. What that will bring:
* Obviously, buzz for a whole year :)
* Users will get newer software in a Tumbleweed fashion; unchanged base system with newer software including kernel device drivers. Respins can be Tumbleweed snapshots, which will have additional positive effect; in a case of problems that will require fallback to previous state, change will be not so drastic as it is now.
* Software integrators will have more time for a base system as more software updates will happen without backporting effort.
* More users will be able to try openSUSE when is well debugged and more suitable for them.
* From that group some will move to earlier releases, which at the end, when they come to the Factory, will increase integration support base - testers, bug reporters and debuggers.
* This will also correct current situation where installation mediums are always with some defects and always some group of users can't install without serious help.
* Problem-less installation will lower pressure on support channels for basic installation help, opening opportunity to discuss other software issues and improve quality of distribution.
In short, one year cycle and respins will solve few problem that project is facing right now, and at the same time increase user satisfaction.
...
Offering 'official respins' of openSUSE 13 + GNOME 3.10 (or whatever it will be called...)
The name for respins should be simple and in accordance with expectations of people that follow software development with major.minor part.
I don't buy in total simplification as the best option and the reason is exactly your example. * How to address release in a short form "13 + GNOME" instead of 13.1. * Also it is telling KDE users they don't have to look there, while it can be some improved software that they can use. A bit of mystery is good.
...
Of course, the most 'difficult' part with those respins would be compatibility with 'other desktops';
If we follow Tumbleweed example, then incompatible software that break other can't enter the main repo. Either, it must wait next release, or it can be offered as an unofficial Live CD, with clear statement that is not suitable to install another desktops and give a reason for that. I don't think that many will complain about that limitation.
Best regards, Dominique
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 17 Sep 2012 20:10:14 -0700 "DuBois, Scott L." <ranger@roguehorse.com> wrote:
From what I'm reading in this thread, it sounds like an annual release would be beneficial all around starting with next years first annual kick-off of openSUSE 13.
Everyone is talking about 12.3. I think that people don't like 13 and first of annual releases will happen in 2014 :) (if ever)
... A good example of this is KDE 4.8 "officially" supported with 12.2 when 4.9 is out and available for those souls who wish to be "bleeding edge".
It is not about bleeding edge, it is about fixed bugs, at least that is the reason I started to use last available stable release. Before first successful use of such repos I was reluctant to use anything, but official. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 18 of September 2012 23:59EN, Rajko wrote:
On Mon, 17 Sep 2012 20:10:14 -0700
A good example of this is KDE 4.8 "officially" supported with 12.2 when 4.9 is out and available for those souls who wish to be "bleeding edge".
It is not about bleeding edge, it is about fixed bugs, at least that is the reason I started to use last available stable release.
Fixed some and introduced other. KDE 4.8 -> 4.9 is not only a bugfix release. Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am Mittwoch, 19. September 2012, 10:15:11 schrieb Michal Kubeček:
On Tuesday 18 of September 2012 23:59EN, Rajko wrote:
It is not about bleeding edge, it is about fixed bugs, at least that is the reason I started to use last available stable release.
Fixed some and introduced other. KDE 4.8 -> 4.9 is not only a bugfix release.
Indeed. 4.9 bugs get fixed, 4.8 bugs not. Thus people are stuck with the bugs until the next openSUSE release. Sven -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 19 Sep 2012 13:10:08 +0200 Sven Burmeister <sven.burmeister@gmx.net> wrote:
Thus people are stuck with the bugs until the next openSUSE release.
Only those that did not figure out by now that: ** 4.9 bugs get fixed, 4.8 bugs not ** It is not that strict, though. Security bugs and show stoppers will be fixed, but added functionality, and code optimizations will stay with newer version. It is nothing to blame developers. If one would backport all stuff from newer version then what would be the difference in a code - none, and then what would be purpose of versions - also none. In other words riding the tide is not that bad idea. You get new bugs and regressions that are fixed fast, and in exchange you get better, faster code. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
"DuBois, Scott L." <ranger@roguehorse.com> wrote:
From what I'm reading in this thread, it sounds like an annual release would be beneficial all around starting with next years first annual kick-off of openSUSE 13.
Why is the default solution to problems always "lengthen the release cycle by 2 months" anyway? Once problems arose, the cycle was first lengthened from 6 months to 8, then 12.2 took 10 months and now 12 months are being discussed. Seriously: lengthening the cycle didn't work in the past. Why would it suddenly work? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Friday, September 21, 2012 01:07:05 Markus wrote:
"DuBois, Scott L." <ranger@roguehorse.com> wrote:
From what I'm reading in this thread, it sounds like an annual release would be beneficial all around starting with next years first annual kick-off of openSUSE 13.
Why is the default solution to problems always "lengthen the release cycle by 2 months" anyway? Once problems arose, the cycle was first lengthened from 6 months to 8, then 12.2 took 10 months and now 12 months are being discussed.
Seriously: lengthening the cycle didn't work in the past. Why would it suddenly work?
'just' making the release cycle longer is of course no solution to anything. It does give us a longer supported release cycle - something MANY of our users want. It also gives us the ability to, say, plan longer stabilization phases. And have a smarter release date (the moving date sucks - picking, say, November 20 2013 as release date means we get AND the latest GNOME and KDE, AND we release a while after Ubuntu and Fedora, benefiting from bugfixes for issues they bumped into. For example). And obviously, it does lower the amount of release management work on a year, although it might create a higher peak - depending on how we do it. It also possibly creates a marketing issue (less releases is less attention) but that is also something I think we can work with. So, a 1 year cycle is as much a means in itself as it is meant to solve a problem.
On 17.09.2012 08:59, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Bryen M Yunashko <suserocks@bryen.com>:
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
If we want to consider it (not advocating for or against here): The 'upcoming release' (currently named 12.3, scheduled 'some-when in 2013' would be the perfect candidate to introduce it: - If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme) and is > 12.2, which was the latest release, thus not breaking the 'counting scheme' - If we call it openSUSE 2013, then well, the point is a bit moot.. this would always work.
A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then. Simple example: GNOME has 2 releases per year; if we happen to release openSUSE 13
I see a *huge* fragementation issue with a one year cycle - especially if people dance the Tumbleweed and Respin dance. This would mean even less people work even less time on Factory. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Tirsdag den 18. september 2012 15:30:03 skrev Stephan Kulow:
On 17.09.2012 08:59, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Bryen M Yunashko <suserocks@bryen.com>:
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
If we want to consider it (not advocating for or against here): The 'upcoming release' (currently named 12.3, scheduled 'some-when in 2013' would be the perfect candidate to introduce it: - If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme) and is > 12.2, which was the latest release, thus not breaking the 'counting scheme' - If we call it openSUSE 2013, then well, the point is a bit moot.. this would always work.
A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then. Simple example: GNOME has 2 releases per year; if we happen to release openSUSE 13
I see a *huge* fragementation issue with a one year cycle - especially if people dance the Tumbleweed and Respin dance. This would mean even less people work even less time on Factory.
Yep. The people arguing for a 12 month release cycle seem to have some questionable assumptions, e.g. that this automatically makes releases much more stable and polished, and that the same number of people will contribute and test under those circumstances. Personally I'm very much for sticking to the 8 months. 12 months is too darn long for users and developers alike - and 6 months is too short. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Personally I'm very much for sticking to the 8 months. 12 months is too darn long for users and developers alike - and 6 months is too short.
The feeling I have is that users actually don't want to be updating GB's all the time; I saw Fedora discussions about this where the opposite was proven; Ubuntu LTS releases have a very solid/strong user base for normal users (not the hype 'riders'); Debian stable is probably an example of that also... Are you really sure that normal users think like that ? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Tirsdag den 18. september 2012 16:26:23 skrev Nelson Marques:
Personally I'm very much for sticking to the 8 months. 12 months is too darn long for users and developers alike - and 6 months is too short.
The feeling I have is that users actually don't want to be updating GB's all the time; I saw Fedora discussions about this where the opposite was proven; Ubuntu LTS releases have a very solid/strong user base for normal users (not the hype 'riders'); Debian stable is probably an example of that also...
Are you really sure that normal users think like that ?
There are of course many different types of users. Clearly many users just want to install once and use the same thing for 10-15 years without anything ever changing - for others 8 months is far too long without version numbers increasing. So it's about balance. Fedora users are forced to upgrade every 13 months. For openSUSE currently it's 18 months. With a 12 month cycle _maybe_ that would be increased to 24 months - so not that much difference - assuming the lifetime would be increased at all. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
There are of course many different types of users. Clearly many users just want to install once and use the same thing for 10-15 years without anything ever changing - for others 8 months is far too long without version numbers increasing. So it's about balance.
Fedora users are forced to upgrade every 13 months. For openSUSE currently it's 18 months. With a 12 month cycle _maybe_ that would be increased to 24 months - so not that much difference - assuming the lifetime would be increased at all.
So, we agree that there's fragmentation on the user base; and it's somehow 'common sense' to believe that we need to know and understand our user base, so we can take the proper calls on situations like this, correct? The big question is... "how do we do that ?"... Traditionally this answer should be provided by Marketing, correct? So what can Marketing do for us? (or should we just jump in big and bad based on 'assumptions' ?) NM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Nelson Marques <nmo.marques@gmail.com> [09-18-12 11:44]:
There are of course many different types of users. Clearly many users just want to install once and use the same thing for 10-15 years without anything ever changing - for others 8 months is far too long without version numbers increasing. So it's about balance.
Fedora users are forced to upgrade every 13 months. For openSUSE currently it's 18 months. With a 12 month cycle _maybe_ that would be increased to 24 months - so not that much difference - assuming the lifetime would be increased at all.
So, we agree that there's fragmentation on the user base; and it's somehow 'common sense' to believe that we need to know and understand our user base, so we can take the proper calls on situations like this, correct?
The big question is... "how do we do that ?"...
Tumbleweed and Evergreen :^) and both are working for me
Traditionally this answer should be provided by Marketing, correct? So what can Marketing do for us? (or should we just jump in big and bad based on 'assumptions' ?)
I don't believe any requirements for marketing information is necessary as Tumbleweed and Evergreen cover/blanket exceptions to users outside of <current> with note that some would like Evergreen to last longer.... -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
2012/9/18 Patrick Shanahan <paka@opensuse.org>:
* Nelson Marques <nmo.marques@gmail.com> [09-18-12 11:44]:
There are of course many different types of users. Clearly many users just want to install once and use the same thing for 10-15 years without anything ever changing - for others 8 months is far too long without version numbers increasing. So it's about balance.
Fedora users are forced to upgrade every 13 months. For openSUSE currently it's 18 months. With a 12 month cycle _maybe_ that would be increased to 24 months - so not that much difference - assuming the lifetime would be increased at all.
So, we agree that there's fragmentation on the user base; and it's somehow 'common sense' to believe that we need to know and understand our user base, so we can take the proper calls on situations like this, correct?
The big question is... "how do we do that ?"...
Tumbleweed and Evergreen :^)
Out of context... "how do we do that" as in getting to know our userbase.
and both are working for me
Traditionally this answer should be provided by Marketing, correct? So what can Marketing do for us? (or should we just jump in big and bad based on 'assumptions' ?)
I don't believe any requirements for marketing information is necessary as Tumbleweed and Evergreen cover/blanket exceptions to users outside of <current> with note that some would like Evergreen to last longer....
Like I said you are out of context. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Nelson Marques <nmo.marques@gmail.com> [09-18-12 11:57]:
2012/9/18 Patrick Shanahan <paka@opensuse.org>:
Like I said you are out of context.
more like out of touch with reality. you missed it. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Tirsdag den 18. september 2012 16:42:44 skrev Nelson Marques:
There are of course many different types of users. Clearly many users just want to install once and use the same thing for 10-15 years without anything ever changing - for others 8 months is far too long without version numbers increasing. So it's about balance.
Fedora users are forced to upgrade every 13 months. For openSUSE currently it's 18 months. With a 12 month cycle _maybe_ that would be increased to 24 months - so not that much difference - assuming the lifetime would be increased at all.
So, we agree that there's fragmentation on the user base; and it's somehow 'common sense' to believe that we need to know and understand our user base, so we can take the proper calls on situations like this, correct?
The big question is... "how do we do that ?"...
Traditionally this answer should be provided by Marketing, correct? So what can Marketing do for us? (or should we just jump in big and bad based on 'assumptions' ?)
But this is not a traditional commercial enterprise. This is a free software community project - so users are not the most important thing - the packagers who work on openSUSE:Factory are. Good luck finding the "true facts". Of course we need assumptions - only we should be conscious of them, and justify them as best we can. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 18 Sep 2012 16:42:44 +0100, Nelson Marques wrote:
So, we agree that there's fragmentation on the user base; and it's somehow 'common sense' to believe that we need to know and understand our user base, so we can take the proper calls on situations like this, correct?
The big question is... "how do we do that ?"...
Traditionally this answer should be provided by Marketing, correct? So what can Marketing do for us? (or should we just jump in big and bad based on 'assumptions' ?)
The obvious answer to that question is "you survey the userbase". The / real/ question is "how do you get people who are in the userbase to answer the survey in enough numbers to have a statistically valid sample?" Because without a good statistical sampling, you're not dealing with useful data that helps make a good data-driven decision. That typically means incentives. The next big question also is in constructing a survey that asks valid questions without assuming or suggesting an answer. The single biggest mistake people make when constructing surveys is to ask questions in a way that implies or infers there's a "correct" answer or a "desired" answer. The second mistake that's made is to ask questions that are not clear - using double negatives, poor sentence construction, etc. That becomes more difficult if you publish the survey in multiple languages. The third mistake is asking open-ended questions. In general, you want questions that have answers that are discrete and/or scale based ("on a scale of 1-5, where 1 means [...]"). Fill-in-the-blank/essay style responses take a lot of time to tabulate, and require a lot more work to interpret - and an incorrect interpretation of the respondent's intention can lead to a wrong result (from the respondent's perspective). The fourth is in asking questions that don't ultimately help make decisions. I can't begin to describe the number of surveys I've seen where questions were asked that had no apparent practical value (and in a few cases, surveys I worked with respondent data where the question asked clearly had no practical value to what was being researched). Building a good survey isn't a matter of going up to SurveyMonkey and asking a few questions. You /have/ to start with the goals in mind, and then take some time to determine what questions actually help define a direction, and then make sure the wording doesn't slant the responses to a particular pre-determined response - and that's not always a conscious thing. 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 09/18/2012 11:42 AM, Nelson Marques wrote:
There are of course many different types of users. Clearly many users just want to install once and use the same thing for 10-15 years without anything ever changing - for others 8 months is far too long without version numbers increasing. So it's about balance.
Fedora users are forced to upgrade every 13 months. For openSUSE currently it's 18 months. With a 12 month cycle _maybe_ that would be increased to 24 months - so not that much difference - assuming the lifetime would be increased at all.
So, we agree that there's fragmentation on the user base; and it's somehow 'common sense' to believe that we need to know and understand our user base, so we can take the proper calls on situations like this, correct?
The big question is... "how do we do that ?"...
Traditionally this answer should be provided by Marketing, correct? So what can Marketing do for us? (or should we just jump in big and bad based on 'assumptions' ?)
We can always do a survey on our users. First we need to define clearly the options... Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
We can always do a survey on our users. First we need to define clearly the options...
A survey most likely takes more resources; openSUSE has two great events coming, in which I assume people are expecting users (and in Prague you will most likely have 'potential users'). So a maybe more reasonable approach would be based on focus groups which is most likely more profitable to openSUSE. This would be most likely my first pick, since surveys are not really realiable... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 18 Sep 2012 22:59:11 +0100, Nelson Marques wrote:
We can always do a survey on our users. First we need to define clearly the options...
A survey most likely takes more resources; openSUSE has two great events coming, in which I assume people are expecting users (and in Prague you will most likely have 'potential users'). So a maybe more reasonable approach would be based on focus groups which is most likely more profitable to openSUSE.
Sampling a small group of users that is not representative of the userbase isn't the way to approach this. You need to talk to a larger representative sample than "those who can afford to go to the conference in Prague". Not that getting opinions there is a bad idea, but it's not the only source for data.
This would be most likely my first pick, since surveys are not really realiable...
I would disagree that they're not reliable - they're reliable when they're constructed properly. They're not reliable when no thought is put into what the purpose of the survey is. It's not something you can spend 30 minutes designing and then say "well, that survey's done". It's got to be planned, and you need to collect data points that actually answer your questions, as I described in an earlier post. You know the old saying - garbage in, garbage out. It's important to ask the right questions to get value out of a survey. 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
A survey most likely takes more resources; openSUSE has two great events coming, in which I assume people are expecting users (and in Prague you will most likely have 'potential users'). So a maybe more reasonable approach would be based on focus groups which is most likely more profitable to openSUSE.
Sampling a small group of users that is not representative of the userbase isn't the way to approach this. You need to talk to a larger representative sample than "those who can afford to go to the conference in Prague".
If you take things seriously, it's not necessarily a 'small group'; one quick example that I know from the top of my head. Portugal as 11 million inhabitants; A sample for this population would be 1064 questionnaires to get a 3/5% error margin. Problem #1 - How large is the openSUSE user base... This defeats the whole purpose of having a decent survey; but your are right, technically, it's impossible since we can't measure our Universe.
Not that getting opinions there is a bad idea, but it's not the only source for data.
It's all about resources. We use what we have, and if openSUSE invested in the conference/summit, I don't see why not squeezing some juice out of it. Spare a few millions to Nielsen or any other like them, and I'm sure they will provide outstanding work... the big issue is... do we have a few millions to spend with AC Nielsen ? :) (or any other like them? I tend to say they are the best ones since when it comes to consumer profiling they are the best).
This would be most likely my first pick, since surveys are not really realiable...
I would disagree that they're not reliable - they're reliable when they're constructed properly. They're not reliable when no thought is put into what the purpose of the survey is. It's not something you can spend 30 minutes designing and then say "well, that survey's done". It's got to be planned, and you need to collect data points that actually answer your questions, as I described in an earlier post.
See problem #1 above. But yeah you are right, we just have a problem of resources;
You know the old saying - garbage in, garbage out. It's important to ask the right questions to get value out of a survey.
I would put it this way... If you have resources and want a professional work, it means the world... If do it poorly, it means nothing :) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 20 Sep 2012 00:15:11 +0100, Nelson Marques wrote:
Problem #1 - How large is the openSUSE user base... This defeats the whole purpose of having a decent survey; but your are right, technically, it's impossible since we can't measure our Universe.
No, that's not what I said. I can pretty much guarantee you that when a more technical subset of users attend a conference, their needs are not going to reflect the needs of the non-technical userbase. We can get a rough measure of our universe, though - we know (or should know) how may times openSUSE has been downloaded from the official sites (via whatever means). While downloads are not a 1:1 relationship to installs, it's still a pretty good measure of how many users there are.
Not that getting opinions there is a bad idea, but it's not the only source for data.
It's all about resources. We use what we have, and if openSUSE invested in the conference/summit, I don't see why not squeezing some juice out of it.
Did you not see where I said "of course we should ask at the conferences"? I'm pretty sure I said that, Nelson. I just said that that shouldn't be the /only/ place that discussion takes place.
Spare a few millions to Nielsen or any other like them, and I'm sure they will provide outstanding work... the big issue is... do we have a few millions to spend with AC Nielsen ? :) (or any other like them? I tend to say they are the best ones since when it comes to consumer profiling they are the best).
Yes, because the *only* two options are to do a half-assed job or to spend millions of dollars to hire a professional polling company. That's a straw man argument and you know it.
See problem #1 above. But yeah you are right, we just have a problem of resources;
Hmmm, did I miss where we asked if we had anyone in the active communities who had experience in crafting customer/user surveys? If we haven't asked, then how do we know we have a "resource problem"?
You know the old saying - garbage in, garbage out. It's important to ask the right questions to get value out of a survey.
I would put it this way... If you have resources and want a professional work, it means the world... If do it poorly, it means nothing :)
And there is middle ground between "do nothing because it's 'impossible'" and "spend millions of dollars to hire an AC Nielsen". I would suggest that instead of arguing against it, we actually have a discussion about what we want to learn about our userbase. That's useful whether we do an informal discussion at the conferences or if we do a survey. In either case, knowing the right questions to ask to get the information we're looking for is /critical/ to getting useful information. 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 2012-09-18 17:34 (GMT+0200) Martin Schlander composed:
Fedora users are forced to upgrade every 13 months. For openSUSE currently it's 18 months. With a 12 month cycle _maybe_ that would be increased to 24 months - so not that much difference - assuming the lifetime would be increased at all.
24 months would be ideal for me, allowing to upgrade the same month every other year without going out of support, like I used to do with the initial openSUSE releases. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/18/2012 10:06 AM, Martin Schlander wrote:
Yep. The people arguing for a 12 month release cycle seem to have some questionable assumptions, e.g. that this automatically makes releases much more stable and polished, and that the same number of people will contribute and test under those circumstances.
Personally I'm very much for sticking to the 8 months. 12 months is too darn long for users and developers alike - and 6 months is too short.
I agree. We are already catching heat because 12.2 contains KDE 4.8.x and not 4.9.x. Why do anything to make that sort of situation worse? Just because we had one delayed release is no reason to discard the 8 month cycle. Larry -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 18 Sep 2012 14:06:16 -0500, Larry Finger wrote:
Personally I'm very much for sticking to the 8 months. 12 months is too darn long for users and developers alike - and 6 months is too short.
I agree. We are already catching heat because 12.2 contains KDE 4.8.x and not 4.9.x. Why do anything to make that sort of situation worse? Just because we had one delayed release is no reason to discard the 8 month cycle.
Is it necessarily true that extending the development cycle would make this worse? Whatever release cycle we use, there's going to be component projects (KDE, GNOME, etc) that are close to release or early in their release cycle. I don't know that extending the release cycle makes this problem worse (defined as "a more frequent occurrence") - or is there another factor that I'm missing here? 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 09/18/2012 04:52 PM, Jim Henderson wrote:
On Tue, 18 Sep 2012 14:06:16 -0500, Larry Finger wrote:
Personally I'm very much for sticking to the 8 months. 12 months is too darn long for users and developers alike - and 6 months is too short.
I agree. We are already catching heat because 12.2 contains KDE 4.8.x and not 4.9.x. Why do anything to make that sort of situation worse? Just because we had one delayed release is no reason to discard the 8 month cycle.
Is it necessarily true that extending the development cycle would make this worse? Whatever release cycle we use, there's going to be component projects (KDE, GNOME, etc) that are close to release or early in their release cycle.
I don't know that extending the release cycle makes this problem worse (defined as "a more frequent occurrence") - or is there another factor that I'm missing here?
If you just miss a major release, users have to wait until the next release. The probability of just missing does not change unless the release cycle of the product matches the oS release, only the time until the new version is part of openSUSE. Larry -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 2012-09-18 at 17:09 -0500, Larry Finger wrote:
If you just miss a major release, users have to wait until the next release. The probability of just missing does not change unless the release cycle of the product matches the oS release, only the time until the new version is part of openSUSE.
Larry
GNOME 3.6 is scheduled for release on September 26, if I'm not mistaken. Are you saying we should base our release schedule on these component releases? Should we have waited until October to release 12.2? Besides, isn't there a testing/freeze process that ensures the reputation of openSUSE as stable? We'd have to extend way past the "just-missed" release dates of those components in order to be inclusive +stable. I'm against the idea of our release cycle, whether it is 8 months, 12 months, or whatever being dictated by the releases of upstream projects. While many of us have given some sound arguments for a 12-month release cycle, and I'm still in favor of that proposition, ultimately the final decision on what our release cycle will be has to be primarily considered by what impacts the technical development will experience. I think we've given every reason why we would want such-and-such from a end-user standpoint. Now we need to hear directly from the devs how this affects their work flow and how they feel things should be changed (or kept the same.) Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Bryen M Yunashko wrote:
Besides, isn't there a testing/freeze process that ensures the reputation of openSUSE as stable?
There is? We have alphas and beats and RCs but I don't think there's any actual "process" wrt testing. I mean, there is always plenty of stuff that is never tested. -- Per Jessen, Zürich (12.6°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am Mittwoch, 19. September 2012, 07:42:15 schrieb Per Jessen:
Bryen M Yunashko wrote:
Besides, isn't there a testing/freeze process that ensures the reputation of openSUSE as stable?
There is? We have alphas and beats and RCs but I don't think there's any actual "process" wrt testing. I mean, there is always plenty of stuff that is never tested.
If you wait some weeks without changing anything and not having data loss bugs in the packages you can put the "openSUSE stable" label on it. If you offer that set of packages to users and wait some weeks before shipping it you can put the "openSUSE stable and openSUSE tested" label on it and release it as an openSUSE release. The latter will make it superior to any of the following upstream (bugfix) releases for that package because those are only "upstream stable and upstream tested", no matter how long they are tested. (upstream includes openSUSE users btw. but forget about that, not a valid argument, because upstream creates and fixes regressions while openSUSE only keeps unfixed bugs). You might claim that any package version which was used by openSUSE users for the same amount of time is equally well tested and stable – but that's not how it works, because it was not released as part of an openSUSE release! No, no, no. Sven -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/19/2012 12:42 AM, Per Jessen wrote:
Bryen M Yunashko wrote:
Besides, isn't there a testing/freeze process that ensures the reputation of openSUSE as stable?
There is? We have alphas and beats and RCs but I don't think there's any actual "process" wrt testing. I mean, there is always plenty of stuff that is never tested.
We do have a testing "process". In 2009, a group known as the openSUSE Testing Core Team was organized by Holger Sickenberg with an initial membership of 25. For details, see http://en.opensuse.org/openSUSE:Testing_Core_team. Predictably, a large number of those with membership have never contributed, or contributed very little, even though only one of that group has formally resigned. In fact, only a handful of the members are regular contributors. An offshoot of the TCT has been the openQA system (http://openqa.opensuse.org/) that was started by Bernhard M. Wiedemann, who chairs our on-line meetings. Nearly all builds of the installation media are run through the automated tests, which catch many of the most glaring problems that affect the installation process. I cannot speak for the rest of the members, but I test every MS, Beta, and RC release, as well as many of the intermediate builds. Until MS4, or so, all tests are done in virtual machines. Testing on real machines starts with a box that is used strictly for this purpose. Once that is working, then that release gets installed on my main work machine, and I use the new release routinely until the next cycle. My main emphasis is on finding those problems that prevent installation, i.e. those bugs that cannot be repaired by updating a package in the repos. Next I make certain that the tools that I use regularly work; however, my work load uses a limited portion of the overall system. Besides the standard utilities, the major tested packages include the KDE desktop, Firefox, Thunderbird, Konversation, and K3b. Clearly, the thoroughness of the testing is hurt by the limited number of testers and the small number of hardware configurations that they possess. Yes, plenty of stuff never gets tested by other than the package maintainers, and there are critical sections of systemd (as an example) that never get tested on our systems. Despite this, we do have a testing "process". Larry -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 18 Sep 2012 17:09:27 -0500 Larry Finger <Larry.Finger@lwfinger.net> wrote:
If you just miss a major release, users have to wait until the next release. ...
It is not like that. On IRC #suse just about everyone will advise new users that have problems to switch to KR49 [1]. So far that mostly solved a problem, or at worst did nothing. In other words, who wants newer desktop version can have one independent of release schedule. Those with security concerns should be aware that upstream is fixing security problems too. I know there is equivalent for Gnome, and possibly other desktops. General solution for those that want newer and stable software is to use Tumbleweed. This makes number of candidates that one have to wait for much smaller. Someone with development experience can list and explain this part. [1] KR49 repo is this: http://download.opensuse.org/repositories/KDE:/Release:/49/ -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 18 Sep 2012 17:09:27 -0500, Larry Finger wrote:
Is it necessarily true that extending the development cycle would make this worse? Whatever release cycle we use, there's going to be component projects (KDE, GNOME, etc) that are close to release or early in their release cycle.
I don't know that extending the release cycle makes this problem worse (defined as "a more frequent occurrence") - or is there another factor that I'm missing here?
If you just miss a major release, users have to wait until the next release. The probability of just missing does not change unless the release cycle of the product matches the oS release, only the time until the new version is part of openSUSE.
Oh, I see - that makes sense. Don't know why I didn't see that before. :) 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 Tue, 18 Sep 2012 15:30:03 +0200 Stephan Kulow <coolo@suse.de> wrote:
I see a *huge* fragementation issue with a one year cycle - especially if people dance the Tumbleweed and Respin dance. This would mean even less people work even less time on Factory.
Typical Tumbleweed and Respin users are not Factory users. Factory: They enjoy experimenting and fixing problems. They don't need any level of dependability as they use other computer for day to day activity. Experience level: High. Recruiting base: Tumbleweed users. Preconditions: Multiple computers, technical background. Tumbleweed: They want new software with occasional breakage and low chance of data loss. Option to fallback to older software as a quick fix to use it again is important to them. They will, most likely, help fixing newer version as they want it. Precondition is that they don't have to install and configure each version every time to test it. Experience level: Medium. Recruiting base: Respin users. Preconditions: None. Respin: They want smooth installation and run, with low updates count after installation. Here we can find 99% of people introducing openSUSE to potential users and most of the people that want to try out Linux, or some other distro. Experience level: None. Recruiting base: Computer users. Preconditions: None. In short, there is no fragmentation issue. Limiting choices will keep status quo, which is releases that sometimes work out of the box, and another require serious fixing before it can be used; on the same hardware [1]. This means that sooner or later every user will hit the wall and make decision where leaving openSUSE is one of the options. Those with heavy investment in openSUSE will stay as long as viable, and those that just started will leave. [1] 12.2 KDE was bad for me. Garbled graphics, lockups. Fixed using nvidia proprietary driver. 12.1 KDE was smooth. Ran nouveau for months. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday, September 18, 2012 15:30:03 Stephan Kulow wrote:
On 17.09.2012 08:59, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Bryen M Yunashko <suserocks@bryen.com>:
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
If we want to consider it (not advocating for or against here): The 'upcoming release' (currently named 12.3, scheduled 'some-when in 2013' would be the perfect candidate to introduce it: - If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme) and is > 12.2, which was the latest release, thus not breaking the 'counting scheme' - If we call it openSUSE 2013, then well, the point is a bit moot.. this would always work.
A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then. Simple example: GNOME has 2 releases per year; if we happen to release openSUSE 13
I see a *huge* fragementation issue with a one year cycle - especially if people dance the Tumbleweed and Respin dance. This would mean even less people work even less time on Factory.
That would be a major argument against doing a 1-year release cycle. But we don't know if that'll happen or not. Maybe a poll on this to folks on - factory and our testing groups would be at least a bit helpful, I'll set something up. /Jos
Greetings, Stephan
On Thu, 20 Sep 2012 13:57:01 +0200 Jos Poortvliet <jos@opensuse.org> wrote:
But we don't know if that'll happen or not.
It is unlikely that fragmentation will happen :) People with certain skills and needs exist independent of what we provide. Not providing some flavor of openSUSE that fits skills and needs means they will not become users. http://lists.opensuse.org/opensuse-project/2012-09/msg00197.html Fears are bad advisers. Instead of fearing user base split, one should look how to use user interest in Tumbleweed (TW). TW has fairly new software, where user feedback can help to decide what software versions to include in the next release. The only precondition is that there is a channel(s) where users can publish that feedback. People looking for Respin type of media, will not use Factory, nor prerelease. Without Respin they will use last stable release, as they do now, with minimal benefits for the next release, but with drawback that they will be hit by bugs that are already solved with updates.
Maybe a poll on this to folks on - factory and our testing groups would be at least a bit helpful, I'll set something up.
Good luck :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 20.09.2012 21:49, Rajko wrote:
On Thu, 20 Sep 2012 13:57:01 +0200 Jos Poortvliet <jos@opensuse.org> wrote:
But we don't know if that'll happen or not.
It is unlikely that fragmentation will happen :)
People with certain skills and needs exist independent of what we provide. Not providing some flavor of openSUSE that fits skills and needs means they will not become users.
I was not talking about users per se, but about contributions. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Friday, September 21, 2012 10:10:46 Stephan Kulow wrote:
On 20.09.2012 21:49, Rajko wrote:
On Thu, 20 Sep 2012 13:57:01 +0200
Jos Poortvliet <jos@opensuse.org> wrote:
But we don't know if that'll happen or not.
It is unlikely that fragmentation will happen :)
People with certain skills and needs exist independent of what we provide. Not providing some flavor of openSUSE that fits skills and needs means they will not become users.
I was not talking about users per se, but about contributions.
So, ask our contributors and testers? Poll? I know it's not a perfect way of knowing what will happen but something is better than nothing. J
Greetings, Stephan
On Friday 21 September 2012 14:43:15 Jos Poortvliet wrote:
On Friday, September 21, 2012 10:10:46 Stephan Kulow wrote:
On 20.09.2012 21:49, Rajko wrote:
On Thu, 20 Sep 2012 13:57:01 +0200
Jos Poortvliet <jos@opensuse.org> wrote:
But we don't know if that'll happen or not.
It is unlikely that fragmentation will happen :)
People with certain skills and needs exist independent of what we provide. Not providing some flavor of openSUSE that fits skills and needs means they will not become users.
I was not talking about users per se, but about contributions.
So, ask our contributors and testers? Poll? I know it's not a perfect way of knowing what will happen but something is better than nothing. J
So, Rajko brought up a very substantial argument about improving our situation with regards to testing, but that might have drowned this point: do we want to have some indication to support or contradict Coolo's statement that a 1-year cycle would mean less working on and less testing of Factory? Until we have at least SOME idea about that, it's kind'a pointless to bring it up imho - the effect could be the opposite for all we know. I know a poll is not a perfect way of answering this question - more users is likely to lead to more testers and contributors but the poll won't tell us that, for one. But some data point would be useful imho.
On 24.09.2012 20:37, Jos Poortvliet wrote:
On Friday 21 September 2012 14:43:15 Jos Poortvliet wrote:
On Friday, September 21, 2012 10:10:46 Stephan Kulow wrote:
On 20.09.2012 21:49, Rajko wrote:
On Thu, 20 Sep 2012 13:57:01 +0200
Jos Poortvliet <jos@opensuse.org> wrote:
But we don't know if that'll happen or not.
It is unlikely that fragmentation will happen :)
People with certain skills and needs exist independent of what we provide. Not providing some flavor of openSUSE that fits skills and needs means they will not become users.
I was not talking about users per se, but about contributions.
So, ask our contributors and testers? Poll? I know it's not a perfect way of knowing what will happen but something is better than nothing. J
So, Rajko brought up a very substantial argument about improving our situation with regards to testing, but that might have drowned this point: do we want to have some indication to support or contradict Coolo's statement that a 1-year cycle would mean less working on and less testing of Factory?
Until we have at least SOME idea about that, it's kind'a pointless to bring it up imho - the effect could be the opposite for all we know. I know a poll is not a perfect way of answering this question - more users is likely to lead to more testers and contributors but the poll won't tell us that, for one. But some data point would be useful imho.
How much testing of factory (milestones) do you and Rajko do and how much do you expect to do if the next release is targetting end of next year? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 25 September 2012 12:48:46 Stephan Kulow wrote:
On 24.09.2012 20:37, Jos Poortvliet wrote:
On Friday 21 September 2012 14:43:15 Jos Poortvliet wrote:
On Friday, September 21, 2012 10:10:46 Stephan Kulow wrote:
On 20.09.2012 21:49, Rajko wrote:
On Thu, 20 Sep 2012 13:57:01 +0200
Jos Poortvliet <jos@opensuse.org> wrote:
But we don't know if that'll happen or not.
It is unlikely that fragmentation will happen :)
People with certain skills and needs exist independent of what we provide. Not providing some flavor of openSUSE that fits skills and needs means they will not become users.
I was not talking about users per se, but about contributions.
So, ask our contributors and testers? Poll? I know it's not a perfect way of knowing what will happen but something is better than nothing. J
So, Rajko brought up a very substantial argument about improving our situation with regards to testing, but that might have drowned this point: do we want to have some indication to support or contradict Coolo's statement that a 1-year cycle would mean less working on and less testing of Factory?
Until we have at least SOME idea about that, it's kind'a pointless to bring it up imho - the effect could be the opposite for all we know. I know a poll is not a perfect way of answering this question - more users is likely to lead to more testers and contributors but the poll won't tell us that, for one. But some data point would be useful imho.
How much testing of factory (milestones) do you and Rajko do and how much do you expect to do if the next release is targetting end of next year?
I only test the beta and the RC's. I don't see why that would change if there are changes to the release cycle. We might be able to do slightly better than a sample of two, btw. Say, ask all factory folks if they're willing to answer that question (we could even THINK about the questions, make them have some kind of validity). But if this is enough for you to conclude on the effect of release cycle on testing, fine with me. I guess the result will be that there is no effect (only half the sample is in, but it's a good start I'd say) so we can dump this argument. Great!
Greetings, Stephan
On 25.09.2012 13:52, Jos Poortvliet wrote:
I only test the beta and the RC's. I don't see why that would change if there are changes to the release cycle. And this is what most people do - now you can calculate how many months without much testing we add to factory - and remember that tumbleweed takes things from factory, so basically the testing would happen in tumbleweed -> breaking things.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 25 September 2012 14:01:53 Stephan Kulow wrote:
On 25.09.2012 13:52, Jos Poortvliet wrote:
I only test the beta and the RC's. I don't see why that would change if there are changes to the release cycle.
And this is what most people do - now you can calculate how many months without much testing we add to factory - and remember that tumbleweed takes things from factory, so basically the testing would happen in tumbleweed -> breaking things.
But the goal is a more stable end result, not a more stable factory, is it? I mean, Factory will never be stable unless we'd never put rc's and beta's etc in there and even then it'd be problematic. But I guess you argue that a more stable factory leads to more stable results. Ok, so you say for development, 6-8 month cycle = better. For users, I'd argue, a 1 year cycle is better (provided we keep delivering stuff via OBS). But that's more of a marketing thing then - that we might bet more users and thus, in time, more testers and developers is not guaranteed.
Greetings, Stephan
On Tue, 25 Sep 2012 20:40:18 +0200 Jos Poortvliet <jos@opensuse.org> wrote:
On Tuesday 25 September 2012 14:01:53 Stephan Kulow wrote:
On 25.09.2012 13:52, Jos Poortvliet wrote:
I only test the beta and the RC's. I don't see why that would change if there are changes to the release cycle.
And this is what most people do - now you can calculate how many months without much testing we add to factory - and remember that tumbleweed takes things from factory, so basically the testing would happen in tumbleweed -> breaking things.
But the goal is a more stable end result, not a more stable factory, is it? I mean, Factory will never be stable unless we'd never put rc's and beta's etc in there and even then it'd be problematic. But I guess you argue that a more stable factory leads to more stable results.
Well, it should be that way, but [1].
Ok, so you say for development, 6-8 month cycle = better.
For users, I'd argue, a 1 year cycle is better (provided we keep delivering stuff via OBS). But that's more of a marketing thing then - that we might bet more users and thus, in time, more testers and developers is not guaranteed.
[1] As Stephan said, Tumbleweed is feeding from Factory, which is interesting phenomen. People use Tumbleweed and decline to use Factory?! It seems that all boils down to the stability of a base system. In other words people actually test all, but that base system. Which gives few ideas. Create base system with: * very basic graphic stack, to avoid desktop bugs interference. * communication applications configured for development channels, with CLI counter parts working, all "hidden" under help command or icon. * helper scripts to debug it and post results to paste site or bugzilla; half of debugging on IRC is pulling out needed info from users that have no idea what they should post. Wiki article doesn't count as help in case of network problems, and even in offline form it is introducing long delay between problem and its solution. * verbose bootup report, but not like now an illegible, intangible mess of messages, but sorted in groups, and if possible clickable. * easy fallback; something like part of Factory installation, add small stable system if there is no other installation. * Factory system update, should be possible from used or stable system; which will make broken boot not so serious problem. * Ability to check does Factory boot from VirtualBox. All above will make possible for inexperienced users to participate in Factory development. Factory system that will not boot will be scare of the past. It will help just about everyone; users without big skills and developers. Users will be able to discuss problems and file quality reports without knowing gdb and ton of other utilities. Developers will get quality bug reports after problems were discussed with experienced users avoiding data collection phase. I know that can be a lot of work, but it is time to sort things out, otherwise when old do-it-yourself users and openSUSE diehards retire, there will be no more user base. As usually lack of time doesn't give me chance to sort ideas and create at least some simple template for user directory that will at least make IRC, mail lists and Forums one click away. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 25 Sep 2012 12:48:46 +0200 Stephan Kulow <coolo@suse.de> wrote:
How much testing of factory (milestones) do you and Rajko do and how much do you expect to do if the next release is targetting end of next year?
I lost interest in testing. I sporadically load iso in the VirtualBox, but even when it works fine it is not installed. Development. It is going too fast, erratically changing quality independent of stage; alpha, beta, RC, or milestone number have no meaning. My knowledge. It is needed to recover from disaster, but it is obsoleted by new technologies faster then I can learn. I'm in position of a new user that should not touch Factory. I have no eight hours a day for learning. Bug reports. It takes a lot of effort and time to have it solved. For me it is faster to employ workaround and live happy, then to file bug report. Blame game. I recall time when I wanted to test Gnome3, and it did not load correctly. Blame was sent to the VirtualBox and their graphics driver, which was correct. Blame game doesn't help. If product doesn't pass preliminary testing in virtual machine, who is going to use it on real hardware. There will probably more if I would have time to look at, but vacation is over and day is shorter for 10 hours. openSUSE can't compete with daily trivial tasks like eating and buying a food. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Listen to what Rajko says, he's brilliant I would like to help test, but my time is very limited. With my commute I am working 10 hours per day. My education requires about an hour per day and my wife and son require attention per day as well as eating, sleeping and regular "life". I help what I can when I can. I am getting an education so I can help more in other areas as well. The "here and now" is I NEED a stable openSUSE that boots every day, doesn't "freak out" with an update and isn't "outdated" in just a couple of months. I can't risk being without a computer for 24 hours and this is why I use openSUSE and not MS like all the people around me who have nothing better to talk about except the last virus outbreak to which I smile and walk away. On Tue, Sep 25, 2012 at 9:37 PM, Rajko <rmatov101@charter.net> wrote:
On Tue, 25 Sep 2012 12:48:46 +0200 Stephan Kulow <coolo@suse.de> wrote:
How much testing of factory (milestones) do you and Rajko do and how much do you expect to do if the next release is targetting end of next year?
I lost interest in testing.
I sporadically load iso in the VirtualBox, but even when it works fine it is not installed.
Development. It is going too fast, erratically changing quality independent of stage; alpha, beta, RC, or milestone number have no meaning.
My knowledge. It is needed to recover from disaster, but it is obsoleted by new technologies faster then I can learn. I'm in position of a new user that should not touch Factory. I have no eight hours a day for learning.
Bug reports. It takes a lot of effort and time to have it solved. For me it is faster to employ workaround and live happy, then to file bug report.
Blame game. I recall time when I wanted to test Gnome3, and it did not load correctly. Blame was sent to the VirtualBox and their graphics driver, which was correct. Blame game doesn't help. If product doesn't pass preliminary testing in virtual machine, who is going to use it on real hardware.
There will probably more if I would have time to look at, but vacation is over and day is shorter for 10 hours. openSUSE can't compete with daily trivial tasks like eating and buying a food.
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2012-09-25 12:48 (GMT+0200) Stephan Kulow composed:
How much testing of factory (milestones) do you and Rajko do and how much do you expect to do if the next release is targetting end of next year?
Much of what Rajko wrote applies to me, though I expect my testing to remain quite a bit above zero. Though he did mention Bugzilla, he did not mention what constantly grates on me: repeatedly being logged out during the several hours it often takes per bug to do follow-ups, part of https://bugzilla.novell.com/show_bug.cgi?id=753203 while other bug trackers maintain login at least as long as the browser session is continued; compounded by every bug having two unique URLs polluting browser history, one with, and one without, the idiotic goaheadandlogin appendage; and https://bugzilla.novell.com/show_bug.cgi?id=776204 In particular, replacement of sysvinit with systemd has had a huge impact on how and what I test, including no less than a big enjoyment reduction of the whole testing process. In 12.1 cycle I got around it by installing sysvinit-init on most machines. In 12.2 cycle I did that on about half. I don't know if I'll ever get over my resentment of replacing memorable 6 to 15 character common command strings with immemorable strings of ~25 characters and up, usually ending with the exact same 8 characters, .service, to perform equivalent action. It doesn't help when I see again and again systemd proponents or devs blaming other things for systemd not doing or doing things that other things depend on happening during a normal sysvinit process. e.g. https://bugzilla.novell.com/show_bug.cgi?id=768788. My 60+ year old old brain does not learn like it used to, and has particular difficulty learning more complicated replacements for complicated things I had become comfortable with. I'm still using Quattro Pro for DOS constantly, using its optional 1-2-3 menuing system I learned in the early '80's learning the Lotus PC app that caused the explosion in PC sales and use. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Fri, 21 Sep 2012 10:10:46 +0200 Stephan Kulow <coolo@suse.de> wrote:
I was not talking about users per se, but about contributions.
I see. To get more people testing and solving bugs, or doing some packaging the basic idea would be to create jobs that can be done following written instructions (scripts). Instructions should not presume user skills and experience, just common sense and ability to communicate. Our current documentation about both OBS and Bugzilla is seldom of that kind. Jobs should not take more then a hour. Shorter is better. Everyone was following some script at some point in time and learned along the way. Writing scripts is time consuming, but without them entrance threshold for new contributors is high, so very few will have enough skills and motivation to pass it. For the beginning we should separate few tasks that require max an hour to accomplish for the first time contribution in a certain area. For instance, how to search and/or verify bug report for graphic cards [1]. Something, like this: AMD graphics bug confirmation: * We will search bugzilla using advanced screen [default screen with marked Search]. * This is how interface should be set up [setup screenshot]. * First we are looking for problems with graphics [search field screenshot] * This is what bugzilla will show if there is any [found bug screenshot], and this when it is missing [no bugs screenshot] * ... and so on. That "so on" should not spread over 10-20 screens because that will take an hour to read. Intention is to have reading and verifying within 1 hour. While I can take time and create couple of scripts for bugzilla, somebody else should do that for OBS. Who is that "somebody else"? Most likely the one that needs more testers and packagers. Jim, you opinion and support? -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
2012/9/22 Rajko <rmatov101@charter.net>:
On Fri, 21 Sep 2012 10:10:46 +0200 Stephan Kulow <coolo@suse.de> wrote:
I was not talking about users per se, but about contributions.
I see.
To get more people testing and solving bugs, or doing some packaging the basic idea would be to create jobs that can be done following written instructions (scripts). Instructions should not presume user skills and experience, just common sense and ability to communicate. Our current documentation about both OBS and Bugzilla is seldom of that kind.
Jobs should not take more then a hour. Shorter is better.
osc collab todo --project openSUSE:Factory yikes... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sat, 22 Sep 2012 23:48:39 +0100 Nelson Marques <nmo.marques@gmail.com> wrote:
osc collab todo --project openSUSE:Factory
osc: unknown command: 'collab' osc --version 0.135 I'm still wondering what's the message? -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/23/2012 09:34 AM, Rajko wrote:
On Sat, 22 Sep 2012 23:48:39 +0100 Nelson Marques <nmo.marques@gmail.com> wrote:
osc collab todo --project openSUSE:Factory
osc: unknown command: 'collab'
zypper in osc-plugin-collab Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
That's a list of tasks/jobs to do in openSUSE:Factory :) Isn't that what you want, a list of tasks/jobs to do ? :) 2012/9/23 Rajko <rmatov101@charter.net>:
On Sat, 22 Sep 2012 23:48:39 +0100 Nelson Marques <nmo.marques@gmail.com> wrote:
osc collab todo --project openSUSE:Factory
osc: unknown command: 'collab'
osc --version 0.135
I'm still wondering what's the message?
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sun, 23 Sep 2012 17:22:14 +0100 Nelson Marques <nmo.marques@gmail.com> wrote:
That's a list of tasks/jobs to do in openSUSE:Factory :)
Isn't that what you want, a list of tasks/jobs to do ?
Thanks for the idea :) Although it would help if you would be a bit more careful reading answers, like Togan was, and also not presume that everyone knows what you do. That presumption is probably the major reason for many of communication problems we have. From command line that you posted is not obvious that osc needs plugin to recognize command, and while I know a lot around openSUSE, including existence of Collab project, it did not came to me that functionality is separated from osc and the plugin is a problem. I though that something missing in command line that you posted, or that you have newer version then one in 12.2. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Although it would help if you would be a bit more careful reading answers, like Togan was, and also not presume that everyone knows what you do. That presumption is probably the major reason for many of communication problems we have.
My apologies; English isn't my native language, therefore this might be some sort of cultural issue, though I try my best (sometimes). -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sun, 23 Sep 2012 19:49:51 +0100 Nelson Marques <nmo.marques@gmail.com> wrote:
My apologies; English isn't my native language, therefore this might be some sort of cultural issue, though I try my best (sometimes).
No need for apology Nelson. I do understand multilingual and cultural issues, but in this case it wasn't lingual, nor cultural issue; you perfectly understood what I'm looking for and gave me a tool. The problem was that you, like we all sometimes do, presumed that the other know more then they do. When I posted all I got with your command line you missed to notice my lack of knowledge and was puzzled with answer: "osc: unknown command: 'collab'" . On the other hand, Togan had our recent conversation in mind, where bug reporting utility did not work because of lack of osc, and figured out that osc-plugin-collab is a problem. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Sorry for the delayed reply - I was taking the weekend mostly away from my PC. :) (I mention since you specifically were asking for my input/buy- in) On Sat, 22 Sep 2012 17:21:10 -0500, Rajko wrote:
To get more people testing and solving bugs, or doing some packaging the basic idea would be to create jobs that can be done following written instructions (scripts). Instructions should not presume user skills and experience, just common sense and ability to communicate. Our current documentation about both OBS and Bugzilla is seldom of that kind.
Jobs should not take more then a hour. Shorter is better.
Ideally, this is true - but defining the task as < 1 hour means defining the task clearly as well. Given the source of bugs (and the varying degrees of technical skills of those reporting them), it may not be feasible to guarantee (or try to) that this will always be the case - but it certainly is a worthy goal.
That "so on" should not spread over 10-20 screens because that will take an hour to read. Intention is to have reading and verifying within 1 hour.
Right - I think this addresses some of my above point. But it should be understood that especially when attempting to duplicate a bug that often times the setup is going to take some additional time, so it's not necessarily a hard limit, but it's something we strive to achieve.
Jim, you opinion and support?
Certainly I think that would help validate bugs that need to be addressed, and with the above caveats, I certainly support efforts that help clear out that backlog. 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 Mon, 24 Sep 2012 17:59:36 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote:
Ideally, this is true - but defining the task as < 1 hour means defining the task clearly as well. Given the source of bugs (and the varying degrees of technical skills of those reporting them), it may not be feasible to guarantee (or try to) that this will always be the case - but it certainly is a worthy goal.
One hour is probably the longest time we can count on with motivated users. (School hour is 45 minutes for a reason.) In other words taking few bugs as sample and see how to make reports easy within as small amount of time as possible, taking out of equation users skills and need to read lengthy "How to report a bug?" users skills can be taken out only with helper script that will offer interface with plain language and as output give file that is ready to upload, or even upload it, as smolt client does with hardware information. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 26 Sep 2012 23:47:01 -0500, Rajko wrote:
On Mon, 24 Sep 2012 17:59:36 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote:
Ideally, this is true - but defining the task as < 1 hour means defining the task clearly as well. Given the source of bugs (and the varying degrees of technical skills of those reporting them), it may not be feasible to guarantee (or try to) that this will always be the case - but it certainly is a worthy goal.
One hour is probably the longest time we can count on with motivated users. (School hour is 45 minutes for a reason.)
I don't disagree, but what I'm saying is that there will undoubtably be some tasks that require more time, so rather than guarantee that the task will take < 60 minutes regardless of skill level or knowledge, we need to be realistic about what can be achieved in that time. If we try to make some sort of guarantee and it turns out that most people take more than an hour, then nobody's going to trust the estimates. Thus, it's not a matter of simply guessing, but rather doing an actual estimate, using best case/worst case/likely case weighted averages - and that could end up taking more time to come up with for some tasks than the actual task itself would take.
In other words taking few bugs as sample and see how to make reports easy within as small amount of time as possible, taking out of equation users skills and need to read lengthy "How to report a bug?"
users skills can be taken out only with helper script that will offer interface with plain language and as output give file that is ready to upload, or even upload it, as smolt client does with hardware information.
There again, though, the time to create/debug the helper scripts (which I don't know how generic they can be) might take longer than having someone knowledgeable actually doing the task. That said - scripting tests to get more data points would be useful. For example, if there was a video driver bug that could be reproduced using a script, getting people with a variety of hardware supported by the driver in question would definitely be useful. 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 Thu, 27 Sep 2012 15:46:54 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote:
One hour is probably the longest time we can count on with motivated users. (School hour is 45 minutes for a reason.)
I don't disagree, but what I'm saying is that there will undoubtably be some tasks that require more time, so rather than guarantee that the task will take < 60 minutes regardless of skill level or knowledge, we need to be realistic about what can be achieved in that time.
Jim, this is not about task, it is about user, reporter. We will not look task and estimate how many hours user has to spend on it, but the other way around. Take one hour limit and find tasks that fit in that time frame. In professional world you have task and look how many man hours you need for it. As you know, working with people that donate their free time is different. They will give just as much as they want, or have. Any demand above that individual limit is pointless. What is goal of small tasks limited to 1 hour or lesser? It is the same goal that makes Wikipedia successful. Give a chance people with little time for openSUSE to contribute. That is majority of our users.
If we try to make some sort of guarantee and it turns out that most people take more than an hour, then nobody's going to trust the estimates.
Thus, it's not a matter of simply guessing, but rather doing an actual estimate, using best case/worst case/likely case weighted averages - and that could end up taking more time to come up with for some tasks than the actual task itself would take.
Estimate is just that. We can tell that user that knows this and that will spend 1 hour or lesser. To learn "this and that" user will need additional hours, and to be honest we can estimate that too trough average reading speed vs. size of text, available help, etc.
... users skills can be taken out only with helper script that will offer interface with plain language and as output give file that is ready to upload, or even upload it, as smolt client does with hardware information.
There again, though, the time to create/debug the helper scripts (which I don't know how generic they can be) might take longer than having someone knowledgeable actually doing the task.
We are talking about scripts that will collect info. I mentioned somewhere that we on IRC spend more time explaining how to get information needed to solve a problem, then solving the problem. Any script that will cut down on that is not wasted time. Also, knowledgeable people are busy :)
That said - scripting tests to get more data points would be useful. For example, if there was a video driver bug that could be reproduced using a script, getting people with a variety of hardware supported by the driver in question would definitely be useful.
That too.
Jim
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 27 Sep 2012 19:18:04 -0500, Rajko wrote:
We will not look task and estimate how many hours user has to spend on it, but the other way around. Take one hour limit and find tasks that fit in that time frame.
An hour by whose measure, though? In project management time estimation, the /best/ judge of how long it takes to do something is the person who is going to do the task. That's not to say you can't estimate it (weighted averages as I mentioned before are often used - but even then, the best data comes from the person doing the task).
In professional world you have task and look how many man hours you need for it.
Right, and you ask the person doing the task - usually someone experienced or who has at least done the task before at the skill level of the person doing the task - makes the estimate.
As you know, working with people that donate their free time is different.
Exactly my point. I know what I can do in an hour. I don't know what you can do in an hour. I don't know what my older brother (who has experience as an end-user of Macs mostly) could accomplish on a Linux box in an hour. We have a very wide userbase with a very large variety of experience levels who get involved in testing. So whose measure of "what can be done in an hour" is the benchmark?
What is goal of small tasks limited to 1 hour or lesser? It is the same goal that makes Wikipedia successful. Give a chance people with little time for openSUSE to contribute. That is majority of our users.
Yes and no - Wikipedia's entries grow somewhat organically. Work units on bug analysis are more discrete components. On Wikipedia, writing an article about elephants (for example), you have people contributing and building on the same base of information. There's a sequence of tasks that need to be completed - so when breaking work units out, when you end up with a work breakdown structure that is sequential, you can't use the time to complete a discrete work unit as the estimate for the total time involved to complete that work unit. If it takes me an hour to set up to get to where I can do the hour of testing for the task at hand, that has to be taken into consideration as part of the task.
If we try to make some sort of guarantee and it turns out that most people take more than an hour, then nobody's going to trust the estimates.
Thus, it's not a matter of simply guessing, but rather doing an actual estimate, using best case/worst case/likely case weighted averages - and that could end up taking more time to come up with for some tasks than the actual task itself would take.
Estimate is just that. We can tell that user that knows this and that will spend 1 hour or lesser. To learn "this and that" user will need additional hours, and to be honest we can estimate that too trough average reading speed vs. size of text, available help, etc.
Sure, but again that comes back to the question of what the expected level of experience is for those doing the tasks. The solution is that when a task is being defined, ideally you should have the actual tester involved to try to provide a baseline for how long they think it'll take - best case, worst case, and likely case, and then use a weighted average to determine if the task is reasonable. If it isn't, and it can't be further divided, then either more time is needed or a more experienced tester is needed.
... users skills can be taken out only with helper script that will offer interface with plain language and as output give file that is ready to upload, or even upload it, as smolt client does with hardware information.
There again, though, the time to create/debug the helper scripts (which I don't know how generic they can be) might take longer than having someone knowledgeable actually doing the task.
We are talking about scripts that will collect info.
Sure, and that is something that can help with predictability. If it's known that a script that does x, y, and z will gather the necessary information and it takes 10 minutes to understand how to run it, 5 minutes to run it and verify the collected data is valid enough, and 10 minutes to update the bug, then that's a reasonable approach.
I mentioned somewhere that we on IRC spend more time explaining how to get information needed to solve a problem, then solving the problem. Any script that will cut down on that is not wasted time.
Also, knowledgeable people are busy :)
Yes, which is why it's important to determine if it's a better use of their time to create a script or to just test the thing that needs to be tested. It's also important that the tasks defined not be so scripted as to produce a result that's not valid for fixing the bug. If I write a procedure that ultimately misses the point of the bug, then we could end up with a lot of NABWAD resolutions (ie, "Not a Bug, Working as Designed") as a result of poorly written instructions - or poorly understood bugs. 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 Thu, Sep 27, 2012 at 8:32 PM, Jim Henderson <hendersj@gmail.com> wrote:
Exactly my point. I know what I can do in an hour. I don't know what you can do in an hour. I don't know what my older brother (who has experience as an end-user of Macs mostly) could accomplish on a Linux box in an hour.
Perhaps your older brother would be willing to be a test subject for quantitative data on how much results can be expected from a "noob" user in a 1 hour period of time? If it takes him 4 hours to accomplish what you can in 1 hour then perhaps we could re-think the process in which the task to be executed to take 1 hour for a user at your brothers level? It sounds like an opportunity to do some very progressive and beneficial R&D work. On Thu, Sep 27, 2012 at 8:32 PM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 27 Sep 2012 19:18:04 -0500, Rajko wrote:
We will not look task and estimate how many hours user has to spend on it, but the other way around. Take one hour limit and find tasks that fit in that time frame.
An hour by whose measure, though? In project management time estimation, the /best/ judge of how long it takes to do something is the person who is going to do the task.
That's not to say you can't estimate it (weighted averages as I mentioned before are often used - but even then, the best data comes from the person doing the task).
In professional world you have task and look how many man hours you need for it.
Right, and you ask the person doing the task - usually someone experienced or who has at least done the task before at the skill level of the person doing the task - makes the estimate.
As you know, working with people that donate their free time is different.
Exactly my point. I know what I can do in an hour. I don't know what you can do in an hour. I don't know what my older brother (who has experience as an end-user of Macs mostly) could accomplish on a Linux box in an hour.
We have a very wide userbase with a very large variety of experience levels who get involved in testing. So whose measure of "what can be done in an hour" is the benchmark?
What is goal of small tasks limited to 1 hour or lesser? It is the same goal that makes Wikipedia successful. Give a chance people with little time for openSUSE to contribute. That is majority of our users.
Yes and no - Wikipedia's entries grow somewhat organically. Work units on bug analysis are more discrete components. On Wikipedia, writing an article about elephants (for example), you have people contributing and building on the same base of information.
There's a sequence of tasks that need to be completed - so when breaking work units out, when you end up with a work breakdown structure that is sequential, you can't use the time to complete a discrete work unit as the estimate for the total time involved to complete that work unit.
If it takes me an hour to set up to get to where I can do the hour of testing for the task at hand, that has to be taken into consideration as part of the task.
If we try to make some sort of guarantee and it turns out that most people take more than an hour, then nobody's going to trust the estimates.
Thus, it's not a matter of simply guessing, but rather doing an actual estimate, using best case/worst case/likely case weighted averages - and that could end up taking more time to come up with for some tasks than the actual task itself would take.
Estimate is just that. We can tell that user that knows this and that will spend 1 hour or lesser. To learn "this and that" user will need additional hours, and to be honest we can estimate that too trough average reading speed vs. size of text, available help, etc.
Sure, but again that comes back to the question of what the expected level of experience is for those doing the tasks.
The solution is that when a task is being defined, ideally you should have the actual tester involved to try to provide a baseline for how long they think it'll take - best case, worst case, and likely case, and then use a weighted average to determine if the task is reasonable.
If it isn't, and it can't be further divided, then either more time is needed or a more experienced tester is needed.
... users skills can be taken out only with helper script that will offer interface with plain language and as output give file that is ready to upload, or even upload it, as smolt client does with hardware information.
There again, though, the time to create/debug the helper scripts (which I don't know how generic they can be) might take longer than having someone knowledgeable actually doing the task.
We are talking about scripts that will collect info.
Sure, and that is something that can help with predictability. If it's known that a script that does x, y, and z will gather the necessary information and it takes 10 minutes to understand how to run it, 5 minutes to run it and verify the collected data is valid enough, and 10 minutes to update the bug, then that's a reasonable approach.
I mentioned somewhere that we on IRC spend more time explaining how to get information needed to solve a problem, then solving the problem. Any script that will cut down on that is not wasted time.
Also, knowledgeable people are busy :)
Yes, which is why it's important to determine if it's a better use of their time to create a script or to just test the thing that needs to be tested.
It's also important that the tasks defined not be so scripted as to produce a result that's not valid for fixing the bug. If I write a procedure that ultimately misses the point of the bug, then we could end up with a lot of NABWAD resolutions (ie, "Not a Bug, Working as Designed") as a result of poorly written instructions - or poorly understood bugs.
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
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 27 Sep 2012 21:06:16 -0700, DuBois, Scott L. wrote:
Exactly my point. I know what I can do in an hour. I don't know what you can do in an hour. I don't know what my older brother (who has experience as an end-user of Macs mostly) could accomplish on a Linux box in an hour.
Perhaps your older brother would be willing to be a test subject for quantitative data on how much results can be expected from a "noob" user in a 1 hour period of time? If it takes him 4 hours to accomplish what you can in 1 hour then perhaps we could re-think the process in which the task to be executed to take 1 hour for a user at your brothers level? It sounds like an opportunity to do some very progressive and beneficial R&D work.
That was more or less a hypothetical in selecting someone who I know has no Linux experience whatsoever. My point is that in order to determine if a task can be done in an hour, we have to have a reasonable guess as to the level of user who is going to be performing the task - a good average, at least - or the estimate is meaningless. 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
I knew using your brother as an example was hypothetical, however people like your brother may be the target audience. Consider Johnny in the 8th grade who has ambitions of being a video game developer. He doesn't know how to code or script but he's pretty good with a computer and changes out his own hardware, managers drivers and the average stuff kids do. He thinks getting involved with openSUSE would be cool because they are really hi-tech people who can provide him with little tasks he can learn that his school doesn't provide so he seeks to further his education towards his goal on his own. He has homework and chores and all the other responsibilities kids have so he gets little time to goof off and instead of just playing video games he helps openSUSE by doing bug reporting or even try to help fix. The idea is to create a process that is so simple Johnny gets enthusiastic and involved because he is being helpful and learning as well. He tells some of his friends about what he is doing and they in turn start doing the same things. Johnny's parents don't mind since he is learning to work as a team with other people who give him small tasks that he can accomplish and by accomplishing them it boosts his self esteem and keeps him focused on his goal of being a game developer. As his self esteem increases with the tasks he completes he will naturally help to market our brand through social media as well as other portals. We benefit because we are getting more people involved with openSUSE that are being productive and helping. By making the process as easy as possible, we motivate more people willing to take the time to help because the work can be accomplished in a small amount of time. Instead of focusing on how to determine user level/hr focus on what you can accomplish in an hour then have it tested by a group of individuals with different skill levels then tweak the process from there. It may have to be modified a number of times until a happy medium is found where the average "non-technical" user can on average perform the task in about an hour. None of this timing can be carved in stone since each person has a different skill level as you say, but we can approximate through enough trial and error until it is safe to say that "the following tasks can each be accomplished in about an hour by persons with little technical skill". On Fri, Sep 28, 2012 at 7:52 AM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 27 Sep 2012 21:06:16 -0700, DuBois, Scott L. wrote:
Exactly my point. I know what I can do in an hour. I don't know what you can do in an hour. I don't know what my older brother (who has experience as an end-user of Macs mostly) could accomplish on a Linux box in an hour.
Perhaps your older brother would be willing to be a test subject for quantitative data on how much results can be expected from a "noob" user in a 1 hour period of time? If it takes him 4 hours to accomplish what you can in 1 hour then perhaps we could re-think the process in which the task to be executed to take 1 hour for a user at your brothers level? It sounds like an opportunity to do some very progressive and beneficial R&D work.
That was more or less a hypothetical in selecting someone who I know has no Linux experience whatsoever.
My point is that in order to determine if a task can be done in an hour, we have to have a reasonable guess as to the level of user who is going to be performing the task - a good average, at least - or the estimate is meaningless.
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
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Fri, 28 Sep 2012 22:44:30 -0700, DuBois, Scott L. wrote:
None of this timing can be carved in stone since each person has a different skill level as you say, but we can approximate through enough trial and error until it is safe to say that "the following tasks can each be accomplished in about an hour by persons with little technical skill".
This makes sense. :) 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 Mon, 1 Oct 2012 15:45:28 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote:
This makes sense. :)
It is funny that it takes Scot's explanation to bring message to your side, but I'm happy that finally we agree, and it is 3 of us that can start looking for bugs that can profit from unskilled user activity and shape general approach to that. Next post should be to find few bugs that need help :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I'm always happy to help whenever I can to the best of my ability : ) On Mon, Oct 1, 2012 at 6:34 PM, Rajko <rmatov101@charter.net> wrote:
On Mon, 1 Oct 2012 15:45:28 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote:
This makes sense. :)
It is funny that it takes Scot's explanation to bring message to your side, but I'm happy that finally we agree, and it is 3 of us that can start looking for bugs that can profit from unskilled user activity and shape general approach to that.
Next post should be to find few bugs that need help :)
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 01 Oct 2012 20:34:37 -0500, Rajko wrote:
On Mon, 1 Oct 2012 15:45:28 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote:
This makes sense. :)
It is funny that it takes Scot's explanation to bring message to your side, but I'm happy that finally we agree,
I just wanted to be sure that we understood each other, and I wasn't getting that you understood what I was saying about how we needed to approach estimation. It sounds like you do, and we're all on the same page. :)
and it is 3 of us that can start looking for bugs that can profit from unskilled user activity and shape general approach to that.
Next post should be to find few bugs that need help :)
That's a good approach. How shall we divide up the task of reviewing the existing outstanding bugs? 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 Tue, 2 Oct 2012 23:33:40 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote: ...
That's a good approach. How shall we divide up the task of reviewing the existing outstanding bugs?
Jim
We can start by improving this report. https://bugzilla.novell.com/report.cgi?x_axis_field=product&y_axis_field=component&z_axis_field=bug_status&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&longdesc_type=fulltext&longdesc=&classification=openSUSE&product=openSUSE+12.1&product=openSUSE+12.2&product=openSUSE+12.3&component=Kernel&component=LibreOffice&component=Network&component=Printing&component=Samba&component=Sound&component=Usability&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=anywords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&resolution=---&resolution=DUPLICATE&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= It has few groups that I consider potential source of interesting bugs, but it may need few more, or less, components. After that we go to opensuse@opensuse.org and Forums (you are the expert for that part), present a plan and ask for help to review and list bugs. Target group are new users with wish to learn and help, common sense, consider Google as a friend, but have not much knowledge. In both cases ask those that want to help to post what part they look at, so that load is split. If someone has affinity to certain problems allow "me too". Of course listing bug report links is possible in a wiki, but there must be volunteers to keep en eye on both, wiki and bugzilla. This can be done by those that are target class of users. And, not to forget the same mail (forum post) can be used to recruit those from target group that can look at selected bugs and explain what they see as a problem. Plan should be win for everyone, new users, old users, bug squashing teams, and at the end openSUSE distro. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 10/03/2012 04:23 AM, Rajko wrote:
We can start by improving this report.
It has few groups that I consider potential source of interesting bugs, but it may need few more, or less, components.
Why not include 11.4 as well to your bug rally. As the days are limited for 11.4 it would be nice to have the bugs either closed or cloned to other released if the problem still exists. Probably just add NEEDINFO for all existing 11.4 bugs with a note if no response in say 2 weeks bugs will be closed. Announce that in the forums or whatever channel you are using so hopefully people get their act together. Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hello, Am Dienstag, 2. Oktober 2012 schrieb Rajko:
We can start by improving this report. REOPENED&resolution=---&resolution=DUPLICATE&emailassigned_to1=1&email ^^^^^^^^^^^^^^^^^^^^ Including DUPLICATE doesn't make sense ;-)
It has few groups that I consider potential source of interesting bugs, but it may need few more, or less, components.
I'm not sure if we should restrict it to some components - as long as interested people can get a list of their favorite component ;-) (which is easy in bugzilla)
Of course listing bug report links is possible in a wiki, but there must be volunteers to keep en eye on both, wiki and bugzilla.
Managing a list of bugreports in the wiki is a bad idea - managing (especially updating!) it will take lots of time you could spend otherwise. Please use a solution that works inside bugzilla, for example add a keyword to the bugreport or add something to the bug summary. In the wiki, just create links like "easy to fix bugs in LibreOffice in openSUSE 12.2" that link to buglist.cgi with the correct parameters. Regards, Christian Boltz -- Ich koche lieber selber, als bei MC Donalds zu essen, aber wem das Kaffeewasser anbrennt, der geht doch lieber zu diese große amerikanische Kette. Selberkochen ist nur dann zu empfehlen, wenn es Spaß macht. Mit Linux ist es genauso. [Bernd Brodesser in suse-linux] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/17/2012 06:07 AM, Bryen M Yunashko wrote:
On Sun, 2012-09-16 at 00:25 -0500, Rajko wrote:
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle. The reason why we re-defined our versioning was precisely because of what you said. From a marketing standpoint, we noticed a decrease in media coverage of our releases after .0's were released. People (particularly journalists) tended to perceive .1, .2, and .3 as updates to the "major release." They saw .0 as major revision and thus didn't bother to cover as much.
But in fact, .0, .1, .2, and .3 were meaningless in that concept. They were just simply releases. Just as you point out. .1, .2, .3 has meaning now, but as recently proven, that meaning became broken quite easily.
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
The more I have been thinking about the benefits of an annual release (even before the .x issue came into discussion) the more I find I *like* the idea of a once-a year release. It makes a lot of sense, at least in my corner.
And literally, if things go haywire like it did with 12.2 release, you actually have a 12-month window within your release date. You could delay and still be "on-time." :-)
So, I join the bandwagon to support an annual release plus a 2-year support lifecycle for each release.
Bryen
I agree with Bryen here. IF we move to a 1-year release plan, point releases have to go. Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I have a few concerns: 1) What is the contingency plan in case something fails; 2) In the future, when should we evaluate the outcome of this and how; We need to know if this was indeed benefic for the project; People are changing things way too much in the last releases; there are negative effects regarding users trust, potential impacts on developers workflow, customer loyalty... not to mention that it's really legit that users believe we don't know what the hell we are doing or why we need to change too much. Please consider that the last releases introduced a lot of non-technical changes and in the case of 12.2 it was delayed for two months... This isn't just about introducing changes; changes bring impacts, and so far everyone seems thrilled, but I don't see any concern in potential nefast impacts. NM PS: Not that I care, my opinions aren't worth #$% for the project. 2012/9/17 Bryen M Yunashko <suserocks@bryen.com>:
On Sun, 2012-09-16 at 00:25 -0500, Rajko wrote:
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle.
The reason why we re-defined our versioning was precisely because of what you said. From a marketing standpoint, we noticed a decrease in media coverage of our releases after .0's were released. People (particularly journalists) tended to perceive .1, .2, and .3 as updates to the "major release." They saw .0 as major revision and thus didn't bother to cover as much.
But in fact, .0, .1, .2, and .3 were meaningless in that concept. They were just simply releases. Just as you point out. .1, .2, .3 has meaning now, but as recently proven, that meaning became broken quite easily.
This is yet another reason why I think the once-a-year release of openSUSE could be appealing. Not only would it be appealing from a technical and support perspective, but even in amrketing we'd finally do away with .x's altogether. Just have openSUSE released once a year to reflect the year. openSUSE-12 or openSUSE 2012, and 2013, and 2014, and so on. Or, if we want to get really weird, o2p0enS1U2E. (Just to freak people out, LOL)
The more I have been thinking about the benefits of an annual release (even before the .x issue came into discussion) the more I find I *like* the idea of a once-a year release. It makes a lot of sense, at least in my corner.
And literally, if things go haywire like it did with 12.2 release, you actually have a 12-month window within your release date. You could delay and still be "on-time." :-)
So, I join the bandwagon to support an annual release plus a 2-year support lifecycle for each release.
Bryen
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sunday 16 September 2012 22:07:56 Bryen M Yunashko wrote:
On Sun, 2012-09-16 at 00:25 -0500, Rajko wrote:
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle.
The reason why we re-defined our versioning was precisely because of what you said. From a marketing standpoint, we noticed a decrease in media coverage of our releases after .0's were released. People (particularly journalists) tended to perceive .1, .2, and .3 as updates to the "major release." They saw .0 as major revision and thus didn't bother to cover as much.
<snip> Yup. IF we go to a 1-year release cycle, I'm all for doing the 1 number per year thing and dump the .xyz stuff. If we keep the current schedule, we should keep the numbering - we discussed it extensively and made a vote, let's not change it every 2-3 releases.
So, I join the bandwagon to support an annual release plus a 2-year support lifecycle for each release.
Note that the 2 year support livecycle is something we'd have to put effort in: SUSE is currently paying for 18 months, the remaining 6 months would have to come from community efforts. Either in lowering the support load during the 18 months to make it reasonable for SUSE to spread out their efforts more or doing those 6 months separate. And, as Dominique notes, we do have to offer something for our users in between the releases. Respins, tumbleweed, OBS, all of those - whatever it is, we need to think about it and build it so that it's easy to use (easier than the current solutions - as in, adding the GNOME 3.6 or KDE 4.9 repo's right now is NOT easy enough). Hugs, Jos
Bryen
* Jos Poortvliet <jos@opensuse.org> [2012-09-17 12:12]:
On Sunday 16 September 2012 22:07:56 Bryen M Yunashko wrote:
On Sun, 2012-09-16 at 00:25 -0500, Rajko wrote:
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle.
The reason why we re-defined our versioning was precisely because of what you said. From a marketing standpoint, we noticed a decrease in media coverage of our releases after .0's were released. People (particularly journalists) tended to perceive .1, .2, and .3 as updates to the "major release." They saw .0 as major revision and thus didn't bother to cover as much.
<snip> Yup. IF we go to a 1-year release cycle, I'm all for doing the 1 number per year thing and dump the .xyz stuff. If we keep the current schedule, we should keep the numbering - we discussed it extensively and made a vote, let's not change it every 2-3 releases.
So, I join the bandwagon to support an annual release plus a 2-year support lifecycle for each release.
Note that the 2 year support livecycle is something we'd have to put effort in: SUSE is currently paying for 18 months, the remaining 6 months would have to come from community efforts. Either in lowering the support load during the 18 months to make it reasonable for SUSE to spread out their efforts more or doing those 6 months separate.
AFAICS right now SUSE only promises security updates for the lifecycle of a release while all other updates are more or less at the discretion of the maintainers already (that is as they see fit and are willing/able to invest time) and those are not necessarily paid by SUSE. That said, I'd favor a longer lifecycle and would be willing to do my part. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Guido Berhoerster wrote:
* Jos Poortvliet <jos@opensuse.org> [2012-09-17 12:12]:
On Sunday 16 September 2012 22:07:56 Bryen M Yunashko wrote:
On Sun, 2012-09-16 at 00:25 -0500, Rajko wrote:
We should quit with minor version nonsense: "Minor number means nothing", when in the rest of the software world it means patch level. Our approach is counter intuitive, requires additional processing and it should be treated as yet another obstacle.
The reason why we re-defined our versioning was precisely because of what you said. From a marketing standpoint, we noticed a decrease in media coverage of our releases after .0's were released. People (particularly journalists) tended to perceive .1, .2, and .3 as updates to the "major release." They saw .0 as major revision and thus didn't bother to cover as much.
<snip> Yup. IF we go to a 1-year release cycle, I'm all for doing the 1 number per year thing and dump the .xyz stuff. If we keep the current schedule, we should keep the numbering - we discussed it extensively and made a vote, let's not change it every 2-3 releases.
So, I join the bandwagon to support an annual release plus a 2-year support lifecycle for each release.
Note that the 2 year support livecycle is something we'd have to put effort in: SUSE is currently paying for 18 months, the remaining 6 months would have to come from community efforts. Either in lowering the support load during the 18 months to make it reasonable for SUSE to spread out their efforts more or doing those 6 months separate.
AFAICS right now SUSE only promises security updates for the lifecycle of a release while all other updates are more or less at the discretion of the maintainers already (that is as they see fit and are willing/able to invest time) and those are not necessarily paid by SUSE.
That is my understanding too.
That said, I'd favor a longer lifecycle and would be willing to do my part.
Ditto. -- Per Jessen, Zürich (22.3°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 2012-09-17 at 12:12 +0200, Jos Poortvliet wrote:
Note that the 2 year support livecycle is something we'd have to put effort in: SUSE is currently paying for 18 months, the remaining 6 months would have to come from community efforts. Either in lowering the support load during the 18 months to make it reasonable for SUSE to spread out their efforts more or doing those 6 months separate.
Mathematically speaking, I don't see a real difference in daily manpower allocation if we were on 18-month or 2 year support lifecycle. The daily resources would remain the same. But you do bring up the other more important question, which really isn't just about support but broader overall community relationship to openSUSE. We need to find ways to attract and maintain community support. This is, in my opinion, a separate but important issue that should be discussed. So far, we've been discussing a lot about "what we should have for release cycle" but we have yet to have a discussion about the strategy for enhanced community contributions. And we should have a very broad discussion on this that includes important questions such as: what are the barriers that would-be contributors experience, how do we recruit contributions/new contributors, how do we maintain a positive environment for contributions, what are the reasons some have left, etc. Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
2012/9/17 Bryen M Yunashko <suserocks@bryen.com>:
On Mon, 2012-09-17 at 12:12 +0200, Jos Poortvliet wrote:
Note that the 2 year support livecycle is something we'd have to put effort in: SUSE is currently paying for 18 months, the remaining 6 months would have to come from community efforts. Either in lowering the support load during the 18 months to make it reasonable for SUSE to spread out their efforts more or doing those 6 months separate.
Mathematically speaking, I don't see a real difference in daily manpower allocation if we were on 18-month or 2 year support lifecycle. The daily resources would remain the same.
But you do bring up the other more important question, which really isn't just about support but broader overall community relationship to openSUSE. We need to find ways to attract and maintain community support. This is, in my opinion, a separate but important issue that should be discussed.
So far, we've been discussing a lot about "what we should have for release cycle" but we have yet to have a discussion about the strategy for enhanced community contributions. And we should have a very broad discussion on this that includes important questions such as: what are the barriers that would-be contributors experience, how do we recruit contributions/new contributors, how do we maintain a positive environment for contributions, what are the reasons some have left, etc.
Bryen
I vote to continue what we already discussed a lot and as a community decided, the current version scheme. Or every x months/years anyone will start a thread with a magic solution to the versioning. Maybe 1 year will not be fun enough, so someone will suggest a 8months or 6 months concept to be sincronized with major DE's release. Regards Luiz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 2012-09-17 at 11:02 -0300, Luiz Fernando Ranghetti wrote:
Or every x months/years anyone will start a thread with a magic solution to the versioning. Maybe 1 year will not be fun enough, so someone will suggest a 8months or 6 months concept to be sincronized with major DE's release.
Why do we need to synchronize our releases with those of major DE's? We provide (in most cases) a way to update to the latest DE with current releases, respins, etc. I am not in favor of a release schedule that is beholden to external parties' release schedules. Granted, maybe a more intuitive method of updating DE's for users would be useful, but that doesn't really make much sense for the definition of a release cycle because not all DE's release in the exact same month. Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
2012/9/17 Bryen M Yunashko <suserocks@bryen.com>:
On Mon, 2012-09-17 at 11:02 -0300, Luiz Fernando Ranghetti wrote:
Or every x months/years anyone will start a thread with a magic solution to the versioning. Maybe 1 year will not be fun enough, so someone will suggest a 8months or 6 months concept to be sincronized with major DE's release.
Why do we need to synchronize our releases with those of major DE's? We provide (in most cases) a way to update to the latest DE with current releases, respins, etc. I am not in favor of a release schedule that is beholden to external parties' release schedules.
You also know thats dangerous; you as a part of the community often look for help in GNOME IRC channel; if you can't handle it without help, then our users won't either... This to say, if all users require the same ammount of help, we wont be able to provide such large scale help and we are doomed. So we have a potential solution, but it's not rock solid and demands more knowledge than the average of users have. right ? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 2012-09-17 at 15:20 +0100, Nelson Marques wrote:
2012/9/17 Bryen M Yunashko <suserocks@bryen.com>:
On Mon, 2012-09-17 at 11:02 -0300, Luiz Fernando Ranghetti wrote:
Or every x months/years anyone will start a thread with a magic solution to the versioning. Maybe 1 year will not be fun enough, so someone will suggest a 8months or 6 months concept to be sincronized with major DE's release.
Why do we need to synchronize our releases with those of major DE's? We provide (in most cases) a way to update to the latest DE with current releases, respins, etc. I am not in favor of a release schedule that is beholden to external parties' release schedules.
You also know thats dangerous; you as a part of the community often look for help in GNOME IRC channel; if you can't handle it without help, then our users won't either... This to say, if all users require the same ammount of help, we wont be able to provide such large scale help and we are doomed.
So we have a potential solution, but it's not rock solid and demands more knowledge than the average of users have.
right ?
You must have intentionally ommitted the part in this copy-reply where I said it needs to be more intuitive and could use more work and such which actually supports what you are saying here. :-) Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
2012/9/17 Bryen M Yunashko <suserocks@bryen.com>:
On Mon, 2012-09-17 at 15:20 +0100, Nelson Marques wrote:
2012/9/17 Bryen M Yunashko <suserocks@bryen.com>:
On Mon, 2012-09-17 at 11:02 -0300, Luiz Fernando Ranghetti wrote:
Or every x months/years anyone will start a thread with a magic solution to the versioning. Maybe 1 year will not be fun enough, so someone will suggest a 8months or 6 months concept to be sincronized with major DE's release.
Why do we need to synchronize our releases with those of major DE's? We provide (in most cases) a way to update to the latest DE with current releases, respins, etc. I am not in favor of a release schedule that is beholden to external parties' release schedules.
You also know thats dangerous; you as a part of the community often look for help in GNOME IRC channel; if you can't handle it without help, then our users won't either... This to say, if all users require the same ammount of help, we wont be able to provide such large scale help and we are doomed.
So we have a potential solution, but it's not rock solid and demands more knowledge than the average of users have.
right ?
You must have intentionally ommitted the part in this copy-reply where I said it needs to be more intuitive and could use more work and su which actually supports what you are saying here. :-)
Bryen
Well, if I don't remove stuff from previous emails I get slammed in my face that I must snip emails... when I snip stuff out (which proves I actually listen to people), then I'm ommitting stuff intentionally; honestly... where do we stand ? Should we snip or not snip? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 17 Sep 2012 09:14:10 -0500 Bryen M Yunashko <suserocks@bryen.com> wrote:
Granted, maybe a more intuitive method of updating DE's for users would be useful,
Desktop environment (DE) is just a software distribution. It has dependencies, it can be updated, update rolled back, upgraded and downgraded. Our focus on up-part brought us not once problems when new version doesn't work as expected. DEs with their dependencies make that up and down path (yo-yo) more complicated, even when older version of application exists. Ditto, for 12.3 and later versions we should focus to make this yo-yo ride as smooth and simple as possible. Example of software that makes this goal easy is kernel, although actually finding how to go up and down is a bit different story. Another example is Firefox that makes updates very easy, but it needs improvement in rollback part. Thinking of patch that will not only disable updates, but, instead, open package management with list of available Firefox versions. Of course instead of package management one can open support wizard that will ask user why to downgrade, offer help to fix a problem, ask forums, mail lists, assist with a bug reporting, and finally help to install last working version. What we will get with this? * More happy users. * Better bug reports. * More users aware of our "app store" that is way older then some commercial variants. * And, after some time, lesser load on support channels.
but that doesn't really make much sense for the definition of a release cycle because not all DE's release in the exact same month.
This is yo-yo: http://en.wikipedia.org/wiki/Yo-yo and this yo-yo ride: http://en.wikipedia.org/wiki/Yo-Yo_%28ride%29 When word spreads that we have yo-yo ride, openSUSE will become the most desirable Linux in the world :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/18/2012 06:40 AM, Rajko wrote:
On Mon, 17 Sep 2012 09:14:10 -0500 ions.
Of course instead of package management one can open support wizard that will ask user why to downgrade, offer help to fix a problem, ask forums, mail lists, assist with a bug reporting, and finally help to install last working version.
I do not think that would change anything as we do have, susepaste package so people can use to paste things, bugreporter to report bugs to assist. The question is do people use them heavily, or not
What we will get with this?
* More happy users. * Better bug reports.
use bugreporter Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 18 Sep 2012 09:04:52 +0200 Togan Muftuoglu <toganm@opensuse.org> wrote:
On 09/18/2012 06:40 AM, Rajko wrote:
On Mon, 17 Sep 2012 09:14:10 -0500 ions.
Of course instead of package management one can open support wizard ... I do not think that would change anything as we do have,
It is changing few important things: * accessibility of tools User has to remember one location to look for help and that is Help menu in any application, plus in case that application is crashing Help Assistant should be located in the Main Menu too. Like: Main Menu > Computer > Help Assistant (persistent) Main Menu > Favorites > Help Assitant It is located where user is looking for help, so it doesn't change user habits with a new congenial, never thought of location, or naming. and it is very easy to point out on a mediums like IRC, email, forums, phone, SMS. * it will lower pressure on support channels taking out preparation phase, * software developers and supporters don't have to guess what is needed to help users, just fill the blanks. We don't want to keep this for ourselves, but to work with upstream projects to include help in their offer.
susepaste package so people can use to paste things, bugreporter to report bugs to assist. The question is do people use them heavily, or not
User will use them as needed, and it would be better that they don't need to use it heavily :) Note that susepaste and bugreporter are perfect example why one needs Help Assistant. They are there, but I didn't know about bugreporter, and I'm not a new user. Even experienced users have a problem to remember all tools that are available and can make use of Advanced options in Help Assistant that will skip a lot of questions targeted to new users. We patch applications for many reasons, I don't see a problem to add Help Assistant that will work with user to address issue without presuming it is software failure. Initial version of Help Assistant can be very simple, just let user know all help options, give links for online help, start package management, bugreporter or whatever other subsystem help we have.
use bugreporter
rajko@linux:~> bugreporter Welcome to the submit bug report module! You have to have a valid .oscrc file. Please do so by running osc. rajko@linux:~> osc Your user account / password are not configured yet. You will be asked for them below, and they will be stored in /home/rajko/.oscrc for future use. Creating osc configuration file /home/rajko/.oscrc ... Username: ---------------------------------------------------------------- OK :) :D Togan, I was talking about help for users that can find Help menu, not about those that have Open Build Service (OBS) account. They can report bugs without bugreporter, although I hope that quality of reports is better with it. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/18/2012 04:00 PM, Rajko wrote:
On Tue, 18 Sep 2012 09:04:52 +0200 Togan Muftuoglu <toganm@opensuse.org> wrote:
On 09/18/2012 06:40 AM, Rajko wrote:
On Mon, 17 Sep 2012 09:14:10 -0500 ions.
Of course instead of package management one can open support wizard ... I do not think that would change anything as we do have,
It is changing few important things: * accessibility of tools
User has to remember one location to look for help and that is Help menu in any application, plus in case that application is crashing Help Assistant should be located in the Main Menu too. Like: Main Menu > Computer > Help Assistant (persistent) Main Menu > Favorites > Help Assitant
see below
Initial version of Help Assistant can be very simple, just let user know all help options, give links for online help, start package management, bugreporter or whatever other subsystem help we have.
Himm I thought some if not the most was already part of the greeter thingies that come with KDE, or the Firefox thingies, but not having used them I can not be sure
use bugreporter
rajko@linux:~> bugreporter Welcome to the submit bug report module!
You have to have a valid .oscrc file. Please do so by running osc.
rajko@linux:~> osc
Your user account / password are not configured yet. You will be asked for them below, and they will be stored in /home/rajko/.oscrc for future use.
Creating osc configuration file /home/rajko/.oscrc ... Username: ----------------------------------------------------------------
OK :) :D
Ok that I accept since I had a valid .osrc file it did not ask for it
Togan, I was talking about help for users that can find Help menu, not about those that have Open Build Service (OBS) account. They can report bugs without bugreporter, although I hope that quality of reports is better with it.
Well in that case, I can only suggest one thing make the wiki or the support database better, if I need to go to Arch wiki or debian or gentoo (but honestly Arch is better IMHO) then the problem is within what one has and creating another tool will not make the change the situation. So to me fix what is broken in this case documentation is broken. And yes user will have to remember one location support page <http://en.opensuse.org/Portal:Support> Just check Arch wiki and compare it with ours decision is yours Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 18 Sep 2012 17:08:28 +0200 Togan Muftuoglu <toganm@opensuse.org> wrote:
Himm I thought some if not the most was already part of the greeter thingies ...
Greeter is in need of attention :) That is actually what Help Assistant should replace.
... if I need to go to Arch wiki or debian or gentoo ... then the problem is within what one has and creating another tool will not make the change the situation.
Wiki is as good as people that contribute content and manage it. It needs skilled people, php and java programmers, editors, administrators, document writers, artists, and it is asking for attention. We are short in every respect. Also, your choice of documentation sources tells that you are advanced user that needs bare metal advices. That will work for users that have at least some technical aspirations, but not so well for those that only look where is Help menu and expect hand holding trough the process.
And yes user will have to remember one location support page <http://en.opensuse.org/Portal:Support>
That is when Internet is working. What is needed are offline pages to fix problems with network access and graphics, so that people can actually access Portal:Support. And, when you mention it, that one needs some attention too :) Although, we tried to make it release independent,
Just check Arch wiki and compare it with ours decision is yours
I was looking often online docs in other distros, and they were better in some respects, in some not. Some articles are up to date, some not, some useful, some touch basics. It is a mixed bag where situation is changing with time. Solution would be joined effort as in one writes article other copy and adjust to the local needs. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/18/2012 07:35 PM, Rajko wrote:
On Tue, 18 Sep 2012 17:08:28 +0200 Togan Muftuoglu <toganm@opensuse.org> wrote:
Himm I thought some if not the most was already part of the greeter thingies ...
Greeter is in need of attention :) That is actually what Help Assistant should replace.
It still won't solve the problem as the documentation is what needs polishing.
And yes user will have to remember one location support page <http://en.opensuse.org/Portal:Support>
That is when Internet is working. What is needed are offline pages to fix problems with network access and graphics, so that people can actually access Portal:Support.
Then make Portal:Support documentation available offline i.e pdf file or info file. Interestingly ages ago (SuSE 7.2 or so) I had initiated a project called susefaq and the idea was similar have something that is working with or without network access. But I won't do it again. So in order to have Help Assistant working with no network you still need polished documentation that is also available offline regularly updated to reflect changes what is available online Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Or every x months/years anyone will start a thread with a magic solution to the versioning. Maybe 1 year will not be fun enough, so someone will suggest a 8months or 6 months concept to be sincronized with major DE's release.
In a way I do agree with you, because changing every release the rules of game won't take us nowhere and this stuff can really undermine our efforts; we can't Marketing failures to influence the engineering part of the distribution... period, full stop! Someone within SUSE as main sponsor should stop this non-sense discussions and should hold this for as much time as required with the aim of gathering relevant data information regarding our user base and their real needs; Until we have objetive and reliable data on this, we're risking the credibility and work of a large community because of marketing failures. Keep in mind this discussion started because of marketing buzz failures. We need data to analyze, not opionions without any relevant background :) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 17 Sep 2012 12:12:22 +0200, Jos Poortvliet wrote:
Note that the 2 year support livecycle is something we'd have to put effort in: SUSE is currently paying for 18 months, the remaining 6 months would have to come from community efforts. Either in lowering the support load during the 18 months to make it reasonable for SUSE to spread out their efforts more or doing those 6 months separate.
It strikes me that there's overlap with SLE that could possibly be leveraged here. 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
Hi, On 09/11/2012 11:53 AM, Andreas Jaeger wrote:
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
Independed on the schedule, I think it's a good idea to discuss what features we do for the next release. The systemd discussion on opensuse- factory already lead to this webpage: http://en.opensuse.org/openSUSE:Goals_12.3
If we are moving towards systemd why not cease the console-kit dependency, or at least start porting things towards systemd and use its facilities rather than the dead project as I understand console-kit is history or going in that direction Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Togan Muftuoglu <toganm@opensuse.org> [2012-09-13 12:03]:
Hi,
On 09/11/2012 11:53 AM, Andreas Jaeger wrote:
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
Independed on the schedule, I think it's a good idea to discuss what features we do for the next release. The systemd discussion on opensuse- factory already lead to this webpage: http://en.opensuse.org/openSUSE:Goals_12.3
If we are moving towards systemd why not cease the console-kit dependency, or at least start porting things towards systemd and use its facilities rather than the dead project as I understand console-kit is history or going in that direction
Just because RH abandoned it does not mean that is is dead or going away any time soon. There are many Linxu distros which do not use systemd, the BSDs and Solaris which is also invested in CK. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/13/2012 01:59 PM, Guido Berhoerster wrote:
* Togan Muftuoglu <toganm@opensuse.org> [2012-09-13 12:03]:
Hi,
On 09/11/2012 11:53 AM, Andreas Jaeger wrote:
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
Independed on the schedule, I think it's a good idea to discuss what features we do for the next release. The systemd discussion on opensuse- factory already lead to this webpage: http://en.opensuse.org/openSUSE:Goals_12.3
If we are moving towards systemd why not cease the console-kit dependency, or at least start porting things towards systemd and use its facilities rather than the dead project as I understand console-kit is history or going in that direction
Just because RH abandoned it does not mean that is is dead or going away any time soon. There are many Linxu distros which do not use systemd, the BSDs and Solaris which is also invested in CK.
Then openSUSE should not bother to change to systemd as well with this logic and BSDs or Solaris are not openSUSE projects or have they become and I missed it. Even Arch is now switching to systemd and they are a rolling release AFAIK. In one mailinglist there is the discussion of dropping sysv-init for the next release in another there is the discussion of should tumbleweed be the rolling release or should we have 12.3. or 13.1 or whatever, yet my understanding is if it is a rolling release than it is the latest-greatest mumbo jumbo and that means phasing out old concepts and introducing the future. All I am saying is if the idea/goal whatever word you want to use for the next release is to use systemd as the only approach then we should seek the ways to use systemd native approches instead of console-kit, and I do realize it's not let's switch over yet the question for me is valid are we half hearted do systemd or full. Just my 0.02 Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi Will, Regardless of the schedule we decide, we have to look at the process and clean up our act a little bit. With more and more people wanting rolling releases like distros... look at the success of tumbleweed I think a 6-8 months cycle is probably good... Though before that I think we need a proper process about the following things... * list of official devel projects for the distro... -at the moment one can get it when branches the package from the factory. -who is in "charge" of the repo. -improve the reaction time for the submit process... branch-> devel-> factory, -it happened to me that in some devel projects this time was more than one week, and sometimes a small infinity. Usually the last step devel->factory is very slow... *nominate a list of disjoint projects that enhance the distro (science, education, gnome current/stable, kde current/stable, kde:extra, gnome:extra). Some of them we already have we have to work only on the disjoint part. *refine the texlive instalation process... at the moment is slow like hell due to the branching in many small packages... *let us take branding and polishing seriously. *let us have weekly reports shouts on the ml about the progress of the main goals on the style Dominique did with gcc47 move. * at the moment two major moves seem to be envisaged a) keep only systemd for booting and b) python2 and python3 alternatives... * should we adopt kde-telepathy as main IM for kde instead of kopete? * should we relegate kde3 and old gnome spins to community repos and keep the oss tree only with the current versions of the two? regards, Alin Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
With vacations in August and holidays in December, we cannot release in September or January. I like the 8-month cycle, and support the return to November, August and March for releases .1, .2, and .3, respectively. With the "short" release cycle, I suggest that the elimination of SystemV be delayed until 13.1. I support the change to systemd, but I understand the objections of those that do not. The delay will allow the cleanup of more systemd problems, and the SystemV supporters will have a better chance of getting their maintainers in place. The python2/3 situation seems to be handled quite easily, thus the main development and testing efforts will be in supporting secure UEFI booting, and keeping up with new developments in KDE, etc. Larry -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 11 Sep 2012 12:23:06 -0500, Larry Finger wrote:
I like the 8-month cycle, and support the return to November, August and March for releases .1, .2, and .3, respectively.
I would agree with this.
With the "short" release cycle, I suggest that the elimination of SystemV be delayed until 13.1.
I would also agree with this - that gives enough advance notice to those who have something to migration from sysv to systemd, and the change in "major" version number (yeah, I know that's not really how the versioning works, but it's still a perceptual thing) makes for a clear signal that there is a significant change - and aligning a significant change with that bump in release number intuitively makes sense for users. 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 Tue, Sep 11, 2012 at 1:58 PM, Jim Henderson <hendersj@gmail.com> wrote:
On Tue, 11 Sep 2012 12:23:06 -0500, Larry Finger wrote:
I like the 8-month cycle, and support the return to November, August and March for releases .1, .2, and .3, respectively.
I would agree with this.
As a primarily a leaf package maintainer, I don't feel one way or the other, but respect the desire of Coolo to maintain the March, November, July cycle (don't know where August came from).
With the "short" release cycle, I suggest that the elimination of SystemV be delayed until 13.1.
I would also agree with this - that gives enough advance notice to those who have something to migration from sysv to systemd, and the change in "major" version number (yeah, I know that's not really how the versioning works, but it's still a perceptual thing) makes for a clear signal that there is a significant change - and aligning a significant change with that bump in release number intuitively makes sense for users.
The elimination of sysv does seem to be too big for March from what little I know. I vote we skip a big 12.3 spring release and prepare for a 13.1 fall release with systemd only supported. But I propose in roughly the March timeframe we do a major respin of 12.2 with UEFI secure boot included. Further that we use Tumbleweed as the source of the respin. ie. devel => factory => tumbleweed => march 12.2 respin with UEFI secure boot If UEFI secure boot is ready earlier or later, then we adjust the time of the respin based on its availability. Tumbleweed would need to guarentee sysV init support through at least the March respin. Does that make sense technically? ie. have factory start dropping sysV init support now, but have tumbleweed maintain it at least thru March? Maybe a factory-no-sysVinit-staging repo would be needed. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 11 Sep 2012 14:24:04 Greg Freemyer wrote:
With the "short" release cycle, I suggest that the elimination of SystemV be delayed until 13.1.
I would also agree with this - that gives enough advance notice to those who have something to migration from sysv to systemd, and the change in "major" version number (yeah, I know that's not really how the versioning works, but it's still a perceptual thing) makes for a clear signal that there is a significant change - and aligning a significant change with that bump in release number intuitively makes sense for users.
The elimination of sysv does seem to be too big for March from what little I know.
I haven't seen a systematic collection of regressions that would come from dropping sysvinit init yet, besides the catchall bug [*]. Without that, talk of unworkable interactive init scripts, problems mounting crypted filesystems, or telling unmanaged VM processes to quit at shutdown is too nebulous for me to judge this (but neither is it my decision). * https://bugzilla.novell.com/show_bug.cgi?id=696902 Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer 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 Tue, 2012-09-11 at 11:23 +0200, Will Stephenson wrote:
So I'd like to start the discussion now before we lose a month waiting to discuss it at osc12, where only a fraction of the active members of the project are is going to be present anyway. You don't want everything to be decided by German Engineers* for you do you?
Some ideas to start the ball rolling:
I generally think getting us back into the established 8-month cycle is a good thing, even at the expense of 12.3 being shortened. We defined .1 .2 and .3 as being November, July, March. I do see the long-term support advocates screaming bloody murder that this would in effect shorten the support lifecycle of 12.2. But I guess that's really another matter to discuss. However, my feeling is this: I don't think it is entirely clear to everyone, except those most closest to the development process, exactly what was the reason (or where things went wrong) for the 12.2 delay. A lot of marketing-spin that the delay was the product of our own success as a growing community. A scheduling discussion is good, but equally as important is a discussion centering on the lessons learned and how we can build new pathways for the community to step up and contribute. There's a lot of people who would like to move from armchair quarterbacking to actual field play but discussions are generally so convoluted and vague, it may be intimidating to them to actually take the next step into technical contribution. Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi, Le mardi 11 septembre 2012, à 07:46 -0500, Bryen M Yunashko a écrit :
However, my feeling is this:
I don't think it is entirely clear to everyone, except those most closest to the development process, exactly what was the reason (or where things went wrong) for the 12.2 delay.
+1. If we don't do a post-mortem about 12.2, we'll hit the same issue for 13.1 or 13.2 (unlikely for 12.3, though). So I'd very much prefer to see some analysis of what went wrong, and see how we're going to fix this. I'm pretty sure we can fix the issues, and there has already been some reorganization that will help. Of course we can discuss the schedule for 12.3, but I don't think we should commit to a schedule before this work is done. Some of the issues we had I can think of: - live images were not working for a while - new gcc broke stuff for too long (hi zypp!) - we skipped some milestones (iirc) - coolo had too many fires to deal with by himself Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Vincent Untz <vuntz@opensuse.org> [2012-09-12 08:22]:
Hi,
Le mardi 11 septembre 2012, à 07:46 -0500, Bryen M Yunashko a écrit :
However, my feeling is this:
I don't think it is entirely clear to everyone, except those most closest to the development process, exactly what was the reason (or where things went wrong) for the 12.2 delay.
+1.
If we don't do a post-mortem about 12.2, we'll hit the same issue for 13.1 or 13.2 (unlikely for 12.3, though). So I'd very much prefer to see some analysis of what went wrong, and see how we're going to fix this. I'm pretty sure we can fix the issues, and there has already been some reorganization that will help.
Of course we can discuss the schedule for 12.3, but I don't think we should commit to a schedule before this work is done.
Some of the issues we had I can think of:
- live images were not working for a while - new gcc broke stuff for too long (hi zypp!) - we skipped some milestones (iirc) - coolo had too many fires to deal with by himself
IIRC there were numerous problems caused by the "usr-move" which was largely busywork for no added benefit. And we should probably also add the infrastructure downtimes to this list. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 12.09.2012 08:22, Vincent Untz wrote:
Some of the issues we had I can think of:
- live images were not working for a while We're in the same situation again ;(
Same for the DVD ;(
- new gcc broke stuff for too long (hi zypp!) - we skipped some milestones (iirc) Because of the above problems, no cause in itself.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 12 Sep 2012 08:22:20 Vincent Untz wrote:
If we don't do a post-mortem about 12.2, we'll hit the same issue for 13.1 or 13.2 (unlikely for 12.3, though). So I'd very much prefer to see some analysis of what went wrong, and see how we're going to fix this.
We did our internal postmortem meeting for 12.2 today and will post results shortly. Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer 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
Hello, Why don't we decide to make it rolling? How many rolling distros are there? How many easy to install and use? Make it rolling, we'll save resources. Not only infrastructure but developers as well. Developers will maintain or create their packages for only one version and not for 11.4 (it ends on 15th, right?), 12.1, 12.2, Tumbleweed, Factory. It's easy to do using OBS but I guess it's mode hard disk space (please correct me if I'm wrong). Rolling distro will have factory and tumleweed. Also there won't be delays like 12.2. For marketing reasons, someone can create ISO file every now and then, print it and promote it to events. Maybe this will give us an ID to our distro. Ubuntu has LTS. Fedora has new features first (eg Gnome). What do you think? Green means go Stathis -- http://about.me/iosifidis http://iosifidis.co.cc or http://eiosifidis.tk http://blogs.gnome.org/eiosifidis http://eiosifidis.wordpress.com Facebook: http://www.facebook.com/eiosifidis Google+: http://bit.ly/IU5p3I Connect: https://connect.opensuse.org/pg/profile/diamond_gr Ένα γραμμάριο δράσης αξίζει ένα τόνο θεωρίας Μην αφήσεις αυτό που σε τρώει να χορτάσει -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 11.09.2012 16:04, Stathis Iosifidis (aka diamond_gr) wrote:
Hello,
Why don't we decide to make it rolling? How many rolling distros are there? How many easy to install and use?
Make it rolling, we'll save resources. Not only infrastructure but developers as well. Developers will maintain or create their packages for only one version and not for 11.4 (it ends on 15th, right?), 12.1, 12.2, Tumbleweed, Factory. It's easy to do using OBS but I guess it's mode hard disk space (please correct me if I'm wrong). Rolling distro will have factory and tumleweed. Also there won't be delays like 12.2.
For marketing reasons, someone can create ISO file every now and then, print it and promote it to events.
Maybe this will give us an ID to our distro. Ubuntu has LTS. Fedora has new features first (eg Gnome). What do you think?
If you want a rolling release, use factory. It's updated every day. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
If you want a rolling release, use factory. It's updated every day.
// no prisioners... --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
If factory and tumbleweed are stable enough, then it's ok. So far I used personally tumbleweed 3 times and installed it to 4 of my friends and after a week, we did format. Regarding factory, I was told not to use it for stability. I would like to install once something at home computer and just update to new patches. A friend of mine has 11.4 and I'll tell her not to upgrade it. At home I won't upgrade 12.1. When I said rolling, I meant stable rolling. Also, we have an identity. What I mean here is identity on release cycle. Thanks 2012/9/11 Nelson Marques <nmo.marques@gmail.com>:
If you want a rolling release, use factory. It's updated every day.
// no prisioners...
--- Artigo 21 - Direito à Resistência
Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública.
Constituição da Républica Portuguesa -- 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
Am 11.09.2012 16:45, schrieb Efstathios Iosifidis:
If factory and tumbleweed are stable enough, then it's ok. So far I used personally tumbleweed 3 times and installed it to 4 of my friends and after a week, we did format.
Regarding factory, I was told not to use it for stability. I would like to install once something at home computer and just update to new patches.
A friend of mine has 11.4 and I'll tell her not to upgrade it. At home I won't upgrade 12.1.
When I said rolling, I meant stable rolling.
If Tumbleweed is not working for you, no rolling release will do for you. If you want to stay with one release forever, that's not rolling - that's things like evergreen. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 11 of September 2012 17:45EN, Efstathios Iosifidis wrote:
When I said rolling, I meant stable rolling.
That's what most people would like: rock stable and with latest versions of everything. Unfortunately it's not possible, these goals contradict each other. The more rolling your distribution is, the less stable it is, and vice versa. Various distributions and distribution flavours choose their weights for these goals but all of them have to face the fact that one can't have both. Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 2012-09-11 16:45, Efstathios Iosifidis wrote:
If factory and tumbleweed are stable enough, then it's ok. So far I used personally tumbleweed 3 times and installed it to 4 of my friends and after a week, we did format.
Regarding factory, I was told not to use it for stability.
I always like to promote "see for yourself", since what works for one need not work for another. And then of course then there are biased advisors.
I would like to install once something at home computer and just update to new patches.
A friend of mine has 11.4 and I'll tell her not to upgrade it. At home I won't upgrade 12.1.
When I said rolling, I meant stable rolling.
When you say stable rolling, you mean openSUSE:x:Update. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Attempting to follow this discussion, my impression is that there are differing ideas about what different concepts mean and what the consequences of some choices might be. So perhaps it would be a good idea to take a few moments (okay it might need more than a few) to make a brief overview of the development process and the factors affecting release time, and the consequences of short versus longer release schedules. Particularly how it relates to kernel development and updates, desktops (someone mentioned complaints about KDE versioning) and stability. I understand this might be already known to many on the Project list since this is a development focus, but for less technical users 'listening in' to the conversation, it would be very helpful - and perhaps it would help the discussion to have these points clarified. -- IRC: helen_au helen.south@opensuse.org helensouth.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 23.09.2012 13:31, Helen South wrote:
Attempting to follow this discussion, my impression is that there are differing ideas about what different concepts mean and what the consequences of some choices might be.
So perhaps it would be a good idea to take a few moments (okay it might need more than a few) to make a brief overview of the development process and the factors affecting release time, and the consequences of short versus longer release schedules. Particularly how it relates to kernel development and updates, desktops (someone mentioned complaints about KDE versioning) and stability.
I understand this might be already known to many on the Project list since this is a development focus, but for less technical users 'listening in' to the conversation, it would be very helpful - and perhaps it would help the discussion to have these points clarified.
There is no hard data about this. There are different oppinions on how things relate. And then there are factors like "are higher KDE versions better without testing" that people just disagree on - so talking about release schedules is like talking about what kind of sneakers to wear. The problem we have: we can only afford one type of sneakers for all.
From my point of view, the whole discussion has shown: sticking to the roadmap we agreed on some years ago sounds like the best option.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Monday 24 September 2012 10:03:08 Stephan Kulow wrote:
On 23.09.2012 13:31, Helen South wrote:
Attempting to follow this discussion, my impression is that there are differing ideas about what different concepts mean and what the consequences of some choices might be.
So perhaps it would be a good idea to take a few moments (okay it
might need more than a few) to make a brief overview of the development process and the factors affecting release time, and the consequences of short versus longer release schedules. Particularly how it relates to kernel development and updates, desktops (someone mentioned complaints about KDE versioning) and stability.
I understand this might be already known to many on the Project list since this is a development focus, but for less technical users 'listening in' to the conversation, it would be very helpful - and perhaps it would help the discussion to have these points clarified.
There is no hard data about this. There are different oppinions on how things relate. And then there are factors like "are higher KDE versions better without testing" that people just disagree on - so talking about release schedules is like talking about what kind of sneakers to wear.
The problem we have: we can only afford one type of sneakers for all. From my point of view, the whole discussion has shown: sticking to the roadmap we agreed on some years ago sounds like the best option.
... and keep our compromise solution which doesn't really work for anyone... The reason I proposed a 12 month cycle with Tumbleweed is that it actually solves the discussion about longer vs shorter: 12 months makes openSUSE a better choice for those people who take care of the computers of friends and family (where Ubuntu LTS now reigns) as it'll have the same 3 year life cycle (even a bit more). Meanwhile, Tumbleweed keeps those who want something fresh into openSUSE - beating even Fedora on having the latest, always. So, we attract more people to openSUSE. If we manage to improve on our user engagement (mentoring, marketing, documentation) this is what can bring more people to test Factory. Nothing else will, really. Staying on the current 8 month cycle and trying to force more people to use Factory means we just keep disappointing people, leading to less users and - well, less people testing Factory of course. Why care about a dead or dying distro? You really have to look OUTSIDE the people on this list, Coolo. People will always leave openSUSE, that is a fact of life - and if we fail in getting new people in, openSUSE will just go the way of the dodo. Tumbleweed has probably gotten us more users (and some of those might now become engaged) than anything else we've ever done. We should build on that, not ignore it. /Jos
Greetings, Stephan
On 09/11/2012 04:04 PM, Stathis Iosifidis (aka diamond_gr) wrote:
Hello,
Why don't we decide to make it rolling? How many rolling distros are there? How many easy to install and use?
Make it rolling, we'll save resources. Not only infrastructure but developers as well. Developers will maintain or create their packages for only one version and not for 11.4 (it ends on 15th, right?), 12.1, 12.2, Tumbleweed, Factory. It's easy to do using OBS but I guess it's mode hard disk space (please correct me if I'm wrong). Rolling distro will have factory and tumleweed. Also there won't be delays like 12.2.
Some people (like me) prefer to use stable releases ie.11.4 is for me the latest stable release where no major new toys, such as systemd, were introduced, hence most of my servers use 11.4 as default while some of them ,oops dare I say it are running 11.1. So not everything is about running the latest and the greatest yada yada. But if factory is stable enough, it could/should be used as a rolling release, more on the edge. So I am thinking promoting the usage of factory rather then tumbleweed is a better approach as fixing bugs in Factory means a better (read as with lesser bugs) release.
For marketing reasons, someone can create ISO file every now and then, print it and promote it to events.
Maybe this will give us an ID to our distro. Ubuntu has LTS. Fedora has new features first (eg Gnome).
I though we already had the ID : geeko and if you are not happy with it build your own <http://geekobuilder.suse.com/>
What do you think?
Green means go
And geeko means Avanti Avanti ;) Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Tirsdag den 11. september 2012 17:04:48 Stathis Iosifidis skrev:
Why don't we decide to make it rolling? How many rolling distros are there? How many easy to install and use?
Make it rolling, we'll save resources. Not only infrastructure but developers as well. Developers will maintain or create their packages for only one version and not for 11.4 (it ends on 15th, right?), 12.1, 12.2, Tumbleweed, Factory. It's easy to do using OBS but I guess it's mode hard disk space (please correct me if I'm wrong). Rolling distro will have factory and tumleweed. Also there won't be delays like 12.2.
For marketing reasons, someone can create ISO file every now and then, print it and promote it to events.
Maybe this will give us an ID to our distro. Ubuntu has LTS. Fedora has new features first (eg Gnome). What do you think?
There are plenty of rolling release (russian roulette) distros already - and even two openSUSE flavours (Factory and Tumbleweed). So that wouldn't give openSUSE a unique identity. openSUSE already has a unique identity in being the only (gratis) distro combining power, professionalism and productivity. This identity just needs to be nurtured more. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2012-09-11T16:24:17, Martin Schlander <martin.schlander@gmail.com> wrote: (Martin, it isn't just you who chimed in with this kind of response, but:)
There are plenty of rolling release (russian roulette) distros already - and even two openSUSE flavours (Factory and Tumbleweed). So that wouldn't give openSUSE a unique identity.
Rolling release isn't meant to be "russian roulette"; and neither does Factory ("bleeding edge") count as a production version of continuous delivery. There'd still be increments - e.g., the systemd/sysvinit obsolescence that would be developed *and tested* in a branch (or Factory) before being merged back into the rolling user release once done, or a new sound system, ... And, of course, smaller stuff - say, new version of any given package with no or little cross-dependencies - could be phased in all the time. But there'd be no "everyone jump at once" transitions like "2.4 GB to download; continue?" Providing a stable rolling release would be impressive. Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 2012-09-11 at 16:40 +0200, Lars Marowsky-Bree wrote:
Providing a stable rolling release would be impressive.
Regards, Lars
Is Tumbleweed not considered stable yet? I thought it was. Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Bryen M Yunashko <suserocks@bryen.com> [09-11-12 10:47]:
On Tue, 2012-09-11 at 16:40 +0200, Lars Marowsky-Bree wrote:
Providing a stable rolling release would be impressive.
Regards, Lars
Is Tumbleweed not considered stable yet? I thought it was.
I too. I have been using Tumbleweed since it's inception with *few* difficulties, mostly of my own making.... :^) Tks Greg KH -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2012-09-11T11:48:39, Patrick Shanahan <paka@opensuse.org> wrote:
Providing a stable rolling release would be impressive. Is Tumbleweed not considered stable yet? I thought it was. I too. I have been using Tumbleweed since it's inception with *few* difficulties, mostly of my own making.... :^)
I really like Tumbleweed. But it is not a rolling release; it's more of a selective backport. (Which I appreciate, honestly! It's just not what's being suggested.) This morning, zypper dup greeted me with
2172 packages to upgrade, 315 to downgrade, 660 new, 37 to reinstall, 300 to remove, 383 to change vendor, 14 to change arch. Overall download size: 2.43 GiB.
A rolling release would have fed these into the repository over the course of the last 8 months or so when they were ready and tested in smaller increments/bundles, not as one huge jump. You know, much like "We're not going to do the 1.0/1.2/1.4/2.0/2.2/2.4/2.6 thing any more", because such major releases were not considered appropriate for todays world? ;-) (Incidentally, the downgrades are those where Tumbleweed/12.1 already had the same version but a higher build number. That's also not supposed to happen in a rolling release ;-) And some packages, like vim, actually did experience a minor version downgrade.) Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Lars Marowsky-Bree <lmb@suse.de> [09-11-12 12:40]:
On 2012-09-11T11:48:39, Patrick Shanahan <paka@opensuse.org> wrote: ... I really like Tumbleweed. But it is not a rolling release; it's more of a selective backport. (Which I appreciate, honestly! It's just not what's being suggested.)
well, that is *your* definition, not mine.
This morning, zypper dup greeted me with
2172 packages to upgrade, 315 to downgrade, 660 new, 37 to reinstall, 300 to remove, 383 to change vendor, 14 to change arch. Overall download size: 2.43 GiB.
apparently you do not do "zypper dup" very often.....
A rolling release would have fed these into the repository over the course of the last 8 months or so when they were ready and tested in smaller increments/bundles, not as one huge jump.
which it did. I only get *many* package updates when something like kde updates to new version as it did today: ////// 155 packages to upgrade, 5 to change vendor. Overall download size: 531.9 MiB. After the operation, additional 1.9 MiB will be used. Continue? [y/n/?] (y): ////// Which is more than the *actual* change to 12.2 from 12.1.
You know, much like "We're not going to do the 1.0/1.2/1.4/2.0/2.2/2.4/2.6 thing any more", because such major releases were not considered appropriate for todays world? ;-)
(Incidentally, the downgrades are those where Tumbleweed/12.1 already had the same version but a higher build number. That's also not supposed to happen in a rolling release ;-) And some packages, like vim, actually did experience a minor version downgrade.)
somehow you missed the kernel downgrade, but you have your own definitions. Tumbleweed works well for me! Tks Greg KH -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Patrick Shanahan wrote:
* Lars Marowsky-Bree <lmb@suse.de> [09-11-12 12:40]:
On 2012-09-11T11:48:39, Patrick Shanahan <paka@opensuse.org> wrote: ... I really like Tumbleweed. But it is not a rolling release; it's more of a selective backport. (Which I appreciate, honestly! It's just not what's being suggested.)
well, that is *your* definition, not mine.
This morning, zypper dup greeted me with
2172 packages to upgrade, 315 to downgrade, 660 new, 37 to reinstall, 300 to remove, 383 to change vendor, 14 to change arch. Overall download size: 2.43 GiB.
apparently you do not do "zypper dup" very often.....
Every upgrade is a risk of something ending up not working. -- Per Jessen, Zürich (19.9°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 11.09.2012 18:38, Lars Marowsky-Bree wrote:
On 2012-09-11T11:48:39, Patrick Shanahan <paka@opensuse.org> wrote:
Providing a stable rolling release would be impressive. Is Tumbleweed not considered stable yet? I thought it was. I too. I have been using Tumbleweed since it's inception with *few* difficulties, mostly of my own making.... :^)
I really like Tumbleweed. But it is not a rolling release; it's more of a selective backport. (Which I appreciate, honestly! It's just not what's being suggested.)
This morning, zypper dup greeted me with
2172 packages to upgrade, 315 to downgrade, 660 new, 37 to reinstall, 300 to remove, 383 to change vendor, 14 to change arch. Overall download size: 2.43 GiB.
A rolling release would have fed these into the repository over the course of the last 8 months or so when they were ready and tested in smaller increments/bundles, not as one huge jump.
You know, much like "We're not going to do the 1.0/1.2/1.4/2.0/2.2/2.4/2.6 thing any more", because such major releases were not considered appropriate for todays world? ;-)
Well, if you integrate new gcc, there is no point in saying it generates much faster code unless you offer the new code in form of newly compiled binaries. So a rolling release has even more times when you have to download tons of packages. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 09/11/2012 05:23 AM, Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment?
Every time I've been involved in a project without a schedule, we've had a long period of (probably highly satisfying for developers) of 'undirected hacking' followed by crisis, followed by a rush to 'get it out before people forget who we are' which inevitably had some fallout (I'm thinking of the period leading up to KDE 4.0 here ;).
So I'd like to start the discussion now before we lose a month waiting to discuss it at osc12, where only a fraction of the active members of the project are is going to be present anyway. You don't want everything to be decided by German Engineers* for you do you?
Some ideas to start the ball rolling:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
* Extend the release cycle keeping same process and longer stabilization period (effective 12.2 release process; leads to shipping 'outdated' stuff)
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
While more planned features sounds like an initial good idea, I also like the more free flowing nature of openSUSE development. However, on the feature part we should not forget that Fedora and Ubuntu are mostly driven by companies, while in openSUSE I'd like to belive we have a larger share of non SUSE employee contributed packages in the distro than in the other two distributions. Thus the "planned feature" part is much more tricky. Looking at the process and what we ship as a whole I think we have some serious issues, and I have 2 talks at osc where from my point of view we need some serious thinking and possibly disruptive changes. One issue is the process and how things are tied together, the other is package and project maintainership. But heeding Will's advice I am not going to write a dissertation now, come to osc!!!! While I believe we have some serious issues, that will only increase as the community grows if we do not address them, I also think we should get back to our "original" cycle, i.e. the next release should be in March. First, the issues as I see them will probably not get fixed in 1 release cycle, may it be 6 or 8 month, anyway. Second, I think what we have can certainly get 12.3 out the door in time. I strongly agree with Andrew that predictability is very important and I think we have done a good job with that except for 12.2. Important now will be that we get back to it, forget the slip ever happened and deliver again as promised. In the end we have to look at underlying issues to make the job of getting the distribution out the door on time easier. In the end a couple of people always have to do the heavy lifting at the end and that is a recipe for disaster. However, I do not believe that this is a root cause, I think that this is only a symptom of underlying issues. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead 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
On Tuesday 11 September 2012 11:23:19 Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment? <snip>
"just a note": As you can probably see on the 300 mails thread, this is hard to discuss on- line. I'd like to point out that THIS is what the *openSUSE Conference* is for: offering a place to discuss these things *in person*. If you care about our release schedule and technologies we'll ship (including systemd and such, yes), make sure you're there. And again, if money is a problem, officially the deadline has passed but we'd rather have requests late than people NOT show up. So PLEASE mail the travel committee and ask for help if finances are getting in the way. There is still budget and it's what the committee is for. Izabel and Kostas would gladly help out. Know that decisions made at the conference, in person, are going to guide where openSUSE is going. Simply because, in person, it is easier and faster to get to consensus - and that is what makes decisions. /Jos (of course, the over 150 people at the Summit can and should do the same: discuss these things...)
Will
(* Something Pascal was moping about on IRC last week, I'm hoping to tempt him out of his cave)
Jos Poortvliet wrote:
Know that decisions made at the conference, in person, are going to guide where openSUSE is going. Simply because, in person, it is easier and faster to get to consensus - and that is what makes decisions.
I think reaching a consensus depends primarily on the number of people, not the method of communication. Whether you meet in person, by email or telephone it is exactly equally difficult when you have a hundred or more people. If you have less than 10, it's also equally difficult, but much more likely. -- Per Jessen, Zürich (12.6°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Jos Poortvliet <jos@opensuse.org> [2012-09-19 11:19]:
On Tuesday 11 September 2012 11:23:19 Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment? <snip>
"just a note": As you can probably see on the 300 mails thread, this is hard to discuss on- line.
I'd like to point out that THIS is what the *openSUSE Conference* is for: offering a place to discuss these things *in person*.
If you care about our release schedule and technologies we'll ship (including systemd and such, yes), make sure you're there. And again, if
That means also excluding people from the decision-making process (regardless of their stake in openSUSE development) who simply cannot attend due to time constraints. A problem that doesn't exist with asynchronous means of communication like email or the web. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 2012-09-19 at 11:18 +0200, Jos Poortvliet wrote:
I'd like to point out that THIS is what the *openSUSE Conference* is for: offering a place to discuss these things *in person*.
Allow me to jump in with another "shameless plug-in" :-D What Jos is saying also applies to this weekend's openSUSE Summit in Orlando, Florida. If the spirit moves you to make a last minute decision to head on to Orlando, we'll be there welcoming you with open Geeko arms! We have a General meeting scheduled for Sunday that includes a luncheon. Three fun-filled hours to talk about the state of anything under the openSUSE Project umbrella. http://summit.opensuse.org Bryen -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi,
Allow me to jump in with another "shameless plug-in" :-D What Jos is saying also applies to this weekend's openSUSE Summit in Orlando, Florida. If the spirit moves you to make a last minute decision to head on to Orlando, we'll be there welcoming you with open Geeko arms! We have a General meeting scheduled for Sunday that includes a luncheon. Three fun-filled hours to talk about the state of anything under the openSUSE Project umbrella.
It would be really helpful if the following topics arise: * Release process * Bugzilla We are analysing both so input is welcome. If we can get minutes from those meetings it would be even better. 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 Wed, 19 Sep 2012 11:18:13 +0200, Jos Poortvliet wrote:
If you care about our release schedule and technologies we'll ship (including systemd and such, yes), make sure you're there.
Jos - I don't think it's necessarily a fair assumption that if you can't be there, it's because you don't care. I would /love/ to be there, but even with the travel program, as a contract employee/consultant, the cost of travel isn't my main consideration - the loss of income, as the only vacation time I get is unpaid. There's not just a financial cost, but an opportunity cost - and as much as I support the project, paying the bills has to be my top priority. :) There needs to be an alternative for those who do care but can't attend an in-person event in order to get their input involved. Even a Google Hangout scheduled, or some time set aside on the IRC project channel would help get input from those who want to be involved. 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 Wed, 2012-09-19 at 15:41 +0000, Jim Henderson wrote:
On Wed, 19 Sep 2012 11:18:13 +0200, Jos Poortvliet wrote:
If you care about our release schedule and technologies we'll ship (including systemd and such, yes), make sure you're there.
Jos -
I don't think it's necessarily a fair assumption that if you can't be there, it's because you don't care.
In defense of Jos, I think he simply botched his own writing. I don't think he meant to imply that if you don't show up, you don't care. Probably better worded if said "if you care and you can find a way to make it to the Conference..."
I would /love/ to be there, but even with the travel program, as a contract employee/consultant, the cost of travel isn't my main consideration - the loss of income, as the only vacation time I get is unpaid. There's not just a financial cost, but an opportunity cost - and as much as I support the project, paying the bills has to be my top priority. :)
There needs to be an alternative for those who do care but can't attend an in-person event in order to get their input involved.
I think slowly but surely, we're finding ways to do this. We have oSC coming up next month, Summit this weekend, COSCUP mini-openSUSE Conference in Taipei last month. Last year we made our first community appearance at Brainshare where we met you. We're showing up at more FOSS events than ever before. We may not have perfected yet how to leverage these in-person dialogues more effectively on a global basis, but I think we're getting there. Lessons are being learned and retooled as we go along.
Even a Google Hangout scheduled, or some time set aside on the IRC project channel would help get input from those who want to be involved.
Hangout only allows ten connections. I think Hangout can be used in some situations, but not as a replacement to a large conference gathering. We need to continue to explore ways to communicate with our community and users across many borders, cultures, and languages.
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 Wed, 19 Sep 2012 11:04:04 -0500, Bryen M Yunashko wrote:
I don't think it's necessarily a fair assumption that if you can't be there, it's because you don't care.
In defense of Jos, I think he simply botched his own writing. I don't think he meant to imply that if you don't show up, you don't care. Probably better worded if said "if you care and you can find a way to make it to the Conference..."
I think you're probably right - that that's what he meant. Hadn't had any caffine yet this morning. :) I certainly didn't mean to "jump on" Jos.
There needs to be an alternative for those who do care but can't attend an in-person event in order to get their input involved.
I think slowly but surely, we're finding ways to do this. We have oSC coming up next month, Summit this weekend, COSCUP mini-openSUSE Conference in Taipei last month. Last year we made our first community appearance at Brainshare where we met you. We're showing up at more FOSS events than ever before. We may not have perfected yet how to leverage these in-person dialogues more effectively on a global basis, but I think we're getting there. Lessons are being learned and retooled as we go along.
Yeah, it's a question of doing both - and in-person meetings certainly have value. My point wasn't to say they don't (and if that's how it came across, I apologise profusely for that). The implication that if you want to be heard you need to be there in person (even if unintentional) diminishes a lot of voices in the community. Not so much for my own personal benefit (I provided my situation as an anecdote to explain one of many reasons why someone might not be able to attend), but for the benefit of the community as a whole.
Even a Google Hangout scheduled, or some time set aside on the IRC project channel would help get input from those who want to be involved.
Hangout only allows ten connections. I think Hangout can be used in some situations, but not as a replacement to a large conference gathering. We need to continue to explore ways to communicate with our community and users across many borders, cultures, and languages.
I know the capability is there to allow at least more viewers - it was used to promote viewing of the solar eclipse a few months back. It makes sense that the video side would be limited - and in such a scenario, the limit would be to the moderators of the discussion. But leveraging both synchronous and asynchronous communications channels is needed, because of time zone differences and people's availability. Gathering the right data isn't easy - and while it should be made / easier/, there is a difference between making it easier and excluding valuable input because someone has to use a different means to make their input. Just like putting a survey together - it's easy to say they don't provide value when the time spent creating it isn't sufficient to create a proper survey. It's harder to build a survey that actually answers the questions you want to answer, but he quality of data is better if you take the time to do it properly. :) 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 09/19/2012 06:41 PM, Jim Henderson wrote:
On Wed, 19 Sep 2012 11:18:13 +0200, Jos Poortvliet wrote:
If you care about our release schedule and technologies we'll ship (including systemd and such, yes), make sure you're there. Jos -
I don't think it's necessarily a fair assumption that if you can't be there, it's because you don't care.
I would /love/ to be there, but even with the travel program, as a contract employee/consultant, the cost of travel isn't my main consideration - the loss of income, as the only vacation time I get is unpaid. There's not just a financial cost, but an opportunity cost - and as much as I support the project, paying the bills has to be my top priority. :)
There needs to be an alternative for those who do care but can't attend an in-person event in order to get their input involved.
Even a Google Hangout scheduled, or some time set aside on the IRC project channel would help get input from those who want to be involved.
Jim
+1 to regular Google Hangout meetings Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 19 Sep 2012 20:39:03 +0300, Angelos Tzotsos wrote:
Even a Google Hangout scheduled, or some time set aside on the IRC project channel would help get input from those who want to be involved.
+1 to regular Google Hangout meetings
Did a little checking, and it seems that the eclipse thing was set up as a hangout that was broadcast - so limited interactivity from the viewers. But maybe something like openmeetings could be set up? 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
I'd like to point out that THIS is what the *openSUSE Conference* is for: offering a place to discuss these things *in person*.
While I believe the community/members and everyone involved should have the ultimate decision on this, I'm available to participate in a focus group or help conducting one if needed. As most people know, I'm prepared to do that and I have qualifications for it also (as my field is actually marketing management). peace -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 19 Sep 2012 11:18:13 Jos Poortvliet wrote:
On Tuesday 11 September 2012 11:23:19 Will Stephenson wrote:
Given that 12.2 slipped by 2 months, and the development process for 12.3 is "to be discussed", what schedule are we working on towards 12.3 at the moment?
<snip>
"just a note": As you can probably see on the 300 mails thread, this is hard to discuss on- line.
I'd like to point out that THIS is what the *openSUSE Conference* is for: offering a place to discuss these things *in person*.
Probably this has already been pointed out on the thread, but since you CCed me: as I pointed out on the original thread, a) neither the entire project, nor all those whose voices deserve to be heard, is going to be at the conference b) the discussion exceeds the scope of a couple of BoFs at the conference, which happens late in the cycle this discussion affects. This thread has brought to light useful inputs that can frame the decision making at the conf. So big, representative decisions take big mail threads - man-up a bit, read, digest and prepare a summary of them to share at the conference. Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer 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
participants (35)
-
Agustin Benito Bethencourt -
Alin M Elena -
Andreas Jaeger -
Andrew Wafaa -
Angelos Tzotsos -
Bryen M Yunashko -
Christian Boltz -
Dominique Leuenberger a.k.a DimStar -
DuBois, Scott L. -
Efstathios Iosifidis -
Felix Miata -
Greg Freemyer -
Guido Berhoerster -
Helen South -
Jan Engelhardt -
Jim Henderson -
Jos Poortvliet -
Larry Finger -
Lars Marowsky-Bree -
Luiz Fernando Ranghetti -
Markus -
Martin Schlander -
Michal Kubeček -
Nelson Marques -
Patrick Shanahan -
Per Jessen -
Rajko -
Robert Schweikert -
Saulo Moraes -
Stathis Iosifidis (aka diamond_gr)
-
Stephan Kulow -
Sven Burmeister -
Togan Muftuoglu -
Vincent Untz -
Will Stephenson