Re: Patch policy

[Jonathan Larmour <jifl@eCosCentric.com>]

Jonathan Larmour wrote:
> 
> I'd suggest not using bugzilla actually. I've already been thinking 
> about this problem and there are well established patch managers out 
> there. In particular I'm thinking of what is on savannah.gnu.org, e.g.: 
> http://savannah.gnu.org/patch/?group=inetutils

I was talking to Alex, and he has persuaded me now that bugzilla is a good 
solution after all! The problems I had with it were primarily due to there 
not being a good mapping between bug states and patch states.

But it turns out that the Bugzilla folks have now thought of that. The 
primary way to sort this out is using flags, like:

http://bugzilla.mozilla.org/flag-help.html

With flags, the mozilla folks sensibly use bugzilla for patch review.

Alex also pointed out that with Bugzilla, it means that all patches are in 
one place - both patches that we say close bugs, and new patches. This 
means people looking for patches only need to search one place.

The only thing is that we can't just add flags to bugzilla.redhat.com... 
so I suggest we go ahead and make a decision about moving to 
http://bugs.ecos.sourceware.org/

Does it look okay by everyone? If so, we can shut down the old bugzilla, 
move all the existing bugs over, and update the web pages to point to 
bugs.ecos.sourceware.org.

Then once we're running with that and happy that it works, we can start 
looking at what's needed to get patches in there, primarily involving 
documenting patch submission procedure.

One thing I'd still want cleared up is how we keep track of what's 
actually being checked in, i.e. when a patch would transition between 
"approved" and "committed" states. I don't know if Alex has any ideas on that.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine