This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
Re: Patch policy
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