RFC: Package maintenance and update policy for EPEL -- take 1

[Thorsten Leemhuis]

Kevin Fenzi schrieb:
> Some minor comments: 
> 
>> The changes that cant be avoided get routed into different release
>> trees. Only updates that fix important bugs (say: data-corruption,
>> security problems, really annoying bugs) go to a testing branch for a
>> short time period and then build a second time for the stable branch;
>> those people that sign and push the EPEL packages to the public repo
>> will skim over the list of updated packages for the stable repo to
>> make sure that sure the goal "only important updates for the stable
>> branch" is fulfilled.
> Can we possibly require any package that wants to push to the current
> release to have a bug filed and mention that in the changelog? 
> This would make looking and making sure a package is supposed to fix a
> data-corruption/security/serious bug much easier on people who push the
> updates. 

Yes, maybe that would be helpful, but on the other hand it makes things
more complicated and buerocratic.

My take: Bring this idea back up after EPEL has taken of and if people
push to much stuff to the stable branch.

> We might want to also mention (although perhaps it's just common sense)
> that if people have any questions about how they should handle an
> upgrade in their package, they should consult this list and/or the SIG
> members for input. It might be that someone here could find or be able
> to generate a backported fix when a maintainer is unable to. 

Might be a good idea. I'll add a short section.

> Anyhow, looks good to me. 

thx.

Cu
thl