Good news everyone,
you can probably expect to receive more positive bodhi karma for your updates in the future (or you already got unexpected much), because there is now a script called 'fedora-easy-karma'[0], that makes providing feedback a lot easier.
This makes it more important to consider the "karma automatism" for your updates. By default testing updates updates are declared stable when they get three karma points. In the past this probably never happened, but now I have seen several updates, where this occurred. So if you think your package should stay longer in testing or needs more intensive testing than the average updates, consider disabling the "karma automatism" or select a higher threshold for the automatic push to happen.
Regards Till
On 6.3.2010 23:21, Till Maas wrote:
Good news everyone,
you can probably expect to receive more positive bodhi karma for your updates in the future (or you already got unexpected much), because there is now a script called 'fedora-easy-karma'[0], that makes providing feedback a lot easier.
Till, great job, thank you!
Also thanks for packaging that immediately -- what about installing it by default? It's a tiny package and we really do want our users to provide feedback.
Best, Milos
On Sun, Mar 07, 2010 at 01:29:28AM +0100, Milos Jakubicek wrote:
Also thanks for packaging that immediately -- what about installing it by default? It's a tiny package and we really do want our users to provide feedback.
I do not mind, if it is installed by default, but I am not sure, whether this is a good idea. Users will still need a FAS account, install packages from updates-testing and know that it exist to use it.
Regards Till
Till Maas (opensource@till.name) said:
Also thanks for packaging that immediately -- what about installing it by default? It's a tiny package and we really do want our users to provide feedback.
I do not mind, if it is installed by default, but I am not sure, whether this is a good idea. Users will still need a FAS account, install packages from updates-testing and know that it exist to use it.
Given that it at the moment requires a FAS account, perhaps having it as default in the Fedora packager group is a good first step.
Hey, why don't we register for FAS accounts with firstboot?
Bill
Bill Nottingham wrote:
Till Maas (opensource@till.name) said:
Also thanks for packaging that immediately -- what about installing it by default? It's a tiny package and we really do want our users to provide feedback.
I do not mind, if it is installed by default, but I am not sure, whether this is a good idea. Users will still need a FAS account, install packages from updates-testing and know that it exist to use it.
Given that it at the moment requires a FAS account, perhaps having it as default in the Fedora packager group is a good first step.
Hey, why don't we register for FAS accounts with firstboot?
Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?)
On 03/11/2010 02:14 AM, Matthew Woehlke wrote:
Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?)
What is the problem you have with the CLA?
Rahul
Rahul Sundaram wrote:
On 03/11/2010 02:14 AM, Matthew Woehlke wrote:
Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?)
What is the problem you have with the CLA?
I tried to send you a reply, but it bounced; gmail says the address you gave does not exist.
Rahul Sundaram wrote:
On 03/11/2010 11:00 PM, Matthew Woehlke wrote:
I tried to send you a reply, but it bounced; gmail says the address you gave does not exist.
I got the mail. Thanks.
Yes, sorry. Must not have read the bounce close enough; I was trying to forward a copy to myself (different account) and got *my* address wrong :-).
On Thu, Mar 11, 2010 at 09:20:11AM +0530, Rahul Sundaram wrote:
On 03/11/2010 02:14 AM, Matthew Woehlke wrote:
Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?)
What is the problem you have with the CLA?
Imho it is to complex, which scares potential contributor away. Especially if only a comment and a karma value are required, the CLA is way to complex to require it.
Regards Till
On Thu, 11 Mar 2010, Till Maas wrote:
On Thu, Mar 11, 2010 at 09:20:11AM +0530, Rahul Sundaram wrote:
On 03/11/2010 02:14 AM, Matthew Woehlke wrote:
Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?)
What is the problem you have with the CLA?
Imho it is to complex, which scares potential contributor away. Especially if only a comment and a karma value are required, the CLA is way to complex to require it.
We don't require it though I thought? Can somone who has not signed the CLA confirm?
-Mike
On Wed, Mar 10, 2010 at 7:36 PM, Bill Nottingham notting@redhat.com wrote:
Till Maas (opensource@till.name) said:
Also thanks for packaging that immediately -- what about installing it by default? It's a tiny package and we really do want our users to provide feedback.
I do not mind, if it is installed by default, but I am not sure, whether this is a good idea. Users will still need a FAS account, install packages from updates-testing and know that it exist to use it.
Given that it at the moment requires a FAS account, perhaps having it as default in the Fedora packager group is a good first step.
Hey, why don't we register for FAS accounts with firstboot?
Good idea. We could also register FAS accounts within the Fedora-Tour once it's ready. I think it would be a good place with lots of space to explain the user what benefits a FAS account has.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/06/2010 05:21 PM, Till Maas wrote:
Good news everyone,
you can probably expect to receive more positive bodhi karma for your updates in the future (or you already got unexpected much), because there is now a script called 'fedora-easy-karma'[0], that makes providing feedback a lot easier.
This makes it more important to consider the "karma automatism" for your updates. By default testing updates updates are declared stable when they get three karma points. In the past this probably never happened, but now I have seen several updates, where this occurred. So if you think your package should stay longer in testing or needs more intensive testing than the average updates, consider disabling the "karma automatism" or select a higher threshold for the automatic push to happen.
Regards Till
Given the obvious utility of this script, can we get it added to the fedora-packager package? It doesn't make a lot of sense to have developers downloading a script off a wiki to use this.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Am Dienstag, den 09.03.2010, 07:50 -0500 schrieb Stephen Gallagher:
On 03/06/2010 05:21 PM, Till Maas wrote:
Given the obvious utility of this script, can we get it added to the fedora-packager package? It doesn't make a lot of sense to have developers downloading a script off a wiki to use this.
This is already in its own package: https://admin.fedoraproject.org/updates/search/fedora-easy-karma
On Tue, 2010-03-09 at 14:06 +0100, Thomas Spura wrote:
Am Dienstag, den 09.03.2010, 07:50 -0500 schrieb Stephen Gallagher:
On 03/06/2010 05:21 PM, Till Maas wrote:
Given the obvious utility of this script, can we get it added to the fedora-packager package? It doesn't make a lot of sense to have developers downloading a script off a wiki to use this.
This is already in its own package: https://admin.fedoraproject.org/updates/search/fedora-easy-karma
Should this script still work if you mirror the updates-testing path and use your local disk for upgrades? Cause that is what I do and it don't do nothing for me.
[mike@scrappy Downloads]$ ./fedora-easy-karma.py Adding en_US to language list [mike@scrappy Downloads]$
NO menus, or anything. And this only updating partially, or everything from updates-testing.
On Tue, Mar 09, 2010 at 03:42:19PM -0600, Mike Chambers wrote:
On Tue, 2010-03-09 at 14:06 +0100, Thomas Spura wrote:
Am Dienstag, den 09.03.2010, 07:50 -0500 schrieb Stephen Gallagher:
On 03/06/2010 05:21 PM, Till Maas wrote:
Given the obvious utility of this script, can we get it added to the fedora-packager package? It doesn't make a lot of sense to have developers downloading a script off a wiki to use this.
This is already in its own package: https://admin.fedoraproject.org/updates/search/fedora-easy-karma
Should this script still work if you mirror the updates-testing path and use your local disk for upgrades? Cause that is what I do and it don't do nothing for me.
How do you update? Do you use yum or rpm? yum with localupdate?
[mike@scrappy Downloads]$ ./fedora-easy-karma.py Adding en_US to language list [mike@scrappy Downloads]$
NO menus, or anything. And this only updating partially, or everything from updates-testing.
You need to update packages from updates-testing first and then it's useful to run it. Please look at the wiki for example output.
Regards Till
On Tue, 9 Mar 2010, Till Maas wrote:
On Tue, Mar 09, 2010 at 03:42:19PM -0600, Mike Chambers wrote:
On Tue, 2010-03-09 at 14:06 +0100, Thomas Spura wrote:
Am Dienstag, den 09.03.2010, 07:50 -0500 schrieb Stephen Gallagher:
On 03/06/2010 05:21 PM, Till Maas wrote:
Given the obvious utility of this script, can we get it added to the fedora-packager package? It doesn't make a lot of sense to have developers downloading a script off a wiki to use this.
This is already in its own package: https://admin.fedoraproject.org/updates/search/fedora-easy-karma
Should this script still work if you mirror the updates-testing path and use your local disk for upgrades? Cause that is what I do and it don't do nothing for me.
How do you update? Do you use yum or rpm? yum with localupdate?
If you know which pkgs you've installed that were from updates-testing you can run:
yumdb set from_repo updates-testing pkg_name
and that should do it.
-sv
On Tue, 2010-03-09 at 17:19 -0500, Seth Vidal wrote:
If you know which pkgs you've installed that were from updates-testing you can run:
yumdb set from_repo updates-testing pkg_name
and that should do it.
Yes, that fixed it. So the name has to be "updates-testing" in the repo for it to work. Guess I can see how that would be the case, unless it checked the packages and compared to the repo on the internet or something, but that would take way too long.
On Tue, Mar 09, 2010 at 04:51:52PM -0600, Michael Cronenworth wrote:
Till Maas wrote:
You need to update packages from updates-testing first and then it's useful to run it. Please look at the wiki for example output.
Would your script break, say, if he was using the bodhi-client from updates-testing that is broken?
fedora-easy-karma does not use bodhi-client, but fedora-python, which contains a python module for bodhi, that is also used by the bodhi-client script.
Regards Till
On Tue, Mar 09, 2010 at 07:50:43AM -0500, Stephen Gallagher wrote:
Given the obvious utility of this script, can we get it added to the fedora-packager package? It doesn't make a lot of sense to have developers downloading a script off a wiki to use this.
It's (going to be) in the fedora-packager comps group, so yum install @fedora-packager should install it iirc (after the next comps to repo sync, if it's not working yet).
Regards Till
On Sat, Mar 6, 2010 at 3:21 PM, Till Maas opensource@till.name wrote:
Good news everyone,
you can probably expect to receive more positive bodhi karma for your updates in the future (or you already got unexpected much), because there is now a script called 'fedora-easy-karma'[0], that makes providing feedback a lot easier.
This makes it more important to consider the "karma automatism" for your updates. By default testing updates updates are declared stable when they get three karma points. In the past this probably never happened, but now I have seen several updates, where this occurred. So if you think your package should stay longer in testing or needs more intensive testing than the average updates, consider disabling the "karma automatism" or select a higher threshold for the automatic push to happen.
Regards Till
Thankyou very much Till. I started using it this morning and it seems to work as expected. There are a couple of things that would make it easier to use:
1) Comments could allow for multi-line code. I tried to paste stuff in and well skipped a couple of packages from the paste :) 2) I found so many packages I didn't know were on my system so had no idea what they were. A) is the package linked to things I use daily? [can this be determined.] B) is the package been used by something so I can see its usage by other daemons. In the end, I did remove a couple of things I was like "huh why did I install that?"
On Wed, Mar 10, 2010 at 09:34:15AM -0700, Stephen John Smoogen wrote:
- Comments could allow for multi-line code. I tried to paste stuff in
and well skipped a couple of packages from the paste :)
Do you have any wish about how this should behave? I was thinking that e.g. a comment like "<EOF" will make it multiline and use everything until a comment that's only EOF will be used. EOF can be an arbitrary string.
- I found so many packages I didn't know were on my system so had no
idea what they were. A) is the package linked to things I use daily? [can this be determined.]
I don't know how to determine this except to scan your .bash_history and use rpm -qf to find matches packages.
B) is the package been used by something so I can see its usage by other daemons.
So you would like to have a list of all packages that are depending on this directly or indirectly? For a future release I was thinking about to use a more interactive shell that allows to also perform some additional query commands. Maybe this could be one of them.
Regards Till
On Wed, Mar 10, 2010 at 4:27 PM, Till Maas opensource@till.name wrote:
On Wed, Mar 10, 2010 at 09:34:15AM -0700, Stephen John Smoogen wrote:
- Comments could allow for multi-line code. I tried to paste stuff in
and well skipped a couple of packages from the paste :)
Do you have any wish about how this should behave? I was thinking that e.g. a comment like "<EOF" will make it multiline and use everything until a comment that's only EOF will be used. EOF can be an arbitrary string.
That works for me.
- I found so many packages I didn't know were on my system so had no
idea what they were. A) is the package linked to things I use daily? [can this be determined.]
I don't know how to determine this except to scan your .bash_history and use rpm -qf to find matches packages.
Yeah.. this would require a more massive database than I think is in the scope of packages. This sort of big brother would basically track what is run, by what and when. It would then present stuff so that a user could see what they are using the most.
However, in some cases, I would just like to know:
poppler-glib: used by evince, gimp.
That way I can say.. oh I used evince since the update.. and its working so I have not had a problem.
B) is the package been used by something so I can see its usage by other daemons.
So you would like to have a list of all packages that are depending on this directly or indirectly? For a future release I was thinking about to use a more interactive shell that allows to also perform some additional query commands. Maybe this could be one of them.
The biggest query command I would like at the moment is something like:
fedora-easy-karma --list # lists packages to be voted on. fedora-easy-karma --list-new # list pacakges I haven't voted on already.
I removed a couple hundred packages from my system today because I am not suing them and even just hitting return to go past them was taking a long time.
On Wed, Mar 10, 2010 at 04:51:34PM -0700, Stephen John Smoogen wrote:
The biggest query command I would like at the moment is something like:
fedora-easy-karma --list # lists packages to be voted on. fedora-easy-karma --list-new # list pacakges I haven't voted on already.
fedora-easy-karma by default already skips updates, that you already commented on, this can be disabled with "--include-commented". So would it be enough, if there is an option "--list-only", that skips the questions whether or not to comment, but only displays the update descriptions?
Regards Till
On Thu, Mar 11, 2010 at 2:07 AM, Till Maas opensource@till.name wrote:
On Wed, Mar 10, 2010 at 04:51:34PM -0700, Stephen John Smoogen wrote:
The biggest query command I would like at the moment is something like:
fedora-easy-karma --list # lists packages to be voted on. fedora-easy-karma --list-new # list pacakges I haven't voted on already.
fedora-easy-karma by default already skips updates, that you already commented on, this can be disabled with "--include-commented". So would it be enough, if there is an option "--list-only", that skips the questions whether or not to comment, but only displays the update descriptions?
What I am looking for is something where I can get a short list of packages I would be asked to comment on if I ran the program. The reason being that I removed a couple hundred packages yesterday because I don't run them, haven't run them, and probably wouldn't know how to test them :).
Additionally, I have some RFE's too. ;)
- Could you add a 'q' for quit or something. Or at least not catch control-c? If I am in the middle of doing something and need to reboot or wander off, I would perfer to be able to just stop.
- Perhaps also a 'n' and 'p' for next and previous ? If I am looking at them quickly, I sometimes hit a return when I should have stopped and tested something. The only way to go back is to get to the end and restart and find the update I passed.
- Perhaps add a "(FEK)" or something to the comments? It would then be more obvious how many people are using this tool?
Again, great work on this... thanks!
kevin
On Thu, Mar 11, 2010 at 01:22:35PM -0700, Kevin Fenzi wrote:
Additionally, I have some RFE's too. ;)
- Could you add a 'q' for quit or something. Or at least not catch control-c? If I am in the middle of doing something and need to reboot or wander off, I would perfer to be able to just stop.
Uh, I catching CTRL-C is not intended, I'll look into this the next days. But you can use CTRL-D to quit.
- Perhaps also a 'n' and 'p' for next and previous ? If I am looking at them quickly, I sometimes hit a return when I should have stopped and tested something. The only way to go back is to get to the end and restart and find the update I passed.
Yes, this is annoying, I'll add this to TODO. In the meantime: In the git repo there is a version that accepts patterns to select an update, so you can just append the full name (no v-r) of a build to select only it or use shell pattern, e.g. gstreamer* to only get updates that include a build or rpm matching this patterin.
- Perhaps add a "(FEK)" or something to the comments? It would then be more obvious how many people are using this tool?
The git version will set it's own http user agent so people with access to the server logs can create some usage statistics. But I could also add this, if nobody objects.
Regards Till