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