Can we do both testing->stable moves on the same day?

Thorsten Leemhuis fedora at leemhuis.info
Thu Jun 12 12:22:06 UTC 2008


On 10.06.2008 13:34, Michael Stahnke wrote:
> I too have thought that doing pushes on different dates is hard on
> end-users, but we need to remember that a non-trivial amount of effort
> goes into pushing these updates.

Well, it's a bit of work, but it not that it takes multiple hours. Doing 
it in one go might in fact be a little bit easier for me (or others that 
prepare and realize the move).

IOW: I'm all for it (that why I asked mpdehaan to propose his idea here 
after he brought it up on #epel).


BTW: I fully agree with what Ville said in:
https://www.redhat.com/archives/epel-devel-list/2008-June/msg00025.html

> Just a general note/reminder, I don't use cobbler/koan myself nor know really 
> anything about them and maybe this is already being observed with their 
> updates:
> 
> Intrusive updates like the one described above should be done only for good 
> reasons:
> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Package_maintenance_and_update_policy

Having a repo where some packages are maintained in Fedora update style 
(e.g. update to the latest versions often) while others are maintained 
in RHEL update style (update only if there is a really good reason; 
don't break systems; don't force admis to adjust configuration) is IMHO 
the worst thing EPEL can do. We (like every project/repo) *really* need 
a consistent "look and feel", as EPEL users otherwise will be confused 
and nobody will be happy with EPEL.

As RHEL/CentOS users are used to the RHEL update style I'd say updating 
EPEL packages in RHEL style is the safest bet. And that what the 
guidelines suggest right now. We don't enforce that, but I tend to say 
some EPEL packages are moving forward to fast; maybe we should ask some 
of the EPEL maintainer to slow down a bit. I did that in the past now 
and then (I just watched epel-commits and asked maintainers if they were 
preparing big updates if the update really is needed), but I don't do 
that anymore due to a lack of time. Sorry.

CU
knurd




More information about the epel-devel-list mailing list