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.
I should also point out that you can define as many flags as you want as
well as associate them with different components, etc, as well as bugs
and attachments. So it is really up to you to decide what you want the
process to be.
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 have no problem with this.
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.
I would have thought something like flag "review+" with associated bug
state CLOSED would imply that it was applied and committed. The
bug/patch state would be RESOLVED (since the feature/enhancement was
added by a patch), so after a patch goes through "request review"
(review?) followed by "review approved" (review+) the next state would
be "CLOSED".
Alternatively since a flag status is simply a single character (Mozilla
folks used '?','-','+' and NULL) you can also add a new flag state like
'=' to mean committed (review=).
As you have control of the flag feature, you do not even have to call
the flag "review" and you can add as many flags as you want. For
example, Mozilla use "superreview". To add flags (follow the "flags"
link at the bottom of the "query" page - this is available only to
maintainers - to add/edit/delete flags etc).
Up to you really to decide - you have the power. Unlike
bugzilla.redhat.com (well you try to get the sources for the Red Hat
version of bugzilla then ;-), this really is open source, and you know
what you always say... ;-)
BTW, the table description for flags is:
+-------------------+--------------+------+-----+---------------------+
| Field | Type | Null | Key | Default |
+-------------------+--------------+------+-----+---------------------+
| id | mediumint(9) | | PRI | 0 |
| type_id | smallint(6) | | | 0
| | status | char(1) | | |
| | bug_id | mediumint(9) | | MUL | 0
| | attach_id | mediumint(9) | YES | | NULL
| | creation_date | datetime | | | 0000-00-00
00:00:00 | | modification_date | datetime | YES | | NULL
| | setter_id | mediumint(9) | YES | MUL | NULL
| | requestee_id | mediumint(9) | YES | MUL | NULL
|
+-------------------+--------------+------+-----+---------------------+
Like I said, the power is yours...
-- Alex
Jifl