pushing packages to stable

[Dennis Gilmore]

On Friday 24 October 2008 01:30:05 pm Thorsten Leemhuis wrote:
> On 24.10.2008 16:38, Dennis Gilmore wrote:
> > Yesterday a request to move a package to stable early was made.  I denied
> > it because the reason given was "due to popular customer demand"  there
> > is no way to measure that. and the next stable push will be just over a
> > week away.
> >
> > To Date the only reason that packages have been pushed to stable early
> > has been security issues.
>
> Sorry, but that's not incorrect. I in the past now and then did push
> some packages by packagers request if there was a good reason for it. Of
> course "due to popular customer demand" alone is not enough reason.
>
> Security bugs are of course one (very) good reason, but not the only one
> to move a new package to the proper repos quickly -- sometimes other
> bugsfixes are just as important to send out quickly, hence we should
> push them as soon as possible.
>
> >   if you point epel_signers at a bug that mentions a CVE
> > we will push the package to stable.
>
> That is not how we handled it in the past. What EPEL Steering Committe
> agreed on a few months ago was added to the FAQ in the Wiki:
>
> """
>    What do I need to do if I need to get a updated package quickly into
> the EPEL proper?
>
> If you want to see a package moved from the testing or needsign repos to
> the proper EPEL repos (for example to fix important (security) bugs)
> please test the package once it got build; if it works well send a mail
> asking for this move to [[MailTo(epel_signers-members AT fedoraproject
> DOT org )]
> """
that's basically what I said, but much shorter,  of course a bug that makes a 
package not work should be fixed and pushed stable also.  but of course that's 
what testing is for.  a package should never go from needsign to stable 
without going through testing first unless is a security issue IMO. 

> We should enhance this; the request for moving should include the reason
> for the move.
I personally wont move a package to stable without good justification like a 
bug report that mentions a CVE,  orsome critical bug like a segfault (but of 
course that's why we have testing)

> >  But i wanted to open up the discussion here.
>
> Such a rule like the you outlined above IMHO would be stupid bureaucracy
> -- a hurdle that makes life for packagers hard, as they for each and
> every bug would have to open a bug. That's something most packagers
> don't want to do. They just want to commit the package and tell somebody
> "hey, this update fixes a security bug; I tested this, it works; please
> move to the proper repos as soon as possible." Which often worked fine;
> I even did it often if somebody on IRC just said to me "hey, can you
> move this please, as it fixes a important bug"; that was low overhead
> and worked just fine for everybody. Especially as that way we can fix
> bugs that don't (yet) have a CVS entry.
ive done it via irc also when told that this fixes  a CVE, if the bug is so 
critical  there will be a bug report somewhere. point us at it. 

> >  EPEL is supposed to be stable and slower moving than fedora.
>
> Fully agreed. But it should not be moving slower then RHEL, as even Red
> Hat pushes enhancements as regular updates now and then. We should do
> the same in EPEL if there is a good reasons.
we do  once a month. 

> >  the package in question happened to be built yesterday.
>
> Then of course it's unacceptable to move if there is no good reason
> (which we might not aware of yet).
>
> >  and it was an update of an existing package.
>
> Which is irrelevant -- the packager might be aware of crucial
> data-corruption bug in the package that needs to be fixed quickly to
> avoid further problems for users (but for the package is question that
> afaics was not the case)
the data corruption bug would have a  bur report somewhere.  either in 
upstream bug tracker or EPEL's bugzilla.  point us at it.

> >  so it really should live in testing for a little while.
>
> +1 for the package in question