[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RTEMS Patches (was Re: FTP client API)
- Date: Fri, 23 Apr 2010 09:46:14 +0200
- From: arnout at mind.be (Arnout Vandecappelle)
- Subject: RTEMS Patches (was Re: FTP client API)
On Friday 23 April 2010 00:31:43, Chris Johns wrote:
> Bugzilla provides a state driven database of open tickets. Changes
> handled this way can be searched, linked, and managed openly with a full
> history of the discussions attached to the ticket. The ticket is always
> present so the history is always available. If you find a bug or suspect
> a bug please add it. It is simple to say, not a problem, duplicate, or
> fixed and to close it. For patches, if you are working on a change that
> is big, or has a long life cycle then a ticket maybe be better.
> Patches to the mailing list are always welcome but can be lost or
> maintainers may think someone else is handling it. I know I need to keep
> a thread around in case I have missed a piece plus it can become
> confusing knowing which patch or patch set is correct.
In my experience, it is really necessary to put everything in a tracker or
things will get lost. However, if something is put only on the tracker and
not on the mailing list, it can also get lost. There are always much fewer
people who follow the tracker than those who follow the mailing list.
Therefore, if a bug is put in the tracker but none of the maintainers can
reproduce it, or if a feature is put in the tracker but none of the
maintainers finds it sufficiently interesting, it will never get followed
up. If it were posted on the mailing list instead, there is a much higher
chance that somebody can do something useful with it, even if it never ends
up in the core.
So ideally I guess there should be a post on the mailing list as well as a
ticket in the tracker. An approach I've seen in one (very small) project
was that everything was supposed to be put in the tracker, and you forward
some of the mails that the tracker generates (on rtems-bugs) to the mailing
Just my 2c.
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43