submitters +1ing their own packages

"Jóhann B. Guðmundsson" johannbg at
Thu Sep 8 18:42:56 UTC 2011

On 09/08/2011 06:27 PM, Till Maas wrote:
> On Thu, Sep 08, 2011 at 01:16:50PM -0400, Josh Boyer wrote:
>> I don't think a maintainer can realistically replace wide-spread user
>> based testing in a variety of environments.  In light of that, we can
>> either accept a maintainer +1 as "I tested this as I would use it and
>> it worked" (which should be implied by them submitting the update
>> already anyway), or we can disallow it as the policy says.
>> I don't think adding more definitions or steps to the existing policy
>> is really going to improve anything.
> Why does pushing an update to testing imply that the maintainer has
> already used the package and tested it? I cannot find this requirement
> in the wiki and I do not find it useful. For this requirement every
> maintainer would need to copy the Fedora infrastructure to distribute
> updates to his or her testing machines. Also it would delay the
> possibility for other users to test an update, unless they are forced to
> use other distribution methods than the updates-testing repository. But
> then the problem to verify updates emerges, since packages are first
> signed when they are put into updates-testing.

How about tying the requirement to criteria the component belongs to?

As in components flagged as base/core/critical might restrict the 
maintainer from +1 his own component and require more stricter QA 
oversight while components that are not flag as base/core/critical might 

If doable I would think that was a fair compromise...


More information about the devel mailing list