This is the mail archive of the ecos-maintainers@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Doc on How to submit patches


Gary Thomas wrote:
On Wed, 2003-09-03 at 06:34, Andrew Lunn wrote:

On Wed, Sep 03, 2003 at 12:08:40AM +0100, Jonathan Larmour wrote:

Nick and myself have been working on this: http://ecos.sourceware.org/patches.html

Comments? Corrections? Abuse?

The component to use in Bugzilla is "Patches and Contributions". Im humming and harring as to if it would be better to use the component the major part of the patch is in. That way it automagically gets a default owner who we can point a finger at when the patch sits around for a while with nothing happening. If the owner is overloaded its his responsibility to then find another maintainer to take over the patch.

That's true, and what Nick was thinking too. But the other issue is that it would still be good to keep a patch on the ecos-patches list, and with bugzilla you can only associate e-mail addresses automatically with components. So all the traffic to do with patches would end up on ecos-bugs, not ecos-patches, and ecos-patches would no longer be a record of patches considered/reviewed/applied.


Besides, one of us can assign the patch to "the obvious person", but if you consider components like "HAL" or many of the device drivers, there's never an obvious person. Or areas like the kernel where even though Nick is the obvious candidate for much of it, there's plenty of areas which either weren't written by him, or for which other people could resolve issues just as easily.

By putting all the bugs in a pool, other people have a chance to do something about them instead of relying on individuals who may be heavily loaded for some time.

It would be nice to add a state "Waiting for assignment" to bugzilla.

Isn't this just the "new" state? Once it has been looked at by someone, it should then be assigned (as appropriate) and changed to "assigned" or "needinfo".

Hmmm... "assigned" could be ambiguous ;-).


Actually the way we're going to do this is with Bugzilla flags. What you can do is give any attachment to a bug some flags. We will have two flags: "assignment" and "review".

Flags have three states: -, ? and +. We would use these as follows:

For the assignment flag:
-   No assignment
?   Is there an assignment? Or perhaps the assignment is being obtained?
+   There is an assignment

For the review flag:
- This patch was reviewed, but was not acceptable in its present state
? This patch needs review. You would use this in association with an e-mail address.
+ This patch has passed review.


For an example, have a look at this bug:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000042

We currently have too many bugs that are just left at "new" (some in
the old system were 3-4 years old!).  I think they should be moved to
a working status as soon as possible and yes, I know, I'm at least
as guilty as anyone else in this regard.

Well, if anything the older ones are less important as there's "evidently" no urgency.


Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]