FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-01-2010, 10:11 PM
Matthew Woehlke
 
Default Bodhi karma feature request

Doug Ledford wrote:
> One could argue that the current bodhi karma system is simply too
> simplistic for real use cases. Maybe instead of just +1 -1, there
> should be:
>
> Fixes my problem
> Works for me (someone testing that didn't necessarily have any of the
> problem supposedly fixed by this update just noting that their system
> still works ok with the update)
> Doesn't fix my problem (but doesn't necessarily imply it's any worse
> than before)
> Causes new problems (which should, IMO, be an automatic veto of any push
> to stable, requiring intervention to override)

I was thinking that negative karma really ought to count as -5 instead
of -1, but I like this suggestion a lot better. I'd vote for it (if I
could legally vote :-( ).

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Person A: It's an ISO standard.
Person B: ...And that means what?
-- mal (http://theangryadmin.blogspot.com/2008/04/future.html)

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 10:12 PM
Dominik 'Rathann' Mierzejewski
 
Default Bodhi karma feature request

On Monday, 01 March 2010 at 23:34, Doug Ledford wrote:
[...]
> One could argue that the current bodhi karma system is simply too
> simplistic for real use cases.

There's nothing to argue. It's rather obvious.

> Maybe instead of just +1 -1, there should be:
>
> Fixes my problem
> Works for me (someone testing that didn't necessarily have any of the
> problem supposedly fixed by this update just noting that their system
> still works ok with the update)
> Doesn't fix my problem (but doesn't necessarily imply it's any worse
> than before)
> Causes new problems (which should, IMO, be an automatic veto of any push
> to stable, requiring intervention to override)

Great choices. This covers all bases, I think.

> I could see situations where you would want to push updates to stable if
> say the update was supposed to solve multiple bugs, but turns out it
> only solves a subset of those bugs and doesn't cause new ones, so you
> would have some FMP, maybe some WFM, some DFMP, but no CNP. You'd
> probably just need to leave it up to the maintainer to decided if the
> bugs that are solved are important enough to push to stable before
> respinning another attempt at the ones that weren't solved.

This is an excellent idea, and big improvement over current purely numeric
karma system in bodhi. +1 to implementing that.

Regards,
R.

--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 10:16 PM
Jesse Keating
 
Default Bodhi karma feature request

On Mon, 2010-03-01 at 17:34 -0500, Doug Ledford wrote:
>
> One could argue that the current bodhi karma system is simply too
> simplistic for real use cases. Maybe instead of just +1 -1, there
> should be:
>
> Fixes my problem
> Works for me (someone testing that didn't necessarily have any of the
> problem supposedly fixed by this update just noting that their system
> still works ok with the update)
> Doesn't fix my problem (but doesn't necessarily imply it's any worse
> than before)
> Causes new problems (which should, IMO, be an automatic veto of any push
> to stable, requiring intervention to override)

I agree that this is good data to have, and that karma right now is
pretty simplistic (which was it's goal). Simplistic karma is far better
than what we had before, which was nothing.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 10:27 PM
Nicolas Mailhot
 
Default Bodhi karma feature request

Le lundi 01 mars 2010 à 15:16 -0800, Jesse Keating a écrit :
> On Mon, 2010-03-01 at 17:34 -0500, Doug Ledford wrote:
> >
> > One could argue that the current bodhi karma system is simply too
> > simplistic for real use cases. Maybe instead of just +1 -1, there
> > should be:
> >
> > Fixes my problem
> > Works for me (someone testing that didn't necessarily have any of the
> > problem supposedly fixed by this update just noting that their system
> > still works ok with the update)
> > Doesn't fix my problem (but doesn't necessarily imply it's any worse
> > than before)
> > Causes new problems (which should, IMO, be an automatic veto of any push
> > to stable, requiring intervention to override)
>
> I agree that this is good data to have, and that karma right now is
> pretty simplistic (which was it's goal). Simplistic karma is far better
> than what we had before, which was nothing.

With enough data points one can print pretty graphes that show vote
repartition¹. Those are harder to skew than averages. However, they
require many data points and bohdi is far from that today

¹ For example, the bargraphs on
http://www.animenewsnetwork.com/encyclopedia/anime.php?id=840
http://www.animenewsnetwork.com/encyclopedia/anime.php?id=2276

(amazon uses a simpler system)

--
Nicolas Mailhot
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 02:23 AM
Björn Persson
 
Default Bodhi karma feature request

Doug Ledford wrote:
> Split off from the stable pushes in Bodhi thread just because I'd like
> to see it not get lost.

(For your information, you didn't split it off. Your message is marked as a
reply to the one by "Mail Lists" and is displayed in my Kmail as part of
Kevin's enormous thread.)

> One could argue that the current bodhi karma system is simply too
> simplistic for real use cases. Maybe instead of just +1 -1, there
> should be:
>
> Fixes my problem
> Works for me (someone testing that didn't necessarily have any of the
> problem supposedly fixed by this update just noting that their system
> still works ok with the update)
> Doesn't fix my problem (but doesn't necessarily imply it's any worse
> than before)
> Causes new problems (which should, IMO, be an automatic veto of any push
> to stable, requiring intervention to override)

That sounds really good, although I would call the second one "still works for
me" to emphasize that it's for people for whom the previous release also
worked.

Björn Persson
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 06:51 AM
Adam Williamson
 
Default Bodhi karma feature request

On Tue, 2010-03-02 at 00:27 +0100, Nicolas Mailhot wrote:

> With enough data points one can print pretty graphes that show vote
> repartition¹. Those are harder to skew than averages. However, they
> require many data points and bohdi is far from that today
>
> ¹ For example, the bargraphs on
> http://www.animenewsnetwork.com/encyclopedia/anime.php?id=840
> http://www.animenewsnetwork.com/encyclopedia/anime.php?id=2276

I knew one day the anime fandom / fedora development crossover would
happen!

Now, who's going to write the stickster / kakashi slash fic?

(oh good lord, I am NOT going to be able to sleep tonight with that idea
in my head...)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 06:51 AM
Adam Williamson
 
Default Bodhi karma feature request

On Mon, 2010-03-01 at 17:34 -0500, Doug Ledford wrote:

> One could argue that the current bodhi karma system is simply too
> simplistic for real use cases. Maybe instead of just +1 -1, there
> should be:
>
> Fixes my problem
> Works for me (someone testing that didn't necessarily have any of the
> problem supposedly fixed by this update just noting that their system
> still works ok with the update)
> Doesn't fix my problem (but doesn't necessarily imply it's any worse
> than before)
> Causes new problems (which should, IMO, be an automatic veto of any push
> to stable, requiring intervention to override)
>
> I could see situations where you would want to push updates to stable if
> say the update was supposed to solve multiple bugs, but turns out it
> only solves a subset of those bugs and doesn't cause new ones, so you
> would have some FMP, maybe some WFM, some DFMP, but no CNP. You'd
> probably just need to leave it up to the maintainer to decided if the
> bugs that are solved are important enough to push to stable before
> respinning another attempt at the ones that weren't solved.
>
> I've personally seen situations where this would be helpful with the
> mdadm package when I had 5 or 6 bugs on a single update and only 4 of
> them were actually solved. The update was still worth pushing while I
> worked on the others again.
>
> If you really wanted to get fancy, the FMP/DFMP options could be tied to
> specific bugzillas reported against the update, and if you get a FMP for
> each bugzilla listed in the update, plus at least 1 WFM, then you could
> automatically push to stable. Would be much better than the 3 random
> +1s you get now that don't indicate anything about test coverage or
> anything like that. Also FMP/DFMP karma against a bug could be noted
> both in the bodhi ticket as well as in the bug itself with a resultant
> VERIFIED/FAILS_QA toggle to the bug status.

FMP + WFM


--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 08:09 AM
Kevin Kofler
 
Default Bodhi karma feature request

Björn Persson wrote:
> That sounds really good, although I would call the second one "still works
> for me" to emphasize that it's for people for whom the previous release
> also worked.

Right.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 08:09 AM
Panu Matilainen
 
Default Bodhi karma feature request

On Mon, 1 Mar 2010, Doug Ledford wrote:
>
> One could argue that the current bodhi karma system is simply too
> simplistic for real use cases. Maybe instead of just +1 -1, there
> should be:
>
> Fixes my problem
> Works for me (someone testing that didn't necessarily have any of the
> problem supposedly fixed by this update just noting that their system
> still works ok with the update)
> Doesn't fix my problem (but doesn't necessarily imply it's any worse
> than before)
> Causes new problems (which should, IMO, be an automatic veto of any push
> to stable, requiring intervention to override)

Oh yes. Even just a big red REGRESSION button that stops the update from
automatically entering stable no matter what the karma votes happen to be
would be a definite improvement. And the other data points would certainly
be useful if/when an update happens to get comments.

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 08:13 AM
Kevin Kofler
 
Default Bodhi karma feature request

Doug Ledford wrote:
> Fixes my problem
> Works for me (someone testing that didn't necessarily have any of the
> problem supposedly fixed by this update just noting that their system
> still works ok with the update)
> Doesn't fix my problem (but doesn't necessarily imply it's any worse
> than before)
> Causes new problems

Yes, this makes more sense than just +1 and -1.

> (which should, IMO, be an automatic veto of any push to stable, requiring
> intervention to override)

But no, please no! While it should definitely prevent an automatic push if
the maintainer enabled that, it should not keep the maintainer from pushing
anyway. I've seen way too many invalid accusations of updates causing new
problems, which actually turned out to be various types of false alarms,
e.g. issues caused by another update or even hardware, issues with a
previous testing update already fixed in the edited one being commented on,
"problems" which aren't actually bugs, but intentional changes (e.g. the old
behavior was the bug) etc.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org