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