Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2010-03-02 at 12:08 -0500, Frank Ch. Eigler wrote:
> James Antill <james@xxxxxxxxxxxxxxxxx> writes:
> 
> >> > [...]
> >> > ...but they have almost no options if they are happy to stay with
> >> > the software that they have.
> >> 
> >> Doesn't "just not running random/unrestricted yum update" exactly
> >> encode that option?
> >
> >  No, for two reasons:
> >
> > 1. The user is often informed, from various sources, that they should
> > apply updates. We even want users to do that.
> 
> OK, but then we're not talking about the person who's happy to stay
> with the software they have, but about a more typical person who is
> not too risk-averse and is willing to consider unsolicited updates.
> Those are different dudes.

 Right, I figured that was implied. If I'm happy with, say, named as it
came in F12 ... that implies I don't want any updates for new features
which might break my nameserver, but I'd still want any high exposure
security fixes _quickly_ ... and I'd be happy to see significant
bugfixes for existing problems (but, again, I don't want to see 1 update
a month to fix small problems).
 Could you suggest better wording (that's smaller than the above
paragraph :).

> > Of course the assumption with that advise is that there aren't that
> > many updates, and they will mainly be severe bug fixes and security
> > fixes ...
> 
> Fedora updates may be classified, but perhaps not granularly enough.
> An update can include a mixture of security fixes, serious bug fixes,
> minor bug fixes, new features, and of course risks such as changed
> configuration files, new known bugs.  Perhaps a new update could be
> scored by the maintainer on all these scales, so that the client
> update interface can easily filter/sort to the preferred top few.

 I think it's understood that you can just take one and classify the
bundle as that. Obviously there is still some leeway here, and we might
need more policies but starting by asking the packagers to DTRT doesn't
seem like a terrible idea.

> > and they will have gone through a lot of testing. 
> 
> Well, this being Fedora, "a lot of testing" is always a matter of
> faith.

 Sure, we don't guarantee it and we still won't be able to ... but
there's a big difference between "this has been in updates-testing for 3
days (or less!), has 10 bug fixes and 10 new features" compared with
"this has been in updates-testing for a month, been updated twice to fix
minor problems found in testing and has 10 bug fixes and 2 new
features".

-- 
James Antill - james@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux