submitters +1ing their own packages

Vít Ondruch vondruch at
Fri Sep 9 10:22:12 UTC 2011

Sorry, you are mixing two things:

1) One is testing environment and it can be probably well defined, 
clean, etc.

2) The other thing is maintainer mindset. You can try to convince 
yourself to take a different look but I doubt it will work. It reminds 
me like if you do patch review of your patches, which doesn't make 
sense. You, as a developer, are not able to spot weak points. And it is 
expected that every developer delivers well tested and well behaving 
code from his side (i.e. automatic +1 karma from his side). If there is 
not enough karma for his package to bring it into the stable, then there 
is probably time to ask somebody (probably on fedora-devel), to test 
this package.


BTW no policy can stop some "evil maintainer" who will create other 
Fedora accounts and give karma to his packages under different 
identities. You can even add karma without Fedora identity, but I am not 
sure if that counts.

Dne 9.9.2011 10:13, Nils Philippsen napsal(a):
> On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote:
>> I don't think a maintainer can realistically replace wide-spread user
>> based testing in a variety of environments.
> I didn't argue that this would be the case, but rather that persons who
> are developers/package maintainers can also wear a tester's hat as long
> as they can keep these roles separate.
>>    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.
> ^^^^^^^^^^^^^^^^^
> No, implicitly assuming that the final package was tested just because a
> maintainer submitted it is wrong in my eyes. To me, a maintainer
> submitting an update simply means "I've built (a) new package(s) which
> should fix these problems, now it/they can be tested." It shouldn't make
> a shred of difference if a person testing an update package is a
> maintainer or not in this process.
>> I don't think adding more definitions or steps to the existing policy
>> is really going to improve anything.
> Yet making a special case of testing by a maintainer makes the process
> more complicated. The policy regarding testing done by maintainers
> shouldn't be longer than one or two paragraphs and be summed up in "keep
> development and testing separate, ensure that your testing environment
> isn't negatively affected by your developing."
> Nils

More information about the devel mailing list