Re: yum: Critical path update in testing for 4 months?

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

 



On Sun, 6 Dec 2015 22:29:33 +0100
Michael Schwendt <mschwendt@xxxxxxxxx> wrote:

> On Sun, 6 Dec 2015 12:40:45 -0700, Kevin Fenzi wrote:
> 
> > Perhaps. But you are speculating that this is the case here. 
> > Unless you have talked to the maintainer and thats what they told
> > you?  
> 
> I'm not speculating as I didn't claim I know the reason why this
> particular Yum update is stuck.

Your email read that way to me at least. Sorry if I misunderstood you. 

> I answered to the general question "what is the reason for maintainers
> building updates without the intention to push them?". Knowing that
> some maintainers believe the release bureaucracy sucks can be helpful
> in understanding [some of] the background.

I suppose, but I think there's also other reasons. 
 
> I still talk to other packages from time to time, and I have learned
> to be careful when doing that, because some find it easier to
> complain about various things in a private conversation (and leave
> the project silently) instead of voicing their opinion in one of
> Fedora's public places.

I'm sorry to hear that. I personally don't mind feedback anywhere in
public, but that doesn't mean that I will agree with everything or
agree to do work to change things. 

...snip...

> It's only a lack of testers and a lack of _another method_ to publish
> such updates _automatically_ based on submitter's early request.

So, what you would like would be: 

a) If you have autokarma set and the update doesn't reach autokarma,
push it automatically when it reaches the timeout. 

or

b) Have another bodhi setting for 'push automatically when reaching the
'maintainer can now push to stable' time limit. (defaulted on or off?)

> What's needed is software developers and policy makers to agree that
> some areas are problematic, and to agree on ideas and an agenda. To
> agree that the karma system is flawed and things like testers
> ignoring past votes and overriding another's -1 with their own +1
> should not be possible.

I don't think I agree with that as a blanket statement. What if the
person who added -1 is just wrong, or you cannot duplicate the exact
problem that they said the update had?
 
> If people in Fedora leadership positions don't consider broken upgrade
> paths a problem, and the developers of update release tools don't
> consider them problematic either, not much will happen about such
> issues, for example. Users will continue to run into downgrades,
> unresolvable deps, or runtime breakage. And then there are all those
> ideas where the only response will be that patches will be accepted,
> with the ideas never making it onto a todo list/agenda.

upgrade path is a different issue. Perhaps it should be talked about in
a different thread instead of adding into this one thats not related to
it?

IMHO, upgrade path is less of an issue than it was in the past now that
upgrade methods use distro-sync. Of course there are cases where it
could be an issue still. 

> > > Currently I have two security fixes, which are two months old.
> > > Nobody does the needed testing. The karma isn't reached. Nobody
> > > ensures that they enter the stable updates repo even with 0
> > > karma.     
> > 
> > Perhaps you could solicit testers? Either upstream people or on the
> > test list or on irc?  
> 
> Perhaps Fedora is just not popular enough?

I don't see how you get to that conclusion from that problem statement.

> How many layers of extra work do you ask for? Imagine that a fix is
> from upstream or has been applied and released upstream already. What
> extra testing and baby-sitting is needed at Fedora's side even for
> entirely new packages?

What would you propose? Ship the update directly to stable because
upstream oked it?

> Remember the period when packagers voted +1 on their own updates.
> There still is no way to do that *officially*.  It is still assumed
> that packagers test their own update (even if they don't do that in
> Rawhide, uh-oh!), but they cannot ask for it to be pushed
> automatically after X days other than based on that karma threshold
> that won't be reached for some packages ever.

They could perhaps file a bodhi RFE asking for that feature?

> > > Meanwhile, F21
> > > has reached end-of-life without anyone making sure to do a last
> > > push of security fixes for it.     
> > 
> > We did do a last push. Just blindly pushing all security updates (if
> > they were ready or not) isn't a particularly good idea IMHO.   
> 
> Has the security team done anything at all to even push any other
> security updates for F21 not blindly? I mean, Fedora packagers
> receive all those security related tracker ticket bugzilla spam where
> the security team changes ticket fields again and again, but nobody
> cares that the released fixes find their way onto the Fedora User's
> installations?

You would be better addressing such questions to them: 

https://fedoraproject.org/wiki/Security_Team

I know they prioritized things and have been trying to close a bunch of
older vulnerabilities.

kevin


Attachment: pgpTSGsk2cfZN.pgp
Description: OpenPGP digital signature

--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx

[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