On 11 September 2012 10:36, Stephan Kulow 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 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 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 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

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 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 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 :

...

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

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 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

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

2012/9/14 Jos Poortvliet :

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 Fri, 14 Sep 2012 03:40:57 +0300 Angelos Tzotsos 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

2012/9/12 Jos Poortvliet :

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 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 :

...

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 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 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 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

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

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 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 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 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

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

On Wed, 12 Sep 2012 09:33:32 -0500 Bryen M Yunashko 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, Sep 16, 2012 at 8:07 PM, Bryen M Yunashko 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 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

On 09/17/2012 09:59 AM, Dominique Leuenberger a.k.a DimStar wrote:

Quoting Bryen M Yunashko :

...

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

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 wrote:

On Mon, 17 Sep 2012 08:59:41 +0200 "Dominique Leuenberger a.k.a DimStar" 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 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

On Wed, 19 Sep 2012 13:10:08 +0200 Sven Burmeister 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

On Friday, September 21, 2012 01:07:05 Markus wrote:

"DuBois, Scott L." 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.

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 :

...

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

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

* Nelson Marques [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

* Nelson Marques [09-18-12 11:57]:

2012/9/18 Patrick Shanahan :

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

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

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

...

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 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 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 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

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 Tue, 18 Sep 2012 17:09:27 -0500 Larry Finger 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 15:30:03 +0200 Stephan Kulow 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 Thu, 20 Sep 2012 13:57:01 +0200 Jos Poortvliet 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 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 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 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 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 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 Tue, 25 Sep 2012 20:40:18 +0200 Jos Poortvliet 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

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 wrote:

On Tue, 25 Sep 2012 12:48:46 +0200 Stephan Kulow 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 Fri, 21 Sep 2012 10:10:46 +0200 Stephan Kulow 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

On Sat, 22 Sep 2012 23:48:39 +0100 Nelson Marques 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

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 :

On Sat, 22 Sep 2012 23:48:39 +0100 Nelson Marques 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

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

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 Wed, 26 Sep 2012 23:47:01 -0500, Rajko wrote:

On Mon, 24 Sep 2012 17:59:36 +0000 (UTC) Jim Henderson 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 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, 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

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

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 wrote:

On Mon, 1 Oct 2012 15:45:28 +0000 (UTC) Jim Henderson 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 Tue, 2 Oct 2012 23:33:40 +0000 (UTC) Jim Henderson 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

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

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 :

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

* Jos Poortvliet [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

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

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

On Mon, 2012-09-17 at 15:20 +0100, Nelson Marques wrote:

2012/9/17 Bryen M Yunashko :

...

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

On Mon, 17 Sep 2012 09:14:10 -0500 Bryen M Yunashko 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 Tue, 18 Sep 2012 09:04:52 +0200 Togan Muftuoglu 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 Tue, 18 Sep 2012 17:08:28 +0200 Togan Muftuoglu 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

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

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

On 09/13/2012 01:59 PM, Guido Berhoerster wrote:

* Togan Muftuoglu [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

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, Sep 11, 2012 at 1:58 PM, Jim Henderson 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

* Vincent Untz [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 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

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 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 :

...

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

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

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 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

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 Tue, 2012-09-11 at 16:40 +0200, Lars Marowsky-Bree wrote: