Don't put new packages through updates-testing

Rahul Sundaram sundaram at fedoraproject.org
Fri Jun 1 15:02:06 UTC 2007


Hans de Goede wrote:

>>> I'm very much against this, as it adds one more step to already long
>>> process of getting new packages in, the current wiki page describing the
>>> process divides it into 14 steps and it is lacking the add to comps step
>>> (and in my case the update SIG wiki pag, twice once to add it to the 
>>> list
>>> of packages undergoing review, once more to remove).
>>>
> 
> Please respond to this very imporant point!

Adding that step in the wiki can be done by anyone and addition to help 
improve quality are a good thing.

> 1) There will be no wide audience, even if they have updates-testing 
> enabled they will not automatically install the new packages let alone 
> use it,

If the package has a small audience then surely it can wait for a 
limited timeout in updates-testing

  For all but the top 100 popular new
> packages, being in updates-testing thus adss no additional testing as 
> no-one will install it.

100 is a purely arbitrary number.

> Repeating myself, then first get such a QA time organized up and running 
> and then, and only then, make updates-testing mandatory, if I get 
> usefull feedback from this, you've won me over.

If QA can be bypassed then that reduces the incentive to form the team 
in the first place.
> 
> Not true many reviewers review on the latest stable, it says nowhere 
> that a review should be done on rawhide.

Review is about guidelines and nowhere in the guideline does it even say 
that the fucntionality of the package should be tested. When I suggested 
that it be added I got back a knee jerk reaction to participate in 
reviews myself.

> All I'm asking for is to leaving this to the packagers discretion, isn't 
> Fedora supposed to be all about freedom? Then why put me in a straight 
> jacket.

It is not all about freedom though. There are several other factors that 
influence a decision.

Rahul




More information about the fedora-devel-list mailing list