On Monday, September 27, 2010 06:49:13 pm Bill Nottingham wrote: > Jaroslav Reznik (jreznik@xxxxxxxxxx) said: > > It's not "some random day" - it's when you actually accept an update! > > It's not easy to estimate impact of update - but banning completely is > > not a solution neither. > > We do not give nearly enough information in our updates for the user to > make any informed decision here. Just tagging it as 'enhancement' isn't > enough. So, it most of the time does boil down to: > > 1) they accept updates in general, and they get it on some random day > 2) they wonder, think updates may change things. Therefore updates are > scary, and should be avoided by the user. > > Neither of these are great. Ok - that's one problem - we sucks in selective updates and information for users. Other could be - change release scheme: 1. very similar to current one - rawhide, Fn, Fn-1 * rawhide - really raw development platform * Fn - live release, similar to current state but more testing (proventesters, autoqa) * Fn-1 - do not touch, even more strict rules advantage - nearly no changes in our current workflow, compromise for more groups, Fn is live, hq updates but sometimes makes things more unstable, collateral damage... but slowing down in time (no big updates Fn+1 - 1 month?), once it hits Fn - it's really fresh but another 6 months of development - more stable, more bugfixes, happier users. With current policy - we have two frozen releases, no devs care anymore, dead and stable in terms - not touched not in functionality. 2. big change * devel branches - now with GIT - every new feature should be developed in separate branch -> map it to development instance of Koji... * rawhide - merged devel branches with integration testing - fresh one, similar to current Fedora release - can be used by developers and power users - sometimes broken by updates but they know how to deal with this breakage... * Fn - released one, strict update policy, service packs? - so faster update cycle? maybe 3. combination - I'd like to see devel branches, really and I like Fn & Fn-1 flexibility from the first example! As I already said - I'm not against making Fedora better and more stable. I just think it's more complicated than just this "less updates = stable experience = more users" ;-) Jaroslav > Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
