This is the mail archive of the gdb@sourceware.cygnus.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]

Re: Status


Jim Kingdon wrote:

> But I guess the GCC system makes sense to me.  If something is enough
> of an issue to be a "technical controversy" in the sense of something
> people would escalate to the chief technical maintainer/team, you kind
> of want to get people on board as much as possible.  Because if you
> proceed without _some_ level of consensus (not among the whole world,
> but at least among a small group of people most involved), then it
> creates various kinds of pain.

I think the GCC system grew out of somewhat unusual (and very political)
circumstances.

In the case of GDB I think it is fair to say that the problem has been
far simpler: Cygnus (a Red Hat company) (1) didn't keep up with the
changing world and was slow (2) in moving the GDB repository to a public
locale.  That in turn both frustrated non Cygnus developers and created
the persecption (real or otherwize) that Cygnus was hogging GDB.


> I mean, there is almost always a way out (e.g. make it an option or
> something, if there really a demand for both solutions).
> 
> One thing I don't want to be single-string is the process of making
> checkins which are believed to be relatively uncontroversial.  Right
> now there is a big problem when the person listed in MAINTAINERS for a
> particular file gets busy or is on vacation or whatever.  Or to put it
> another way, being a maintainer should grant you the right to overrule
> other people but it shouldn't grant you the right to stop things in
> their tracks.  Or something like that.

In this regard, you'll notice that I've followed through the suggestion
(from Eric Bachelo) that there be more than one person listed in under
each problem domain. So far I've seen no comments.


Returning to the actual committee (yes I've been put forward as a
potential member).  Quoting the GCC committee's page
http://gcc.gnu.org/steering.html :

``Membership in the steering committee is a personal membership.
Affiliations are listed for identification purposes only; steering
committee members do not represent their employers or academic
institutions.''

``Generally speaking, committee members were chosen to represent the
interests of communities (e.g. Fortran users, embedded systems
developers, kernel hackers), not companies.''

I would argue that one key aspect the GCC stearing committee's success
is that it has ensured that the committee members are considered
individuals and are expected to ensure that any decisions made are both
transparent and independant.  This ain't no IOC :-)


Following on from this, the GCC's committee's primary purpose was:

``to make major decisions in the best interests of the GCC project and
to ensure that the project adheres to its fundamental principles found
in the project's mission statement.'' (see
http://gcc.gnu.org/gccmission.html).

and this points to the committees' second success.  I being less
concerned with direct technical issues it has allowed the GCC
maintainers to persue GCC's development with rigor while still retaing
coheasion within the project.


As for what I think GDB should do?

There is long term benefit in having a small, largely symbolic, group
that ensure the independance of the maintainers.  Such a group being
selected using a criteria very similar to that of GCC (being truely
independant and only having GDB's interests first).

While such a group is being formed (is it a year now?) I think GDB
should continue with the status-quo - a notional head maintainer but
work delegated to problem domain maintainers.  The main thing to ensure
is that this group demonstrates technical independance when making
day-to-day decisions.

With regard to architectural and stategic problems I think they should
continue to be debated and deveoped in a public forum.  The criteria for
debate being strictly technical.  A committee might have a role but not
as one that directly sets the development agenda.

	enjoy,
		Andrew

(1) Sorry about this
(2) Public CVS repositories are relatively recent phenomina when
compared to the age of GDB :-)

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