This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB 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: [maint] The GDB maintenance process


On Wed, Feb 19, 2003 at 10:17:12AM -0500, Andrew Cagney wrote:
> 
> >> > Right now, we use stricter policies to prevent problems which cause
> >> > breakage.  I think these policies are stifling us.  Loosening them (and
> >> > maybe adding a formal patch reversion policy) would let more people fix
> >> > problems more easily, as they arise, without slowing development.
> >> > 
> >>
> >>I really think that having the bug database track patches is a very
> >>big improvement. We should try to push its use a bit more before
> >>giving up on the current rules. 
> >
> >
> >I don't like it, but that's just my general anti-GNATS rancor.  Maybe
> >Bugzilla will be better.
> 
> The idea of tracking things as bugs or GNATS?

Mostly, GNATS.

> Tracking this stuff in a public database is, I think, clearly better 
> than the status quo (my mailbox).  It's already been mentioned that 
> there is possibly a lack of response with some maintainers.  At least 
> with me putting unreviewed patches in the database, we can figure out 
> what patches there are, and if there is a problem.  (my todo list 
> includes checking that all the key developers are on the bug tracking 
> list, I suspect that some are not.)
> 
> Anyway, have a look in the database, you'll notice all sorts of 
> interesting things.

Which reminds me.  We've got two GNATS databases set up for GDB: 'gdb'
and 'gdb-patches'.  Should we use the gdb-patches GNATS database to
separate them from bug reports?

> For instance search for tdep & h8300.  There is an obvious backlog and 
> someone (a global maintainer like yourself or I) needs to step up and 
> work through them with the contributors.  That task, while no where near 
> as glamerous as a new feature, is absolutly needed and maintainers do 
> need to be willing to chip in (in fact I think that task and 
> documentation should be given a higher profile when handing out 
> `credit').  Hopefuly these patches will even yield a new developer.

TBH, I've been avoiding it because I don't know the slightest thing
about the h8300 and it seemed like someone (I don't remember who -
MichaelS maybe?) did.  If I'm wrong then one of us is just going to
have to suck it up and learn about the h8300... yay, another project.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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