Re: 182 pending F11 stable updates. WTF?

["Jóhann B. Guðmundsson" <johannbg@xxxxx>]

On 05/07/2009 10:23 PM, Jeff Spaleta wrote:

2009/5/7 "Jóhann B. Guðmundsson" <johannbg@xxxxx>:
  

Hum so for all the 1100+ packages that come with the default ( dvd ) install
hum mentioning the dvd is not really far so I shall just mention the 182
updates waiting!

You want a notification that nags you all day long..
    

you misread... i said give me a list of 5 out of the hundreds and nag
me to drop a comment about one of them. have the 5 differ on each
notification attempt. Once I drop at least one comment..it stops
nagging me for the day.  At no point did i say his is something
everyone would want. But I know my work patterns and I know I need
help taking the pile of testing updates and turning them into
bite-sized chunks of information. Really its not that much different
than twitter alerts from people interrupting my UI...except instead of
messages from people i know..its messages about packages I've
installed.
  

Ok so let's leave notification rainbow and pony's out of it
and brainstorm a little..

let's say we have an Bodhi client in Gnome ( gtk ) or
Bodhi client ( plasma ) applet in KDE or better yet a Bodhi
plugin in packagekit or kpackagekit that you could just vote
immediately after you receive the updates from updates-testing.

That application would have the thumps up thumps down on the update
along with a comment field and perhaps username and a password field
depending if we want all or just fas user vote.

We cant have maintainer flag an component in updates-testing which would show up on
application as a component that needs testing.

It goes without saying all maintainers would flag their component hence you end up with everything flagged
anyway. 

So each updated would always ask you for a thumb up, thumb down..

Hum randomly notify just a 5 or 10 components will not work messy algorithms that need to be come up with
to deal with various issues like updates chain effect ( updates keep piling up and you would need to keep track of which one had already sent notification  ) etc..

This could perhaps be solved with an ignore/silent or hide button that would hide component until the user mark it "show"
basically the user selects components which he wants to vote on.

Now this application would need to have the ability to exclude some package from requiring voting hum but then again
if they need exclusion then the argument can be made that they simply don't need to be in updates-testing anyway..

We would still be faced with the problem of not knowing what to test and
i'm not foreseeing that improving given some maintainers changelog track records
Along with nobody likes paperwork...
( this is a bit of nugget on the process already  )

Skeptical that this might work sound more like a "Great on  paper crap on field" idea

The biggest obstacle we are facing as I see it is getting the" how and what to test" to the user.

/me throws the thinking ball into the air..

-- 
Viking-Ice 

One of my gods has a hammer your's was nailed to a cross
You do the math!

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list