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 not? If doable I would think that was a fair compromise... JBG -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
