Testing -> stable?

[Thorsten Leemhuis]

On 28.08.2007 20:32, Michael DeHaan wrote:
> Thorsten Leemhuis wrote:
>> On 26.08.2007 17:35, Mike McGrath wrote:
>>  * if there is a strong need to move a package it is allowed according
>> to the policy. But for the other updates I think we manage EPEL similar
>> to how RHEL does it: non-crucial updates go into a quarterly update and
>> no major updates if there isn't a reasons for them. Just "latest and
>> greatest" is IMHO not the reason
> How do you determine which bugfixes are "serious enough"? ... it seems 
> like the package maintainers
> usually would be the best qualified to make this decision

Of course they are.

> if there is a 
> bit of a guideline for it.

http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

Section "Some examples of what package updates that are fine or not"

>> - manage EPEL more like Fedora {,Extras}
>>  * afaics most people in the buildup phase wanted a stable EPEL and I
>> really think that should continue to be our #1 goal. 
> Are there threads that say this? 

Sorry, EPEL is being discussed for over a year now (first in private),
and I can't point out a single thread -- but that my interpretation (it
was in a * section, which were explicitly marked as my opinion) of lots
of discussions that happend over the last year and lead to the
guidelines as they were written.

>[...] 
> Quarterly doesn't really mean "stable", it just means "quarterly".   So 
> having a rolling stable where a package must be
> in testing for X seems reasonable to me.

Note that the idea was to freeze EPEL for some (two) weeks before
pushing it to stable. We didn't do that, but I still think we should go
for that in the long-term.

>> But I see a need
>> and interest for a "more up2date packages" EPEL repo. That what I call
>> EPEL-rolling; I'm fine with having it in parallel to the stable repo.
>> But do we have the man-power to start this yet?
> Disregarding resources, what would we really like to do?  I'd hate to 
> shoot down an idea for how we are going to do things
> because there aren't resources.  If it's a good enough idea, there might 
> be resources crawling out of the woodwork ... you never
> know...

On the other hand you can easily fail if you try to many things at once.
And we have lots to improve in EPEL before doing the next big steps.
Koji and Bodhi for EPEL. More packages. make sure we have a common look
and feel (e.g. not "latest and greatest" in one area and "old and
boring" in another one).

CU
knurd