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 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 Fri, 2011-09-09 at 07:06 -0400, Josh Boyer wrote: On Fri, Sep 9, 2011 at 4:13 AM, Nils Philippsen n...@redhat.com 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, 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 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
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 Fri, Sep 9, 2011 at 4:13 AM, Nils Philippsen n...@redhat.com 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
On 8 September 2011 03:13, Andre Robatino robat...@fedoraproject.org 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
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
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 Williamsonawill...@redhat.com wrote: On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: On 7 September 2011 01:02, Adam Williamsonawill...@redhat.com 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 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 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 pkg; use pkg 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 Thu, Sep 8, 2011 at 12:54 PM, Nils Philippsen n...@redhat.com 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 pkg; use pkg 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 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, 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 pkg; use pkg 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, Sep 8, 2011 at 11:54 AM, Nils Philippsen n...@redhat.com 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 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, 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 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 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 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 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, 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 Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: On 7 September 2011 01:02, Adam Williamson awill...@redhat.com 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 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 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, 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, 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, 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 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 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 7 September 2011 01:02, Adam Williamson awill...@redhat.com 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, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: On 7 September 2011 01:02, Adam Williamson awill...@redhat.com 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 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, 07 Sep 2011 12:15:56 -0700 Adam Williamson awill...@redhat.com wrote: On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: On 7 September 2011 01:02, Adam Williamson awill...@redhat.com 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, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: On Wed, 07 Sep 2011 12:15:56 -0700 Adam Williamson awill...@redhat.com wrote: On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: On 7 September 2011 01:02, Adam Williamson awill...@redhat.com 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 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
Re: submitters +1ing their own packages
On Tue, Sep 6, 2011 at 8:00 PM, Peter Hutterer peter.hutte...@who-t.net 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 08:09:03PM -0500, Richard Shaw wrote: On Tue, Sep 6, 2011 at 8:00 PM, Peter Hutterer peter.hutte...@who-t.net 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 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, 06 Sep 2011 17:02:25 -0700 Adam Williamson awill...@redhat.com 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 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
