Re: Patch policy

[Gary Thomas <gary@mlbassoc.com>]

On Wed, 2003-05-07 at 14:30, Jonathan Larmour wrote:
> 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.
> 

I'm OK with this.  BTW, can we actuall use the eCos logo that's on the
page?

> 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.
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates