From: Alex Schuilenburg <alexs@ecoscentric.com>
To: Jonathan Larmour <jifl@ecoscentric.com>
Cc: eCos Maintainers <ecos-maintainers@sources.redhat.com>
Subject: Re: Patch policy
Date: Wed, 07 May 2003 23:27:00 -0000 [thread overview]
Message-ID: <3EB99682.7010003@ecoscentric.com> (raw)
In-Reply-To: <3EB96CDB.5080405@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.
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
next prev parent reply other threads:[~2003-05-07 23:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-06 12:59 Gary Thomas
2003-05-06 13:17 ` Mark Salter
2003-05-06 13:26 ` Andrew Lunn
2003-05-06 13:34 ` Gary Thomas
2003-05-06 13:40 ` Andrew Lunn
2003-05-06 13:44 ` Gary Thomas
2003-05-06 14:51 ` Jonathan Larmour
2003-05-06 14:46 ` Jonathan Larmour
2003-05-07 20:30 ` Jonathan Larmour
2003-05-07 21:54 ` Gary Thomas
2003-05-07 22:48 ` Alex Schuilenburg
2003-05-07 23:02 ` Jonathan Larmour
2003-05-07 23:39 ` Alex Schuilenburg
2003-05-07 23:55 ` Jonathan Larmour
2003-05-08 0:18 ` Alex Schuilenburg
2003-05-08 3:16 ` Jonathan Larmour
2003-05-08 9:45 ` Alex Schuilenburg
2003-05-07 23:27 ` Alex Schuilenburg [this message]
2003-05-06 15:00 ` Jonathan Larmour
2003-05-06 15:06 ` Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EB99682.7010003@ecoscentric.com \
--to=alexs@ecoscentric.com \
--cc=ecos-maintainers@sources.redhat.com \
--cc=jifl@ecoscentric.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).