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. if you point epel_signers at a bug that mentions a CVE we will push the package to stable. But i wanted to open up the discussion here. EPEL is supposed to be stable and slower moving than fedora. the package in question happened to be built yesterday. and it was an update of an existing package. so it really should live in testing for a little while.
I wanted to make sure that for security issues you can get a packaged pushed to stable at any time. Everything else should go though a period of testing.
Dennis
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 )] """
We should enhance this; the request for moving should include the reason for the move.
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.
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.
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)
so it really should live in testing for a little while.
+1 for the package in question
[...]
Cu knurd
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@lists.fedoraproject.org
-
Dennis Gilmore -
Thorsten Leemhuis