To update or not to update...

[Rahul Sundaram]

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.

Rahul