kevin at scrye.com
Mon Sep 27 17:43:59 UTC 2010
On Mon, 27 Sep 2010 10:19:51 +0200
Jaroslav Reznik <jreznik at redhat.com> 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.
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. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100927/3e486f0f/attachment.bin
More information about the devel