On Mon, 27 Sep 2010 10:19:51 +0200 Jaroslav Reznik <jreznik@xxxxxxxxxx> wrote: > > 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. Well, most people either: a) apply all updates as they come and hope for the best or that they can fix issues or deal with them as they show up. or b) are afraid of updates and only apply them rarely when they need something from them or have a lot of time to deal with fallout. I would like it to be: c) apply updates often and are confident that nothing will blow up or change so they need to re-learn something, and they get all the security updates in a timely manner. > 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 ;-). Yeah, and it's up to our maintainers to talk to their upstreams and convince them to try doing a better job. ;) > 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 Well, we have a base set of rules and a process to request exceptions for the corner cases. ;) > - 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). If we try and come up with a master complicated change plan we will never do anything. I maintain we can put this updates policy into effect NOW (or soon) and gain from it right away. ;) If we need to adjust more (either way) we should not be afraid to do so, but we shouldn't just sit here and keep talking either. ;) kevin
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
