[Gdb] Re: New discussion list.

[J.T. Conklin]

>>>>> "Phillip" == Phillip Rulon <address@hidden> writes:
Phillip> There is a new mailing list, address@hidden, available for gdb
Phillip> discussion.  The list administrator is currently me, if there
Phillip> is someone else interested in doing it let me know.

While I'm replying to this message, I'm really replying to ideas that
have been expressed in the entire thread.  As I reread the discussion
so far, I couldn't find any one message that seemed right for a follow-
up, so I came back to the message that started it all.

* In the meetings where the formation of the GDB steering committee
  was introduced, I think it was understood and accepted that there
  were both political and technical objectives.  Moving the repository
  was an identified goal.  I'm not sure that supporting services like
  mailing lists and list archives were mentioned, but it's really the
  same thing to me.  

  I agree with this move, but I don't think it's as important as when
  we moved the master sources out of Cygnus internal repository into a
  public repository merged with binutils.  This change removed real
  control of GDB from Cygnus/RH, and I think the current move is
  intended to remove perceived control.

  However...

* Perhaps then, but definately at the follow-up meeting at ACT,
  concerns about the stability of the FSF machines were raised.  RMS
  has on several occasions assured us that this will be taken care of.
  The stability of FSF machines has never been quantified.  I believe
  that RMS is sincere in wanting the machines to be reliable, I also
  believe that people have had bad experiences in the past.

  Since I have not had personal experience, I'm a bit torn.  But as
  we've been arguing the same points for a year or so, I think it's
  time to bridge the gap.  RMS has made the first move by providing
  Phillip as a FSF resource to make this happen.  IMO, It's now our
  turn to follow up.

  [ Because of my uncertainty over the stability situation, I'll say
  that I'm pleased that we're only talking about moving the mailing
  lists at this point.  In my experience, latency is the killer when
  it comes to volunteer distributed development projects.  As e-mail
  already has variable latency, an hour downtime is not as catastro-
  phic as a hour where the repository is unavailable.  In the first
  case, I'd probably not notice the outage.  In the second, it might
  stall me from working that day.  An extended e-mail outage would 
  have the same effect, so it is still very important to have high 
  availability. ]

  I think it would have been better had once Phillip been identified
  for another round of communication between him, the proto-steering
  comittee, those folks currently maintaining the GDB development
  infrastructure, and perhaps RMS.  For example, there are actually 7
  or 8 mailing lists that are used in GDB development, plus there are
  technical issues like spam filtering and archiving that need to be
  addressed in order to make it a smooth transition.

  Unfortunately, we've got a bit of patching up to do between those
  who are currently doing this job.

I'm not sure what to recommend.

No timetable has been proposed.  While I think this has dragged on for
far too long, I don't want to rush the transition and do a poor job in
the processes.  I think for many GDB contributors this change may be
viewed as fixing something that isn't broken.  If we botch it, it will
be the first impression of the newformed comittee.  Let's get it right.

I think we need to put all the open issues on the table, and see how
what resources can be put in place to address them.  Once identified,
we should be able to get a good idea of how long it's going to take.

Open questions:

* What is Phillip's role/mandate, short and long term, for the
  maintenence of the GDB lists.

* What is the ongoing role of those who have been maintaining the GDB
  development infrastructure (mailing lists, mail archive, bug
  database, repository, etc.).  Will they be continuing these duties
  on the FSF machine after the transition.

* Someone mentioned getting another machine gdb.gnu.org (not a source-
  ware alias, so there would be no identity leakage) but still hosted
  at redhat to do this.  What are the benefits and drawbacks to this?
  Is this acceptable to RMS/FSF?  Would it make the transition easier?  
  Could/Would RH host/maintain such a machine?

* What are other technical issues that need to be resolved?

        --jtc

-- 
J.T. Conklin
RedBack Networks