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

Re: To update or not to update...

Thorsten Leemhuis wrote:

On 16.08.2007 10:39, Rahul Sundaram wrote:
Thorsten Leemhuis wrote:

A repo where some packages stay stable while others are updated to the
latest and greatest is a mix that won't make people happy, as those that
are those that are interested in a "a stable base" and those that want
"latest and greatest" both don't get what they want.
On the other hand this is what happens within the base product too. The desktop apps and treated different from system apps for example.

Could you or somebody else outline the scheme RHEL uses in more detail?
Is it anywhere written down?

Not anywhere publicly afaik but I don't think a lot of it would apply to EPEL anyway as we cannot expect EPEL maintainers to be doing a lot of backporting.

If I maintain a package which is written in a language or code I am not very familiar with and it has a critical security along with other major changes, I am going to pull in all of that and fix the issue anyway.

The general idea is that the risk of breakage in a core component or library is large and the benefit is small when compared to desktop or leaf applications so be more conservative in the former and slightly more liberal in the latter.

Further: I don't think a more detailed "policy" makes sense -- I'd say
we should discuss all "major update: yes or no?" for EPEL on a case by
case basis here on the list. In RHEL I suppose it's similar: a
release-engineer (or whatever the individual or group is called) likely
has to ACK major updates there as well.

RHEL follows a model which involves engineers, product management (which depends on customer input) and QA and depending on the package, the individual backported patches has to be reviewed with multiple engineers other than the person doing the work. Obviously this requires resources we don't have in EPEL.

Maintainers should probably be trusted to make the best judgments in EPEL keeping in mind that less churn is more desirable. If you aren't sure, don't update.


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