On Tue, Nov 18, 2014 at 10:49 AM, Roger Luedecke <roger.luedecke@gmail.com> wrote:
On Tue, 2014-11-18 at 08:30 +0100, Ancor Gonzalez Sosa wrote:
On 11/17/2014 06:33 PM, Claudio Freire wrote:
On Thu, Nov 13, 2014 at 2:02 PM, Roger Luedecke <roger.luedecke@gmail.com> wrote:
Poll on Google plus with over 1200 respondents shows 89% of our users support an annual release cycle. https://plus.google.com/110312141834246266844/posts/g5FdGJ9iSqB
I think we should however restructure the way we do releases in order to minimize the bumpiness of release. I propose a pseudo-annual release cycle. The idea being that our current state of release is messy at best and could use some last minute repository fixing and bug swatting. I propose that we esentially make the way we release now 'open-beta' at the 11th month.
We then use the 12th month to get all repos online and fixed. Also would be a good chance to give us about a month to fix problems with our disc images, and remaster the 'open-beta' 11th month GM with patches and hardware support fixes.
With this scheme we should see much smoother official release days by essentially duping the users into considering the state we currently call release to be beta, and giving us a month to clean things up.
Question is, if having this marked beta will cause more testing than having it marked release candidate.
Because there's already a lengthy time during which the images are released as "release candidate" and there still isn't enough bug swatting happening during that time. Will a beta period improve things?
Also, in my lingo, beta < rc.
Perhaps it's just a matter of sticking with RC longer and advertising and calling for testing more prominently.
I wouldn't expect a big difference just by renaming things and adjusting the time frames. I would actually change the process a bit.
Right now, we set a proposed date for the release. We set the RC and beta dates counting back from that day. The release happens in the proposed release date if it's "good enough" to go which mainly means that it's not badly broken.
Just from the top of my head, an alternative could be like this (just a first though). I'd NOT have a fixed date for the release in advance. We set a date for the "freeze" (call it beta, call it RC, I don't mind). For that frozen version (good enough for daily usage but not labeled as definitive) we encourage everybody to report bugs and we classify their severity. The actual release happens when the bugs count is below a threshold. Let's say less than 3 critical bugs and less than 15 medium bugs. I know bugzilla is currently a mess, but you get the idea. Something more similar to what Debian does.
Cheers.
-- Ancor González Sosa YaST Team at SUSE Linux GmbH I like that idea. I think the freeze point too though should be considered as I mentioned, and pushed as the default download. Sure, some people may get a nasty surprise because they didn't read the bold print... but we can't really be faulted for people not wanting to read.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I think labeling TW as Beta or RC (or open beta) is a bad idea, it should be a stable rolling release distro, for more stable releases, I think we should "branch" a beta, complete with its repos, then an RC, then release only when it is really stable (more than anything we've done before), just like what Ancor said. Mustafa Muhammad -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org