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