Re: gdb@gnu.org Discussion

[Russ Allbery <rra at stanford dot edu>]

I'm totally unqualified to step in here, as I'm not a maintainer of any
kind, just an interested party who follows a lot of the compiler and
autoconf-related mailing lists.  But given that several other projects
have already gone through this process, and given that I'm as outside of
an observer as it's possible to have (I guarantee that I'm not part of any
shadow organization that gets confided in :)), I'll throw out a couple of
things just 'cause.

Feel free to ignore me completely and pay attention to the people who
really know what's going on.

Kevin Buettner <kevinb@cygnus.com> writes:

> On Nov 23,  3:47pm, Andrew Cagney wrote:
>> People on this mailing list should be aware of the discussion:
>> 
>> http://sources.redhat.com/ml/overseers/2000-q4/threads.html#00214

> Indeed we should!

> For those of you who have not had a chance to look it over yet, it is
> about eliminating this mailing list (gdb@sources.redhat.com) in favor
> of a newly created list hosted at gnu.org.

After having read all the way through that thread (which was interesting,
definitely, and didn't take that long to read through), I don't think
that's a completely accurate characterization of the *intent* (possibly as
opposed to what steps have been taken so far).

The intent is to host the GDB mailing lists (and presumably the web pages;
no one's talking about the CVS repository, which as with most things
related to the compiler and development tools is a more complicated
problem) at gnu.org rather than at a site affiliated with a particular
company.  This isn't a new idea for FSF projects, honestly; I've seen
exactly this situation play out with several things I've been watching.

Whether or not the existing list will be moved intact to another host or
if people will need to switch over is one of the points being debated.

> I think that the members of this forum should be allowed to weigh in
> with their opinions on whether they think this is a good thing or not
> prior to it actually happening.  In particular, I would like to
> understand the technical reasons for eliminating this mailing list in
> favor of another.  In my opinion, there should be some very compelling
> technical reasons for such an action...

There aren't technical reasons to do this.  The reasons for doing this are
related to the public image of GDB maintenance and the desire to avoid
tying the GNU project to any particular company, regardless of what
company that is.

It's my firm belief, as about as much of an outsider as you can get (I
work for Stanford University, I have no affiliation with Red Hat beyond
owning some -- very small amounts -- of their stock, I'm not a GNU
maintainer, and I don't even have assignment papers filed), that this is
an accurate statement of the reasons and that this is not coming out of
Red Hat bashing, some desire to punish Red Hat, or anything of the sort.

I also can see the FSF's point.  Admittedly, I *personally* consider it a
fairly minor point and it wouldn't affect my willingness to contribute to
GDB, but I can understand how a public association with Red Hat *may*
discourage a Red Hat competitor from wanting to contribute to GDB
development.  I don't know if it's ever happened; it probably hasn't.  But
I also don't think it's a position completely without merit.

> Of even greater import though is the fact that this mailing list move is
> apparently being mandated by some sort of shadow organization of which
> we know almost nothing about.

Said "shadow organization" is the GDB Steering Committee (being formed),
from what I can tell reading those same messages.  Now *I* knew that a GDB
Steering Committee was in the process of being formed, probably, along the
same lines as the GCC Steering Committee, and as stated above, I'm hardly
someone that anyone is going to talk to.  :)  I don't recall where I saw
that information, though; it's possible that it was on some other public
mailing list rather than the GDB list.

As a sysadmin who installs GDB and uses it periodically, and as an
observer of the GCC project from the very beginning of the egcs lists, I'm
wholeheartedly in favor of the establishment of such a committee and most
of my guesses as to who might be on such a committee seem to be born out
by the above-referenced thread.  I think it's greatly helped the GCC
project to have such a committee, and it's a model that's been used
successfully with other free software projects.

Openness of deliberations among a committee like this does always come up;
there's been an excellent discussion of this on the GCC mailing list
recently (and a very calm and reasonable discussion).  But, again as a
complete outsider (a contributor may have other views), I find such a
committee to be mostly a substitute for a human maintainer, and a single
human maintainer isn't expected to record in public all of the thoughts
they have about a decision before they make it.  :)  They're just required
to explain and justify their decision.  Similarly, I see no particular
reason to require that a steering committee mailing list be open to
subscribers or be publically archived provided that the decisions and
their justifications are explained in public.  As has been pointed out on
the GCC list, a lot of what is discussed on such a list is private issues
such as personality conflicts that are better off being kept confidential
so that they can be resolved without lots of public bickering distracting
people doing work from doing that work.

Anyway, that's just my two cents.  I find the moving about of mailing
lists bothersome in the short term, since it's a pain to adjust all my
mail splitting rules, but I also know quite well that in two or three
months I will have completely forgotten about it, so if there's long-term
benefit for making the move, I can definitely see the justification for
it.  And as a sysadmin, I offer my sincere gratitude in advance to the
poor people who get to implement it and thoroughly understand their
annoyance at having to change something that's working for no technical
reasons.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>