submitters +1ing their own packages
"Jóhann B. Guðmundsson"
johannbg at gmail.com
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