[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]