To update or not to update...

[Thorsten Leemhuis]

On 16.08.2007 14:06, Rahul Sundaram wrote:
> 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.

"update to latest version instead of backporting" is allowed by the EPEL
policy to fix a important bug. But the mail that started this thread
wasn't about fixing a important bug.

But we drift away.

> [...]
>> 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.

Sure. But we have a mailing list and sending a "what do you guys think:
should I update from foo-x.y to foo-x.(y+1) or foo-(x+1).0 because bar"
is not that much overhead IMHO.

> Maintainers should probably be trusted to make the best judgments in 
> EPEL keeping in mind that less churn is more desirable. [...]

I'd like to agree, but seems at least some people simply build new stuff
for EPEL and don't care (or don't know) about the "only update to new
version if there is a strong need to" policy which EPEL has. So we
sooner or later need tell those maintainers to be more careful, adjust
our policy/goals, start EPEL-rolling in parallel, <insert other
possibilities> or live with the fact that parts of the EPEL-stable repo
follow the a rolling-release scheme similar to Fedora while other parts
go for the careful RHEL-style. The latter would IMHO be quite bad, and I
really don#t want us to go in that direction.

CU
knurd