Re: submitters +1ing their own packages
On Tue, 2011-09-13 at 13:22 +0200, Nils Philippsen wrote: > > That's only a default, though; you can lower it to 1 when you submit the > > update. Also, once a critpath update hits the required threshold - +1 > > from a proventester, +1 from anyone else (PT or no) - you can manually > > push it to stable, whatever auto-push threshold you set. > > Well, I never really understood why we're able to lower the stable karma > threshold. To me that's much more "gaming the system" than a maintainer > +1ing his update after testing it (with the default threshold). The thresholds are as defined in the updates policy: +1 for non-critpath, +1/+1 for critpath. The auto-push trigger is entirely a function of convenience for maintainers. As long as it doesn't let you effectively reduce the policy-defined thresholds, which it doesn't, I don't see a problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 09/13/2011 01:22 PM, Nils Philippsen wrote: > On Mon, 2011-09-12 at 15:22 -0700, Adam Williamson wrote: >> On Mon, 2011-09-12 at 17:56 +0200, Nils Philippsen wrote: >> 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. >>> >>> We have a default of +3 karma for automatic pushes to stable, so a +1 >>> from the maintainer by itself isn't enough to push an update to stable >>> already. >> >> That's only a default, though; you can lower it to 1 when you submit the >> update. Also, once a critpath update hits the required threshold - +1 >> from a proventester, +1 from anyone else (PT or no) - you can manually >> push it to stable, whatever auto-push threshold you set. > > Well, I never really understood why we're able to lower the stable karma > threshold. To me that's much more "gaming the system" than a maintainer > +1ing his update after testing it (with the default threshold). > > Nils It might be because people are waiting ages for +1 on some packages. If I had to wait for +3, then I don't have to create update at all. Usually I get one karma from bug reporter and that's it. -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Mon, 2011-09-12 at 15:22 -0700, Adam Williamson wrote: > On Mon, 2011-09-12 at 17:56 +0200, Nils Philippsen wrote: > > > > 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. > > > > We have a default of +3 karma for automatic pushes to stable, so a +1 > > from the maintainer by itself isn't enough to push an update to stable > > already. > > That's only a default, though; you can lower it to 1 when you submit the > update. Also, once a critpath update hits the required threshold - +1 > from a proventester, +1 from anyone else (PT or no) - you can manually > push it to stable, whatever auto-push threshold you set. Well, I never really understood why we're able to lower the stable karma threshold. To me that's much more "gaming the system" than a maintainer +1ing his update after testing it (with the default threshold). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Mon, 2011-09-12 at 17:56 +0200, Nils Philippsen wrote: > > 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. > > We have a default of +3 karma for automatic pushes to stable, so a +1 > from the maintainer by itself isn't enough to push an update to stable > already. That's only a default, though; you can lower it to 1 when you submit the update. Also, once a critpath update hits the required threshold - +1 from a proventester, +1 from anyone else (PT or no) - you can manually push it to stable, whatever auto-push threshold you set. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Fri, 2011-09-09 at 12:22 +0200, Vít Ondruch wrote:
> Sorry, you are mixing two things:
>
> 1) One is testing environment and it can be probably well defined,
> clean, etc.
And thus incomparable to real-life environments. Mind, I'm not arguing
against some testing (e.g. automated regression tests, AutoQA) being
done in defined environments. But I doubt that it's enough if all
testing is done under these conditions, because this implicates we need
to define, and test against, all (or at least the majority of)
environments under which our software could be run, which frankly is
unrealistic. Therefore I'd rather have people also test in their
"naturally grown" environments to better cover real life situations that
deviate from defaults.
> 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.
This is quite condescending, and a straw man to boot. Testing a piece of
software in the way we do it is on no way comparable to reviewing
patches: In the one case I'd be using the software _like any other user
or tester_, try out some functionality, partly related to what was
intended to be fixed, partly a few basic functionality ("smoke") tests,
in the other case I'd be looking at code changes which I worked on for
let's say the last few hours or even days. I grant you that the latter
case invites say a less skeptical approach than is warranted when
reviewing patches, but it's also much harder to do and much less well
defined (thus much easier to trick yourself into biased behavior) than
the former: with testing it's clear what you have to do (to a maintainer
or developer possibly even more than John Random Tester) and it's clear
how results should be interpreted. Either it does what it's supposed to
do, or it doesn't. If it doesn't, and it did before, it's a regression.
If I can describe to a tester how something should be tested, I can test
it myself.
> 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).
And that's wrong either way how I look at it: If I submit an update only
after I've done testing in the way I described above, I've wasted
precious time in which others could have tested as well. If submitting
an update would automatically imply that level of testing, I couldn't
submit updates for Fedora releases which I don't use.
When I submit an update it usually means that I've tried out the code
(not necessarily the package, probably rather from a checked out source
tree), checked it against bugs supposed to be fixed and done minimal
smoke tests. Nothing more.
> 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.
We have a default of +3 karma for automatic pushes to stable, so a +1
from the maintainer by itself isn't enough to push an update to stable
already. Non-critical-path updates can be pushed to stable within 7 days
of them having been pushed to testing, without any karma at all, which
seems a much lower hurdle if I wanted to dump broken software onto
people.
> BTW no policy can stop some "evil maintainer" who will create other
> Fedora accounts and give karma to his packages under different
> identities.
And that's supposed to mean... what?
> You can even add karma without Fedora identity, but I am not sure if
> that counts.
It doesn't.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Fri, 2011-09-09 at 07:06 -0400, Josh Boyer wrote: > On Fri, Sep 9, 2011 at 4:13 AM, Nils Philippsen wrote: > > 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 meant that it should be implied that the package maintainer already > did some amount of testing on the package before they submitted it as > an update. A basic minimum touch test that it doesn't break things, > etc. This is entirely outside the updates process and just common > sense good practice. And this is just what you get when I submit an update, but don't confuse that with a +1 karma -- I'll only give that to actual packages which I have tested on a live system. In reverse, most times only updates for the distro I've running at the moment will get this, unless I bother to fire up a different VM for testing. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Fri, Sep 9, 2011 at 4:13 AM, Nils Philippsen wrote: > 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 meant that it should be implied that the package maintainer already did some amount of testing on the package before they submitted it as an update. A basic minimum touch test that it doesn't break things, etc. This is entirely outside the updates process and just common sense good practice. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
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. Vit 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
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 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 22:21 +0200, Till Maas wrote: > On Thu, Sep 08, 2011 at 03:33:33PM -0400, David Malcolm wrote: > > > package for a while. If I'm happy with my subsequent testing, then I'll > > +1 my own update, on the grounds that I've been viewing the change from > > a testing perspective, rather than just from a development perspective. > > If not, I'll -1 it. > ^^^ > > Why won't you unpush your update if it fails your testing? > Good point, but hasn't happened so far, IIRC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 22:18 +0200, Till Maas wrote: > It is easy to go in circles if everyone is using "+1" with a different > meaning. If you read carefully what I quoted you will notice that I > quoted a proposal to allow +1 comments only from submitters for non > critpath updates. If we use your meaning of "+1 comments from > submitters" this means that the proposal is to add an audit trail only > for non critpath updates. I am pretty sure that you do not mean this. > > So your proposal is probably to allow +1 comments from submitters, but > do not use it to calculate the karma value of an update. But this is a > technical detail. Even with allowing a direct push to stable instead of > using a complex karma calculation formula you will have an audit trail > in Bodhi, because Bodhi creates a comment about this as well. And you > can as well revoke the direct-push-to-stabe direct-push-to-stabe feature > from misbehaving maintainers. That's true, though we still lose the wrinkle that an explicit +1 from a maintainer is a clear statement that "I have actually tested this code". A direct submission to stable is not such a statement, though we could write up the policy in such a way that it was assumed to be one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 03:33:33PM -0400, David Malcolm wrote: > package for a while. If I'm happy with my subsequent testing, then I'll > +1 my own update, on the grounds that I've been viewing the change from > a testing perspective, rather than just from a development perspective. > If not, I'll -1 it. ^^^ Why won't you unpush your update if it fails your testing? Regards Till pgpogs0bGMBF4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 12:34:25PM -0700, Adam Williamson wrote: > On Thu, 2011-09-08 at 20:59 +0200, Till Maas wrote: > > On Thu, Sep 08, 2011 at 06:42:56PM +, "Jóhann B. Guðmundsson" wrote: > > > > > 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 a +1 from a maintainer is counted for the stable update threshold > > than the policy could just be changed to allow maintainers to push > > updates directly to stable. Because this is what will be possible, only > > that a lot of stupid interaction with Bodhi will be required. But it > > would fit the current policy that does not state clearly that any update > > submitter is allowed to push a non critpath update to stable as soon as > > the update received at least one +1 from anyone. > > We're going round in circles again, as I know I've written this at least > twice in the previous threads on the topic, but: no. What Bodhi adds to > the process is accountability, an audit trail, and an easy way to manage > privileges. If we keep the Bodhi thresholds but allow maintainers to +1 > their own updates, it makes it very very easy to look at a hyopthetical > future problematic update and say 'look, you +1ed this update which was > clearly broken, it went out, and caused pain to users: your +1 > privileges are revoked', and actually do that, without affecting other > maintainers who are following the rules. If we just let everyone push > straight to stable, we lose that. It is easy to go in circles if everyone is using "+1" with a different meaning. If you read carefully what I quoted you will notice that I quoted a proposal to allow +1 comments only from submitters for non critpath updates. If we use your meaning of "+1 comments from submitters" this means that the proposal is to add an audit trail only for non critpath updates. I am pretty sure that you do not mean this. So your proposal is probably to allow +1 comments from submitters, but do not use it to calculate the karma value of an update. But this is a technical detail. Even with allowing a direct push to stable instead of using a complex karma calculation formula you will have an audit trail in Bodhi, because Bodhi creates a comment about this as well. And you can as well revoke the direct-push-to-stabe direct-push-to-stabe feature from misbehaving maintainers. Kind regards Till pgpGL1PRC2yCx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 20:59 +0200, Till Maas wrote: > On Thu, Sep 08, 2011 at 06:42:56PM +, "Jóhann B. Guðmundsson" wrote: > > > 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 a +1 from a maintainer is counted for the stable update threshold > than the policy could just be changed to allow maintainers to push > updates directly to stable. Because this is what will be possible, only > that a lot of stupid interaction with Bodhi will be required. But it > would fit the current policy that does not state clearly that any update > submitter is allowed to push a non critpath update to stable as soon as > the update received at least one +1 from anyone. We're going round in circles again, as I know I've written this at least twice in the previous threads on the topic, but: no. What Bodhi adds to the process is accountability, an audit trail, and an easy way to manage privileges. If we keep the Bodhi thresholds but allow maintainers to +1 their own updates, it makes it very very easy to look at a hyopthetical future problematic update and say 'look, you +1ed this update which was clearly broken, it went out, and caused pain to users: your +1 privileges are revoked', and actually do that, without affecting other maintainers who are following the rules. If we just let everyone push straight to stable, we lose that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: > On 7 September 2011 01:02, Adam Williamson wrote: > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > case-by-case enforcement of this policy? > > I'm guilty of this too; when I file an update that's not getting > enough karma (after a few weeks) then I give it a spin in a *fresh* VM > and test it out like any normal user would do. If this is wrong, > consider my wrists slapped, but otherwise I think it makes sense and > gets things moving. FWIW, I wasn't aware of the policy of not +1-ing my own updates. My approach here (for python/python3) has been that if the patch looks sane and passes the selftest suite, then I'll apply it and create the update. I've then been doing additional testing e.g. dogfooding the package for a while. If I'm happy with my subsequent testing, then I'll +1 my own update, on the grounds that I've been viewing the change from a testing perspective, rather than just from a development perspective. If not, I'll -1 it. I don't feel guilty about doing this additional testing and reporting. [See also http://dmalcolm.livejournal.com/5013.html for more notes on ways of improving QA of Bodhi candidate updates] Hope this is helpful Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 18:42 +, "Jóhann B. Guðmundsson" wrote: > 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... I think that's again in the 'makes theoretical sense but not practical sense' category. The updates we have the most trouble with are critpath updates on N-1 (F14 at present), precisely *because* of the relatively tight karma requirements. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 06:42:56PM +, "Jóhann B. Guðmundsson" wrote: > 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 a +1 from a maintainer is counted for the stable update threshold than the policy could just be changed to allow maintainers to push updates directly to stable. Because this is what will be possible, only that a lot of stupid interaction with Bodhi will be required. But it would fit the current policy that does not state clearly that any update submitter is allowed to push a non critpath update to stable as soon as the update received at least one +1 from anyone. Kind regards Till pgppT3x7WMkGg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 08:30:24PM +0200, Pierre-Yves Chibon wrote: > Might be worth adding a flash() to inform why the karma wasn't added. Done: https://fedorahosted.org/bodhi/attachment/ticket/277/0001-model.py-Change-karma-from-Submitter-to-0.2.patch Kind regards Till pgpHXAZilkoL0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
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. Kind regards Till pgpUPb2i1sxtC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 20:16 +0200, Till Maas wrote: > > > It's not being enforced in bodhi, but it should be: > > > > https://fedorahosted.org/bodhi/ticket/277 > > It is somehow sad that nobody took the time to write a two line patch > to > fix this 3 year old bug report: > > https://fedorahosted.org/bodhi/attachment/ticket/277/0001-model.py-Change-karma-from-Submitter-to-0.patch > Might be worth adding a flash() to inform why the karma wasn't added. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 08:46:50PM -0600, Kevin Fenzi wrote: > It's not being enforced in bodhi, but it should be: > > https://fedorahosted.org/bodhi/ticket/277 It is somehow sad that nobody took the time to write a two line patch to fix this 3 year old bug report: https://fedorahosted.org/bodhi/attachment/ticket/277/0001-model.py-Change-karma-from-Submitter-to-0.patch Kind Regards Till pgpCY45xN8DEk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 8, 2011 at 11:54 AM, Nils Philippsen wrote: > I think we should define what a "vanilla environment" is then. One could > argue that either of the following could be described as "vanilla": One thing I done in lieu of a full VM is to test CLI programs under mock. Of course this is a minimal system. I've even tested GUI programs in mock using Xnest. It doesn't give you the native kernel (and probably several other packages) but it also lets you test programs in other releases and 32bit/64bit environments. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote: > > - A system in good condition (packages verify well, no dupes) that's > > used normally, i.e. what you would see being used by normal persons > > without any fancy hacks in configuration, or worse, non-config files > > owned by packages. Pro: Easy to test as you don't need to do anything > > fancy, just yum --enablerepo=updates-testing update ; > > Neither one of those definitions addresses the large variety of > configurations that are possible with vanilla Fedora packages. E.g. > your update might work wonderfully running a default Gnome desktop > install, but crash portions of the KDE or XFCE stack (for cases of > underlying desktop infrastructure). > > 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 Neither do I, but then, we don't require wide-spread user based testing in a variety of environments: we require, in the strictest case, exactly two tests. > 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. I still think there's a significant difference between "I made the same change in my private git branch, built it locally, fired it up and it worked" (or "I made the same change in my private git branch, and it built"...) and "I installed the package from koji / updates-testing on my reasonably sane Fedora 16 installation and it worked". -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 16:43 +0200, Johannes Lips wrote: > Hi, > > I think a major problem of the current update policy is, that regular > users don't see if there are new package updates in updates-testing, > unless they enable it and I doubt many regular users do this. > > So we might think about spreading the word, when a new update of a > software package is available in updates-testing. I don't know how we > could achieve this. Perhaps an idea which I had earlier might be to > start a page or service where you could "like" various packages and > you'll get notifications if there is something happening with that > package. Perhaps https://admin.fedoraproject.org/community/ could be a > starting point for this idea. > Perhaps we could collect other ideas on this but I think if we make the > update process more public we will get more testers for sure. Bodhi already automatically notifies any bugs that an update is marked as fixing when that update is pushed into -testing, complete with instructions on how to update to the -testing package, and we (QA) have https://fedoraproject.org/wiki/QA/Join linking to https://fedoraproject.org/wiki/QA/Updates_Testing and https://fedoraproject.org/wiki/Proven_tester . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 8, 2011 at 12:54 PM, Nils Philippsen wrote: > On Wed, 2011-09-07 at 18:02 -0700, Adam Williamson wrote: >> On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: >> > * As a maintainer it's easy to have a env that gets out of sync with >> > what a QA or end user would use. Ie, you make 20 iterations of a >> > package to test something, tweak configs to check something, and get >> > it all working, but perhaps your machine is no longer setup the way a >> > fresh install or upgrade of your package would be. Or you tested a >> > version and then changed just 'one little thing' and pushed that and >> > it turned out to break it. >> >> Both hughsie and myself, and I think everyone else in favour of >> maintainer +1s, suggested maintainers should test *in a vanilla >> environment*, with the actual package they were submitting, before >> +1ing. +1ing on the basis of a test build or in a dirty environment >> would be a no-no and could lead to the removal of +1 privileges if >> repeated. > > I think we should define what a "vanilla environment" is then. One could > argue that either of the following could be described as "vanilla": > > - A fresh system without any modifications or unstable updates other > than that being tested. Pro: makes testing comparable. Contra: You > essentially need a special VM for testing which needs to be installed > freshly for each tested update. Makes tests comparable ;-), i.e. reduces > the amount of different environments in which an update is tested. I do > actually want testing to be done on systems that aren't just "minimal > install plus updates plus a user beside root". > > - A system in good condition (packages verify well, no dupes) that's > used normally, i.e. what you would see being used by normal persons > without any fancy hacks in configuration, or worse, non-config files > owned by packages. Pro: Easy to test as you don't need to do anything > fancy, just yum --enablerepo=updates-testing update ; Neither one of those definitions addresses the large variety of configurations that are possible with vanilla Fedora packages. E.g. your update might work wonderfully running a default Gnome desktop install, but crash portions of the KDE or XFCE stack (for cases of underlying desktop infrastructure). 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. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:02 -0700, Adam Williamson wrote: > On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: > > * As a maintainer it's easy to have a env that gets out of sync with > > what a QA or end user would use. Ie, you make 20 iterations of a > > package to test something, tweak configs to check something, and get > > it all working, but perhaps your machine is no longer setup the way a > > fresh install or upgrade of your package would be. Or you tested a > > version and then changed just 'one little thing' and pushed that and > > it turned out to break it. > > Both hughsie and myself, and I think everyone else in favour of > maintainer +1s, suggested maintainers should test *in a vanilla > environment*, with the actual package they were submitting, before > +1ing. +1ing on the basis of a test build or in a dirty environment > would be a no-no and could lead to the removal of +1 privileges if > repeated. I think we should define what a "vanilla environment" is then. One could argue that either of the following could be described as "vanilla": - A fresh system without any modifications or unstable updates other than that being tested. Pro: makes testing comparable. Contra: You essentially need a special VM for testing which needs to be installed freshly for each tested update. Makes tests comparable ;-), i.e. reduces the amount of different environments in which an update is tested. I do actually want testing to be done on systems that aren't just "minimal install plus updates plus a user beside root". - A system in good condition (packages verify well, no dupes) that's used normally, i.e. what you would see being used by normal persons without any fancy hacks in configuration, or worse, non-config files owned by packages. Pro: Easy to test as you don't need to do anything fancy, just yum --enablerepo=updates-testing update ; I'm also guilty of +1ing my updates, but only for Fedora releases where I actually tested the updated package(s). And my system is "in good condition" as per what I described above, I keep code to be tested in separate hierarchies, usually in subdirectories in my home. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Sep 7, 2011, at 7:13 PM, Andre Robatino wrote: > > My opinion is that packagers should be allowed to > +1 their own packages after a certain delay (1 week, maybe?) if it hasn't > gotten > sufficient karma from others by then, and they do actual testing in a > non-custom > environment (for example, maintain a VM with close to default settings). I think this is an unnecessary delay. Either we trust the packager's testing ability, and his karma is valuable, or we don't and the user doesn't have the ability to add karma (exactly how is /that/ going to be programmed, I have no idea). The week delay doesn't really add anything beneficial here at all. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 07:17:35AM -0700, Christopher Aillon wrote: > On 09/07/2011 05:47 PM, Kevin Fenzi wrote: > > > As someone on the other side of this (although not strongly, I could > > be convinced), I don't think thats my concern at all... > > > > * As a maintainer you should only be pushing an update you feel > >works/fixes something anyhow. Shouldn't that be an implied +1 always > >from the maintainer? > > Except that some maintainers build packages and submit them without > testing them at all. > I do this when a bugfix is worthy enough to push to multiple releases but I only test on a subset of those releases. That the bug has been fixed is pretty much tested by testing on a single release. That the fix does not have side-effects on releases other than I'm using is only tested by the people who run updates-testing on those other releases. > I submit that we should be encouraging maintainers to test their builds, > not discouraging it (which turning off selfkarma would do). > +1 > If the current rule is based on the fact that we would like 3 people to > test besides the maintainer, we could just bump the autokarma thresshold > from 3 to 4, and additionally encourage the maintainer to test. > Actually, we're only requiring 2 in the strictest case: (Critpath in stable release): # At the time of the request to stable, the update needs to have a Bodhi karma sum of 2 AND # One of these positive karma points needs to be from a Proventester (All other packages) (list is not exhaustive): # reach the positive Bodhi karma threshold specified by the updates submitter http://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path.27_packages I agree with you that if the idea is to get X people beyond the maintainer, bumping the autokarma so that it is X+1 makes sense. [snip other good points to which I have nothing to add] -Toshio pgpV78PoS0hnm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
Another wrinkle I'm not sure has been discussed (in this thread anyway)... What if a new package is built in response to a bug report? If you add the BZ number when you do your updates then of course anyone following the bug gets cc'd and can try the testing package. It can often be difficult getting users to report back success (failure usually get's pretty quick feedback :) much less getting them to go add karma to the package. Could the policy be updated to allow a maintainer +1'ing an update if they reference the comment in the bug which reported a successful fix? +1 by proxy? :) Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
Hi, I think a major problem of the current update policy is, that regular users don't see if there are new package updates in updates-testing, unless they enable it and I doubt many regular users do this. So we might think about spreading the word, when a new update of a software package is available in updates-testing. I don't know how we could achieve this. Perhaps an idea which I had earlier might be to start a page or service where you could "like" various packages and you'll get notifications if there is something happening with that package. Perhaps https://admin.fedoraproject.org/community/ could be a starting point for this idea. Perhaps we could collect other ideas on this but I think if we make the update process more public we will get more testers for sure. Johannes On 09/08/2011 02:47 AM, Kevin Fenzi wrote: > On Wed, 07 Sep 2011 12:15:56 -0700 > Adam Williamson wrote: > >> On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: >>> On 7 September 2011 01:02, Adam Williamson >>> wrote: Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? >>> >>> I'm guilty of this too; when I file an update that's not getting >>> enough karma (after a few weeks) then I give it a spin in a *fresh* >>> VM and test it out like any normal user would do. If this is wrong, >>> consider my wrists slapped, but otherwise I think it makes sense and >>> gets things moving. >> >> It's against the current policy. I've argued along the same lines as >> you in past threads on this list, but I was on the minority side of >> the debate at the time, it seemed; more people were worried that >> maintainers would +1 their updates without bothering to test them >> properly. > > As someone on the other side of this (although not strongly, I could > be convinced), I don't think thats my concern at all... > > * As a maintainer you should only be pushing an update you feel >works/fixes something anyhow. Shouldn't that be an implied +1 always >from the maintainer? > > * As a maintainer it's easy to have a env that gets out of sync with >what a QA or end user would use. Ie, you make 20 iterations of a >package to test something, tweak configs to check something, and get >it all working, but perhaps your machine is no longer setup the way a >fresh install or upgrade of your package would be. Or you tested a >version and then changed just 'one little thing' and pushed that and >it turned out to break it. > > * Even the best of us would like another pair of eyes to confirm >something is really fixed/working. > > anyhow, just thought I would toss that out there... > > kevin > > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 09/07/2011 05:47 PM, Kevin Fenzi wrote: > As someone on the other side of this (although not strongly, I could > be convinced), I don't think thats my concern at all... > > * As a maintainer you should only be pushing an update you feel >works/fixes something anyhow. Shouldn't that be an implied +1 always >from the maintainer? Except that some maintainers build packages and submit them without testing them at all. I submit that we should be encouraging maintainers to test their builds, not discouraging it (which turning off selfkarma would do). If the current rule is based on the fact that we would like 3 people to test besides the maintainer, we could just bump the autokarma thresshold from 3 to 4, and additionally encourage the maintainer to test. > * As a maintainer it's easy to have a env that gets out of sync with >what a QA or end user would use. Ie, you make 20 iterations of a >package to test something, tweak configs to check something, and get >it all working, but perhaps your machine is no longer setup the way a >fresh install or upgrade of your package would be. Or you tested a >version and then changed just 'one little thing' and pushed that and >it turned out to break it. It's also fairly easy, if not easier, as a tester to get out of sync with what an end user would use since you're likely to be installing broken stuff on your system which could have residual effects. > * Even the best of us would like another pair of eyes to confirm >something is really fixed/working. Yes, but we also should encourage the maintainer to confirm this too. Many past bugs could have been avoided had the maintainer tested and noticed that the fix didn't quite work the way it should have. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 8 September 2011 03:13, Andre Robatino wrote: > If a packager repeatedly submits +1 for updates which turn out later couldn't > possibly have worked in actual testing, then their karma privileges could be > revoked. Makes sense to me. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
submitters +1ing their own packages
Kevin Fenzi scrye.com> writes: > * As a maintainer you should only be pushing an update you feel > works/fixes something anyhow. Shouldn't that be an implied +1 always > from the maintainer? Well, there's actual testing, vs. being convinced based on the apparent simplicity of a patch that it doesn't need to be tested. I've seen a number of non-working "fixes" that obviously fell into the second category, given that they failed in a 100% reproducible, environment-independent way, and would have only taken a minute or two to actually test. > * As a maintainer it's easy to have a env that gets out of sync with > what a QA or end user would use. Ie, you make 20 iterations of a > package to test something, tweak configs to check something, and get > it all working, but perhaps your machine is no longer setup the way a > fresh install or upgrade of your package would be. Or you tested a > version and then changed just 'one little thing' and pushed that and > it turned out to break it. > > * Even the best of us would like another pair of eyes to confirm > something is really fixed/working. Obviously packagers may have more trouble doing objective testing than outsiders, but it's possible. My opinion is that packagers should be allowed to +1 their own packages after a certain delay (1 week, maybe?) if it hasn't gotten sufficient karma from others by then, and they do actual testing in a non-custom environment (for example, maintain a VM with close to default settings). If a packager repeatedly submits +1 for updates which turn out later couldn't possibly have worked in actual testing, then their karma privileges could be revoked. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: > On Wed, 07 Sep 2011 12:15:56 -0700 > Adam Williamson wrote: > > > On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: > > > On 7 September 2011 01:02, Adam Williamson > > > wrote: > > > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > > > case-by-case enforcement of this policy? > > > > > > I'm guilty of this too; when I file an update that's not getting > > > enough karma (after a few weeks) then I give it a spin in a *fresh* > > > VM and test it out like any normal user would do. If this is wrong, > > > consider my wrists slapped, but otherwise I think it makes sense and > > > gets things moving. > > > > It's against the current policy. I've argued along the same lines as > > you in past threads on this list, but I was on the minority side of > > the debate at the time, it seemed; more people were worried that > > maintainers would +1 their updates without bothering to test them > > properly. > > As someone on the other side of this (although not strongly, I could > be convinced), I don't think thats my concern at all... > > * As a maintainer you should only be pushing an update you feel > works/fixes something anyhow. Shouldn't that be an implied +1 always > from the maintainer? I've probably responded to those before, but oh well: this is a bit of a 'physics experiment land' point, for me. In theory? Sure. In practice? Not really. We have this system because maintainers *do* push updates which don't work, after all. Sometimes they 'don't work' in a way the maintainer wouldn't have been able to catch, but often they 'don't work' in a way the maintainer really should have caught if they'd tested the package: viz, say, glibc -6, which prevented all systems from booting properly. I know *I've* submitted updates on spec, or with very minor testing, occasionally, and I'm a QA person. =) > * As a maintainer it's easy to have a env that gets out of sync with > what a QA or end user would use. Ie, you make 20 iterations of a > package to test something, tweak configs to check something, and get > it all working, but perhaps your machine is no longer setup the way a > fresh install or upgrade of your package would be. Or you tested a > version and then changed just 'one little thing' and pushed that and > it turned out to break it. Both hughsie and myself, and I think everyone else in favour of maintainer +1s, suggested maintainers should test *in a vanilla environment*, with the actual package they were submitting, before +1ing. +1ing on the basis of a test build or in a dirty environment would be a no-no and could lead to the removal of +1 privileges if repeated. > * Even the best of us would like another pair of eyes to confirm > something is really fixed/working. Yes, indeed, in a perfect world. But it seems quite plain that, so far, the bodhi system is working pretty well but not perfectly, and we may have to take pragmatic changes to our beautiful, beautiful Physics Experiment Land model (where there's no friction, and there are always 100 proventesters running Fedora 14...) in order to keep everything flowing smoothly. > anyhow, just thought I would toss that out there... > > kevin -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 07 Sep 2011 12:15:56 -0700 Adam Williamson wrote: > On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: > > On 7 September 2011 01:02, Adam Williamson > > wrote: > > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > > case-by-case enforcement of this policy? > > > > I'm guilty of this too; when I file an update that's not getting > > enough karma (after a few weeks) then I give it a spin in a *fresh* > > VM and test it out like any normal user would do. If this is wrong, > > consider my wrists slapped, but otherwise I think it makes sense and > > gets things moving. > > It's against the current policy. I've argued along the same lines as > you in past threads on this list, but I was on the minority side of > the debate at the time, it seemed; more people were worried that > maintainers would +1 their updates without bothering to test them > properly. As someone on the other side of this (although not strongly, I could be convinced), I don't think thats my concern at all... * As a maintainer you should only be pushing an update you feel works/fixes something anyhow. Shouldn't that be an implied +1 always from the maintainer? * As a maintainer it's easy to have a env that gets out of sync with what a QA or end user would use. Ie, you make 20 iterations of a package to test something, tweak configs to check something, and get it all working, but perhaps your machine is no longer setup the way a fresh install or upgrade of your package would be. Or you tested a version and then changed just 'one little thing' and pushed that and it turned out to break it. * Even the best of us would like another pair of eyes to confirm something is really fixed/working. anyhow, just thought I would toss that out there... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, Sep 07, 2011 at 07:20:19PM +0200, Michael Schwendt wrote: > On Wed, 7 Sep 2011 11:00:57 +1000, PH (Peter) wrote: > > > sometimes a +1 after weeks in testing is the only or at least easy way to > > nudge a package into stable. > > > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > > even with my +1 still not there, and this isn't the only package I've done > > this for. > > | Details > |Don't corrupt memory if the server sends unknown classes in > XIQueryDevice. > > # rpm -qi libXi|grep -A2 ^De > Description : > X.Org X11 libXi runtime library > > # rpm -qd libXi > /usr/share/doc/libXi-1.4.3/COPYING > > # rpm -ql libXi > /usr/lib64/libXi.so.6 > /usr/lib64/libXi.so.6.1.0 > /usr/share/doc/libXi-1.4.3 > /usr/share/doc/libXi-1.4.3/COPYING > > No bug ticket number either. > Your own +1 in bodhi is without a comment. > Assuming I wanted to test this, what would I do? ok, fair call, should've created a bug for this. This bug is triggered with new features added in the next X server version (that's not even upstream). Corruption happens when the XIQueryDevice reply includes input classes that are not recognised by Xlib. You can't trigger this bug without having the right git trees, but you can verify that the fix doesn't break anything by running "xinput list" or pretty much any application that uses XI2. fwiw, the reason I pushed this in now is because I didn't want anyone to have that library still around when the X server patches hit rawhide. plus, there's the odd chance that proprietary extensions can trigger this, though I don't think any of these exist. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: > On 7 September 2011 01:02, Adam Williamson wrote: > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > case-by-case enforcement of this policy? > > I'm guilty of this too; when I file an update that's not getting > enough karma (after a few weeks) then I give it a spin in a *fresh* VM > and test it out like any normal user would do. If this is wrong, > consider my wrists slapped, but otherwise I think it makes sense and > gets things moving. It's against the current policy. I've argued along the same lines as you in past threads on this list, but I was on the minority side of the debate at the time, it seemed; more people were worried that maintainers would +1 their updates without bothering to test them properly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 7 September 2011 01:02, Adam Williamson wrote: > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > case-by-case enforcement of this policy? I'm guilty of this too; when I file an update that's not getting enough karma (after a few weeks) then I give it a spin in a *fresh* VM and test it out like any normal user would do. If this is wrong, consider my wrists slapped, but otherwise I think it makes sense and gets things moving. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 7 Sep 2011 11:00:57 +1000, PH (Peter) wrote: > sometimes a +1 after weeks in testing is the only or at least easy way to > nudge a package into stable. > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > even with my +1 still not there, and this isn't the only package I've done > this for. | Details |Don't corrupt memory if the server sends unknown classes in XIQueryDevice. # rpm -qi libXi|grep -A2 ^De Description : X.Org X11 libXi runtime library # rpm -qd libXi /usr/share/doc/libXi-1.4.3/COPYING # rpm -ql libXi /usr/lib64/libXi.so.6 /usr/lib64/libXi.so.6.1.0 /usr/share/doc/libXi-1.4.3 /usr/share/doc/libXi-1.4.3/COPYING No bug ticket number either. Your own +1 in bodhi is without a comment. Assuming I wanted to test this, what would I do? -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc4.git0.0.fc16.x86_64 loadavg: 0.17 0.06 0.06 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, Sep 07, 2011 at 01:38:09PM +1000, Peter Hutterer wrote: > On Tue, Sep 06, 2011 at 07:38:53PM -0700, Adam Williamson wrote: > > > plus a trac ticket. Whether it has some practical effect or not, it's > > clearly against the current policy, and what I'm questioning is whether > > Bodhi should be enforcing that policy automatically. > > my argument is that even though it's against official policy, it can be > useful in some cases. The current voluntary compliance is imo a good > solution since it can be circumvented when needed. I'm definitely not > advocating doing this for every update. > Then the current policy needs to be modified to show that this is appropriate. Otherwise there are people who follow the rules and are disgruntled that other people are able to get away with not following them. One aspect of policy should be to give people an understanding of how to coexist with one another. If the rules don't apply equally (even if that means "The rules apply to those who feel the need to follow them and don't apply to those who do not feel the need to do so") then the common understanding is broken. Getting the policy updated so that people know that there are cases where you can +1 your own update is a better way to build community than just letting people who feel okay about doing so circumvent the policy when they see fit. -Toshio pgpovBnPZs3TJ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 07:38:53PM -0700, Adam Williamson wrote: > On Wed, 2011-09-07 at 11:00 +1000, Peter Hutterer wrote: > > On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: > > > I've mentioned before that I actually support this, but I'm in the > > > minority, and AFAIK the current policy is supposed to be that > > > maintainers cannot upkarma updates they submitted themselves. However, > > > this seems to be happening - exhibit a): > > > > > > https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 > > > > > > karma is listed as 1, the only positive feedback shown as I write this > > > is from kengert, who submitted the update. > > > > > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > > case-by-case enforcement of this policy? > > > > sometimes a +1 after weeks in testing is the only or at least easy way to > > nudge a package into stable. > > > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > > even with my +1 still not there, and this isn't the only package I've done > > this for. > > Please don't turn this into another 'I'm not getting enough testing on > my old critpath package' thread. We already have about five of those, that wasn't my intent. > plus a trac ticket. Whether it has some practical effect or not, it's > clearly against the current policy, and what I'm questioning is whether > Bodhi should be enforcing that policy automatically. my argument is that even though it's against official policy, it can be useful in some cases. The current voluntary compliance is imo a good solution since it can be circumvented when needed. I'm definitely not advocating doing this for every update. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, 06 Sep 2011 17:02:25 -0700 Adam Williamson wrote: > I've mentioned before that I actually support this, but I'm in the > minority, and AFAIK the current policy is supposed to be that > maintainers cannot upkarma updates they submitted themselves. However, > this seems to be happening - exhibit a): > > https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 > > karma is listed as 1, the only positive feedback shown as I write this > is from kengert, who submitted the update. > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > case-by-case enforcement of this policy? It's not being enforced in bodhi, but it should be: https://fedorahosted.org/bodhi/ticket/277 Hopefully that will be implemented soon. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 11:00 +1000, Peter Hutterer wrote: > On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: > > I've mentioned before that I actually support this, but I'm in the > > minority, and AFAIK the current policy is supposed to be that > > maintainers cannot upkarma updates they submitted themselves. However, > > this seems to be happening - exhibit a): > > > > https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 > > > > karma is listed as 1, the only positive feedback shown as I write this > > is from kengert, who submitted the update. > > > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > case-by-case enforcement of this policy? > > sometimes a +1 after weeks in testing is the only or at least easy way to > nudge a package into stable. > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > even with my +1 still not there, and this isn't the only package I've done > this for. Please don't turn this into another 'I'm not getting enough testing on my old critpath package' thread. We already have about five of those, plus a trac ticket. Whether it has some practical effect or not, it's clearly against the current policy, and what I'm questioning is whether Bodhi should be enforcing that policy automatically. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 08:09:03PM -0500, Richard Shaw wrote: > On Tue, Sep 6, 2011 at 8:00 PM, Peter Hutterer > wrote: > > On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: > >> I've mentioned before that I actually support this, but I'm in the > >> minority, and AFAIK the current policy is supposed to be that > >> maintainers cannot upkarma updates they submitted themselves. However, > >> this seems to be happening - exhibit a): > >> > >> https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 > >> > >> karma is listed as 1, the only positive feedback shown as I write this > >> is from kengert, who submitted the update. > >> > >> Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > >> case-by-case enforcement of this policy? > > > > sometimes a +1 after weeks in testing is the only or at least easy way to > > nudge a package into stable. > > > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > > even with my +1 still not there, and this isn't the only package I've done > > this for. > > Do you mean if you don't want to wait for a week in testing? Or is > you're package not aging out for some reason? I do it once the old_testing emails start getting too annoying. With the exception of evtest, I think all the packages I own are critical path so even after that timeout I can't push without proventester ack. in a few cases, I had provenpackager +1 but no other tester and we seem to need both (?) to get it to stable. Cheers, Peter > I own several (new) packages that are not really used yet (building > blocks for other packages) and I didn't feel right about +1 my own > packages so I just end up leaving them in testing until they can be > pushed to stable... > > Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 6, 2011 at 8:00 PM, Peter Hutterer wrote: > On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: >> I've mentioned before that I actually support this, but I'm in the >> minority, and AFAIK the current policy is supposed to be that >> maintainers cannot upkarma updates they submitted themselves. However, >> this seems to be happening - exhibit a): >> >> https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 >> >> karma is listed as 1, the only positive feedback shown as I write this >> is from kengert, who submitted the update. >> >> Is this a Bodhi bug? Or does FESCo expect voluntary compliance / >> case-by-case enforcement of this policy? > > sometimes a +1 after weeks in testing is the only or at least easy way to > nudge a package into stable. > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > even with my +1 still not there, and this isn't the only package I've done > this for. Do you mean if you don't want to wait for a week in testing? Or is you're package not aging out for some reason? I own several (new) packages that are not really used yet (building blocks for other packages) and I didn't feel right about +1 my own packages so I just end up leaving them in testing until they can be pushed to stable... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: > I've mentioned before that I actually support this, but I'm in the > minority, and AFAIK the current policy is supposed to be that > maintainers cannot upkarma updates they submitted themselves. However, > this seems to be happening - exhibit a): > > https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 > > karma is listed as 1, the only positive feedback shown as I write this > is from kengert, who submitted the update. > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > case-by-case enforcement of this policy? sometimes a +1 after weeks in testing is the only or at least easy way to nudge a package into stable. e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 even with my +1 still not there, and this isn't the only package I've done this for. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
submitters +1ing their own packages
I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
