REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Jaroslav Reznik]

On Saturday, September 25, 2010 09:03:08 pm Kevin Fenzi wrote:
> On Thu, 23 Sep 2010 16:58:39 +0200
> 
> Jaroslav Reznik <jreznik at redhat.com> wrote:
> > Not a very latest thing but more like - more useful thing. Because
> > some useful "user experience" changes could lead to better user
> > experience even changing slightly the old one. It's not easy to catch
> > this in policy. I like the idea, I understand why we want it - I want
> > it too, why we need it, it's more relaxed than the first proposals
> > leading practically to frozen, dead and unmaintained releases. But
> > still there should be more space for packager's decision and of
> > course upstream - upstream releases for some reason.
> 
> Sure sometimes things change for the better... a new UI is nicer than
> the old one. The thing is that most people don't want that to happen on
> some random day in the middle of a stable release. This would cause
> them to stop doing what they wanted to do to learn the new UI. Much
> better when it's in the new Fedora release where they realize that they
> need to learn how the new version works before using it.

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.

> >Also this
> >
> > stability proposal has to be coupled with a new release scheme - not
> > just update policy but also release schedules, what we are going to
> > call "release", how often (9 months? branch every 6 - we we talking
> > with Jesse a few minutes ago), how big changes we want in a new
> > release etc... I'm not sure it's going to work without deeper changes
> > here too.
> 
> Feel free to put together a detailed proposal on a new release
> cycle and we can take a look.
> 
> I've often thought a 9month cycle (18 or 19 months supported) would be
> nice and give us more time, but then we are misaligned with a number of
> projects upstream that are on a 6 month cycle, and also, we don't
> release at the same time(s) each year, resulting in hitting holidays or
> the like. :(

Hmm, release cycles of upstream projects are problem. You're right. I'm still 
more for my slow-down "proposal" (not yet proposed - I just lost all ideals and 
sense of life - as it looked like "NO" is general conclusion. Now I feel again 
chance that someone will listen ;-).

R.

> I don't know a solution, but if you come up with one, please do let me
> know. ;)

There's probably no right solution - I just don't want to see as inflexible and 
bind by our own rules - open source is living body. I'm a fan of making Fedora 
better but I'm just not sure this is enough and it needs a lot more - as I said 
- different release scheme, make underlaying services more bullet proof (upstream 
task). Last time my Fedora didn't boot because of kdump (it was rebuilding, 
rebuilding and rebuilding initrd forever) - just banning updates does not help, 
it was easy for me to disable kdump service through run level 1, not easy for 
average user (and I'm not talking about basic user, avarage).

Jaroslav 

> kevin

-- 
Jaroslav Řezník <jreznik at redhat.com>
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.                               http://cz.redhat.com/