Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

Scott Doty scott at ponzo.net
Thu Sep 2 19:09:43 UTC 2010


  On 09/02/2010 11:16 AM, Adam Williamson wrote:
>
> There's no guarantee the bug will get closed even if the problem is
> fixed, unless someone else has the same hardware as you and is testing.
> A fix may come down from upstream without being recognized specifically
> as a fix for this particular Fedora bug report - a lot of stuff comes
> down from upstream, and there's no guarantee the kernel team will match
> up every upstream change to Fedora bug reports without assistance from
> testers.

How difficult would it be for BZ to implement some kind of 
"federations"?  Though some projects don't use BZ for bug tracking, I'd 
hope there would be willingness on maintainers of all bug tracking 
software to agree on a protocol for updating each other.

Simply put, imagine if Alice finds a bug at company X.  She files a bug 
report on her company BZ server.

Whoever is handling in-house development sees the bug, sees that it will 
need an upstream fix, and kicks it upstream.  Alternately, she may fix 
the bug, and could kick _that_ upstream, too.

If the fix is made upstream, that info would get passed down to the 
sub-federated servers that subscribe to that component.

Finally -- and this could be postponed until "Version 2" ;) -- each 
component in each distro has it's own newsgroup in a private news 
hierarchy.  This way, if Bob User wants to track the discussion & work 
on a component, he can go read the newsgroup and see all the discussion 
going on.

That's a few rough ideas.  But it seems like a win to use known, tried, 
and true telecommunications protocols to pass discussion traffic around 
-- expecially if Bob User could use an nnrp client to participate in 
said discussion!

Anyway, I could say more -- but I've probably already shown how bananas 
my ideas can be.

Happy Thursday! :)

  -Scott



More information about the test mailing list