submitters +1ing their own packages
vondruch at redhat.com
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,
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
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."
More information about the devel