only keep the latest package in testing?

Thorsten Leemhuis fedora at leemhuis.info
Thu Nov 8 19:05:38 UTC 2007


On 06.11.2007 01:57, Russell Harrison wrote:
> On 11/5/07, Michael DeHaan <mdehaan at redhat.com> wrote:
>> If this is based on it being a "testing" repo I am not sure that is
>> right as different folks are using it in different ways, but then again,
>> I'm not sure
>> it actually matters that much either.   What are the technical reasons
>> for keeping it?
> 
> I can see the use case where a user is testing a fix for package foo
> in updates-testing.  As it turns out package foo only partially fixes
> the problem.  When the developer pushes out foo +1 to updates-testing
> with what he believes is the true fix it turns out to break in the
> user's environment for whatever reason.  That user would most likely
> like to revert to the original package foo he started with in
> updates-testing because it is better than the one in stable for him.
> If only one version of a package is in updates-testing at any one time
> he wouldn't have that option.

I think we are discussing a hypothetic corner case here that IMHO likely
will happen very rarely and only affect a small number of users.

> Its the same argument for keeping multiple versions in stable.  Just a
> smaller number of users impacted. 

Yes.

> It just so happens these are the
> users that are most likely helping out the project. 

The same reasons could be applied for rawhide. But for years (until we
got koji) the most important testers were not able to get yesterdays
package. Some people even argued that this is the better approach, as
users that way are forced to report bugs instead of going back as a
workaround.

> [...]

Anyway: currently in testing only one package is kept, as nobody yelled
in the days right after I announced that behavior change. Michael's mail
came right after I flipped the bits iirc. We can change it back -- but I
say we leave it as it is and see what happens.

CU
knurd




More information about the epel-devel-list mailing list