On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote:
> I didn't bring up the "fun" argument. My point is that banning direct stable 
> pushes prevents us from fixing things for our users ASAP when needed. This 
> is all part of duty, not fun.

 And it prevents us from breaking things, with no warning (around and
around we go).

> In addition, in practice, it's quite likely that bugs will often be answered 
> with "it's too hard to backport that particular fix, upgrade to the current 
> version from backports (or even Cooker/Rawhide/whatever) if you need it". 
> There's no way you can really force maintainers to provide an update stream 
> which is "stable" under that definition (no upgrades, only backported 
> fixes).

 I know you aren't talking specifically of my proposal here:

https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29

...but it has the same "problem". But IMNSHO this isn't a problem, you
are arguing that people specifically hit by problem X can goto the
updates-testing (or whatever it's called) repo. and get a fix for it.
 Anyone not affected doesn't have to risk that update breaking anything
else they do care about (and for the people affected, if the cure is
worse than the disease they can easily backout).
 And that's only until the new version has been tested enough that it's
a lot more safe to give it to everyone.
 How is this not the best of all solutions? (for the users)

> > Many instances have shown that it does not give us the bugfixes 'for
> > free'. It comes with the cost of causing regressions. That may be a cost
> > which we decide we want to bear, but portraying things in a Panglossian
> > manner doesn't help your cause, as it just makes you look like you're
> > denying there could ever possibly be any problems with your method.
> 
> But that's not a cost for the maintainer (unless the regression breaks 
> his/her own system). :-)

 Indeed, this comment does seem to epitomize your argument.

-- 
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to