5:55 p.m.
On Wed, Mar 03, 2010 at 02:06:33PM -0800, Adam Williamson wrote:
On Wed, 2010-03-03 at 17:04 +0100, Till Maas wrote:
> I mind have misunderstood it, but afaics it only says that it will be
> tested, because it spent time in updates-testing, but this is not even
> true nowadays, even if packages stay long in updates-testing.
as we've explained several times, most packages that go to
updates-testing for a few days *are* being tested, even if they get no
apparent Bodhi feedback. Several QA group members run with
updates-testing enabled and so get all packages (that they have
installed) which go through updates-testing. They do not file positive
If it is limited on the packages the user is installed, a lot of
packages are not tested.
feedback for every single package because there's just too many,
but if
they notice breakage, they file negative feedback.
So here is a first ugly script to easily give feedback for all installed
testing updates that were created after a certain date (I did not find
an easy way to get all testing updates, one did not yet comment on):
http://till.fedorapeople.org/tmp/give-feedback.py
It kind of works like this: Show the update, ask for karma to create a
comment, otherwise it is skipped. Then a comment needs to be entered.
Sometimes it will ask for the FAS password using the bodhi client.
Update: rpmdevtools-7.8-1.fc12
Comment? -1/0/1 ->karma, other -> skip> 1
Comment> "rpmdev-newspec foo" still works
The prompt has readline support, so if you just want to use the same
comment again and again, you can use cursor-up to get the comment again.
Btw. the script fails in case only subpackages of a package are
installed. But if it is used, I will create a saner version.
Nevertheless, there is also now the Fedora Engineering Service, so if
you want to improve your testing tools, you might want to ask there.
So - for the third time - a package being in updates-testing for a
few
days and getting no negative feedback is a moderate strength indicator
that it's not egregiously broken. Not a super-strong indicator, but
better than a kick in the teeth.
It probably only means that the meta-data of the installed package is
not broken, but if they do not use all packages installed daily, then
there is not much test coverage.
Regards
Till
6:07 p.m.
On Thu, 2010-03-04 at 00:55 +0100, Till Maas wrote:
> So - for the third time - a package being in updates-testing for
a few
> days and getting no negative feedback is a moderate strength indicator
> that it's not egregiously broken. Not a super-strong indicator, but
> better than a kick in the teeth.
It probably only means that the meta-data of the installed package is
not broken, but if they do not use all packages installed daily, then
there is not much test coverage.
The types of breakage that most worry us are the ones where some update
causes really big and obvious problems that affect lots of people.
Happily, this is the kind of breakage you're most likely to get negative
feedback on when it happens. :)
So yes, the current process probably isn't very good at testing whether
a given update does absolutely everything it's supposed to do, in all
cases. It's not brilliant even at testing whether a given update works
at all, if that update is a fairly obscure package. What it _can_ do
reasonably well is catch the situation where an update mistakenly breaks
the world - where you install it and then suddenly you can't boot or
GNOME won't start or your network connection is broken or whatever. And
that's the kind of thing we're really trying to prevent.
I don't think a system where all updates had to stay in -testing for a
few days would catch all update problems. We'd still probably ship some
buggy updates. But hopefully we wouldn't again have the situation where
we're standing around scratching our heads and thinking 'how the *hell*
did that get shipped, when it breaks normal functionality for thousands
of people?'
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:32 p.m.
On Thu, Mar 04, 2010 at 12:55:46AM +0100, Till Maas wrote:
So here is a first ugly script to easily give feedback for all
installed
testing updates that were created after a certain date (I did not find
an easy way to get all testing updates, one did not yet comment on):
http://till.fedorapeople.org/tmp/give-feedback.py
It kind of works like this: Show the update, ask for karma to create a
comment, otherwise it is skipped. Then a comment needs to be entered.
Sometimes it will ask for the FAS password using the bodhi client.
Update: rpmdevtools-7.8-1.fc12
Comment? -1/0/1 ->karma, other -> skip> 1
Comment> "rpmdev-newspec foo" still works
The prompt has readline support, so if you just want to use the same
comment again and again, you can use cursor-up to get the comment again.
Btw. the script fails in case only subpackages of a package are
installed. But if it is used, I will create a saner version.
Nevertheless, there is also now the Fedora Engineering Service, so if
you want to improve your testing tools, you might want to ask there.
A less ugly script can now be found here:
http://till.fedorapeople.org/tmp/easy-karma.py
Improvements:
- display update details, e.g. bugs and notes
- use src.rpm to find matching update
- skip updates that have already been commented
With this giving karma is so simple, that there is no excuse for not
doing so. I'll add an git repo and clean it up more the next days.
Regards
Till
8:46 p.m.
On Thu, 2010-03-04 at 03:32 +0100, Till Maas wrote:
A less ugly script can now be found here:
http://till.fedorapeople.org/tmp/easy-karma.py
Improvements:
- display update details, e.g. bugs and notes
- use src.rpm to find matching update
- skip updates that have already been commented
With this giving karma is so simple, that there is no excuse for not
doing so. I'll add an git repo and clean it up more the next days.
This looks absolutely yummy, thank you Till! I'll play with it a bit and
promote it to the QA group.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:36 p.m.
On Thu, 2010-03-04 at 03:32 +0100, Till Maas wrote:
A less ugly script can now be found here:
http://till.fedorapeople.org/tmp/easy-karma.py
Improvements:
- display update details, e.g. bugs and notes
- use src.rpm to find matching update
- skip updates that have already been commented
With this giving karma is so simple, that there is no excuse for not
doing so. I'll add an git repo and clean it up more the next days.
completely awesome, just let me file a bunch of feedback I never would
have managed to get to before. great work, thank you.
small nit: if a single update has, say, three packages in it, the script
presents it for your feedback three times.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:41 p.m.
On Thu, 04 Mar 2010 03:32:13 +0100
Till Maas <opensource(a)till.name> wrote:
A less ugly script can now be found here:
http://till.fedorapeople.org/tmp/easy-karma.py
Improvements:
- display update details, e.g. bugs and notes
- use src.rpm to find matching update
- skip updates that have already been commented
With this giving karma is so simple, that there is no excuse for not
doing so. I'll add an git repo and clean it up more the next days.
Excellent.
I just added 11 bits of karma to various packages I have been using for
a while but never got around to tracking down to give karma to. ;)
Perhaps this could be added into fedora-packager?
Nice work.
kevin
12:23 a.m.
Till Maas <opensource(a)till.name> wrote:
> A less ugly script can now be found here:
> http://till.fedorapeople.org/tmp/easy-karma.py
> Improvements:
> - display update details, e.g. bugs and notes
> - use src.rpm to find matching update
> - skip updates that have already been commented
>
> With this giving karma is so simple, that there is no excuse for not
> doing so. I'll add an git repo and clean it up more the next days.
Till,
Great script here's a small set of changes to have easy-karma use yum as a module
instead of via subprocess.
http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
if I get a chance I'll see if I can figure out how to use the bodhi module
at the end so it doesn't have to use any subprocess calls at all.
thanks
-sv
4:02 a.m.
On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
Great script here's a small set of changes to have easy-karma use
yum as a module
instead of via subprocess.
http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
Thank you, I will integrate it later today, when I set up a git repo. Is
there a way to restrict the yum results using the time the packages were
installed?
if I get a chance I'll see if I can figure out how to use the
bodhi module
at the end so it doesn't have to use any subprocess calls at all.
This is pretty straight forward, I will do this later today, too.
Regards
Till
7:03 a.m.
On Thu, 4 Mar 2010, Till Maas wrote:
On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
> Great script here's a small set of changes to have easy-karma use yum as a
module
> instead of via subprocess.
>
> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
Thank you, I will integrate it later today, when I set up a git repo. Is
there a way to restrict the yum results using the time the packages were
installed?
I can't query based on it - but it's easy for comparison purposes to look
up the installed time from the package object.
the value is pkg_obj.installtime
it'll return the time in seconds
> if I get a chance I'll see if I can figure out how to use the
bodhi module
> at the end so it doesn't have to use any subprocess calls at all.
This is pretty straight forward, I will do this later today, too.
great.
-sv
7:59 a.m.
On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
Great script here's a small set of changes to have easy-karma use
yum as a module
instead of via subprocess.
http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
There is now a git repo and your patch is included:
http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=...
Regards
Till
9:26 a.m.
On Thu, 4 Mar 2010, Till Maas wrote:
On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
> Great script here's a small set of changes to have easy-karma use yum as a
module
> instead of via subprocess.
>
> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
There is now a git repo and your patch is included:
http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=...
Till,
you got a set of things you want to work on there? If there's a TODO I'll
see if I can take care of some of them for you.
-sv
10:32 a.m.
On Thu, Mar 04, 2010 at 10:26:17AM -0500, Seth Vidal wrote:
On Thu, 4 Mar 2010, Till Maas wrote:
> On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
>
>> Great script here's a small set of changes to have easy-karma use yum as a
module
>> instead of via subprocess.
>>
>> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
>
> There is now a git repo and your patch is included:
> http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=...
you got a set of things you want to work on there? If there's a
TODO I'll
see if I can take care of some of them for you.
Thanks, but for my personal use I do not miss anything currently, except
that it could be faster. But this only hits me, because I am running it
a lot to test it. But if you want, you can start creating a spec, so it
can be packaged. Another obvious TODO is to get bodhi_update_str()
included in the bodhi client in fedora-python.
But I have a simple question, is this save to do?
options.releasever = my.conf.yumvar["releasever"]
Regards
Till
10:34 a.m.
On Thu, 4 Mar 2010, Till Maas wrote:
On Thu, Mar 04, 2010 at 10:26:17AM -0500, Seth Vidal wrote:
>
>
> On Thu, 4 Mar 2010, Till Maas wrote:
>
>> On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
>>
>>> Great script here's a small set of changes to have easy-karma use yum as
a module
>>> instead of via subprocess.
>>>
>>> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
>>
>> There is now a git repo and your patch is included:
>> http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=...
> you got a set of things you want to work on there? If there's a TODO I'll
> see if I can take care of some of them for you.
Thanks, but for my personal use I do not miss anything currently, except
that it could be faster. But this only hits me, because I am running it
a lot to test it. But if you want, you can start creating a spec, so it
can be packaged. Another obvious TODO is to get bodhi_update_str()
included in the bodhi client in fedora-python.
Where is the module 'fedora_cert' packaged? I can't seem to find it.
But I have a simple question, is this save to do?
options.releasever = my.conf.yumvar["releasever"]
yes. it is. I actually just finished putting that in so RELEASE didn't
need to be defined. :)
-sv
6:15 p.m.
On Thu, Mar 04, 2010 at 05:32:11PM +0100, Till Maas wrote:
can be packaged. Another obvious TODO is to get bodhi_update_str()
included in the bodhi client in fedora-python.
I'll be happy to take that patch.
Looking like I'll be pushing out an updated python-fedora next week.
Depending on the timing of the packagedb update, I may push out another
python-fedora soon afterwards or hold off on the python-fedora update until
I can push it alongside the new pkgdb.
-Toshio
10:37 a.m.
On Thu, Mar 04, 2010 at 02:40:38PM +0100, Kevin Kofler wrote:
Kevin Fenzi wrote:
> Perhaps this could be added into fedora-packager?
Well, it's useful also for testers (or even just users) who are not
packagers, so I'm not sure that's the best place.
I am more in favor of packaging by its own, to make it easy to update
it, but it could be added to the fedora-packager comps group, iirc there
is one.
Regards
Till
9:28 a.m.
Till Maas (opensource(a)till.name) said:
A less ugly script can now be found here:
http://till.fedorapeople.org/tmp/easy-karma.py
Improvements:
- display update details, e.g. bugs and notes
- use src.rpm to find matching update
- skip updates that have already been commented
With this giving karma is so simple, that there is no excuse for not
doing so. I'll add an git repo and clean it up more the next days.
I haven't had a chance to play with this yet, but just from
reading the description - thanks for doing this, this is great.
Bill
5:26 a.m.
Here is now a review request for fedora-easy-karma:
https://bugzilla.redhat.com/show_bug.cgi?id=570771
3:47 p.m.
On Fri, 2010-03-05 at 22:21 +0100, Michael Schwendt wrote:
Interesting script. Nice idea, Till!
> Comment? -1/0/1 ->karma, other -> skip> 1
With defaults (no command-line args), it here prompted me to enter
the FAS password for "localhost". I had to use --fas-username=...
From a quick look at the code, it first tries to get the username from
your CVS certificate; if there isn't one it should use your account
username. Does seem like something broke a bit if it got 'localhost',
though :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4 p.m.
On Fri, Mar 05, 2010 at 10:21:37PM +0100, Michael Schwendt wrote:
With defaults (no command-line args), it here prompted me to enter
the FAS password for "localhost". I had to use --fas-username=...
These are the two commands that are used to get the username, what do
they return for you?
python -c "import fedora_cert; print fedora_cert.read_user_cert()"
python -c "import os; print os.getlogin()"
But it seems that os.getlogin() is too smart for this purposes, e.g. for me it always
uses
the username that started X, even if I "su -" or "sudo -i" into
another
account.
Regards
Till
5:03 p.m.
On Fri, 05 Mar 2010 23:00:12 +0100, Till wrote:
On Fri, Mar 05, 2010 at 10:21:37PM +0100, Michael Schwendt wrote:
> With defaults (no command-line args), it here prompted me to enter
> the FAS password for "localhost". I had to use --fas-username=...
These are the two commands that are used to get the username, what do
they return for you?
python -c "import fedora_cert; print fedora_cert.read_user_cert()"
Hah! This is an old Rawhide account with ~/.fedora*.cert files from
Nov 2007, which I used to evaluate a local koji instance.
10:42 p.m.
On 10-03-05 17:00:12, Till Maas wrote:
...
But it seems that os.getlogin() is too smart for this purposes, e.g.
for me it always uses the username that started X, even if I "su -"
or "sudo -i" into another account.
The Python docs[1] suggest using the environment variable LOGNAME.
[1] <http://docs.python.org/library/os.html#os.getlogin>
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
2:43 a.m.
On Fri, Mar 05, 2010 at 11:42:28PM -0500, Tony Nelson wrote:
On 10-03-05 17:00:12, Till Maas wrote:
...
> But it seems that os.getlogin() is too smart for this purposes, e.g.
> for me it always uses the username that started X, even if I "su -"
> or "sudo -i" into another account.
The Python docs[1] suggest using the environment variable LOGNAME.
[1] <http://docs.python.org/library/os.html#os.getlogin>
Thank you, it has been changed.
Regards
Till
5161
days inactive
5165
days old
25 comments
9 participants
participants (9)
-
Adam Williamson -
Bill Nottingham -
Kevin Fenzi -
Kevin Kofler -
Michael Schwendt -
Seth Vidal -
Till Maas -
Tony Nelson -
Toshio Kuratomi