Re: Patch policy

[Alex Schuilenburg <alexs at ecoscentric dot 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.

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