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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
