[Queue-developers] response from Mike Castle

[Koni <mh...@co...>]

Hi folks,

Message below is from Mike Castle regarding the recent changes for GNU
queue, originally sent to just myself, Werner, and RMS, but Mike has
authorized me to forward it to the development list. 

Please see his comments on future directions for development in the
second half of the letter. I will add some comments in a reply following
this message.

Cheers,
Koni

-------- Forwarded Message --------
From: Mike Castle <da...@ix...>
Reply-To: Mike Castle <da...@ix...>
To: Richard Stallman <rm...@gn...>
Cc: Mike Castle <da...@ix...>, mh...@co...,
wer...@ya...
Subject: Re: Maintaining GNU Queue
Date: Mon, 13 Jun 2005 16:10:17 -0700

Richard, Werner, and Mark:

My apologies for the issues I have caused.

When I first took over Queue, I had ample spare time, being unemployed at
the time.   I had expected to make some quick work of the project.

But, as I got into it, it turned out to be more work than I anticipated,
for reasons I'll get into below.

Then, of course, I found a job.  Between work and raising a family, it
turned out I was never able to find the time to properly fix the problems.
Heck, finding time to properly reply to these messages from Werner and
RMS was just another indication of the problem.

I could not, as much as Werner requested it, simply do a release with
just my name as the new maintainer.  Releasing something that wouldn't
even compile just wasn't right, in my opinion.

Some work I did get done on Queue is the following:

Updated to modern autoconf.  I think all of that is taken care of.
It should work with any autoconf-2.59+.

It does compile again, but all of the terminal allocation code is now absent
(that is, you HAVE to use -n now).

Two main issues and several minor ones (plans really) still exist:

1) As I mentioned, no terminal code.  The previous stuff was too outdated
to work on modern systems.  I could have just borrowed code from a package
like screen, expect, or script or something.  While screen and expect at
GPL, I was actually hoping to get something owned by FSF, and use it.
To that end, a post to one of the GNU lists asking for pointers would
probably be a good start.

2) The more important issue, I think, is that the protocol, as currently
implemented, is subject to race conditions.  I can deadlock in less
than 3 seconds with nothing more complicated than the `date' command.
This requires a complete overhaul, which is where I got caught up.

3) Starting with the minor issues, or would be nices, would be a migration
from SF to Savannah.  At one time, when I thought I was going to give
energy to Queue, I was going to do this migration, then they had the
security issue in 2003.

4) Slowly rewrite all of GQ to enable a definitive set of authorship,
to enable safely transferring the code to FSF ownership.  (This was why
I didn't want to just pull terminal code from expect, or even screen,
as neither of those are FSF owned either.)

5) I'd had some grand ideas about rewriting both the config files and
communication protocols using some sort of XML structure.  I'm less
convinced of that now.  But the current set of configuration items are
too system specific, and every time I see a double go across the wire,
I wince.  I really think that there should be more emphasis on heterogenous
environments, including configurations shared by multiple architectures.

6) I'd also thought it's be cool to have some sort of library suitable for
use with linking into GNU Make for remote processing when using `make -j'.
I now think this can be accomplished by using SH=/some/wrapper/if/not/qsh
instead.  I may be wrong though.

In looking over Mark's proposals, some of this may be addressed soon already,
particularly the protocol race-condition issue.  At one point the question
was raised on whether or not any code from Queue could be reused or not
to implement some of his ideas.  My gut reaction is probably not.  Ideas,
sure.  But probably not any code.  Not to implement what he had in mind.
A re-write from scratch would probably be easier than trying to retrofit
some those ideas on top of the current code base.  Well, reusing some of
the autotools stuff should work.

I would like to emphasize heterogeneity again.  Once thing that I read in
Mark's proposal was a seeming focus on Linux-kernel based systems.  Or at
least homogenous environments.  I strongly feel this is a big mistake.
All the world is not a VAX.  Let's not continue to relearn this lesson.

Werner, if you've not yet done so, please go ahead and remove me from the
SF project.  I don't for see having any time to even participate in a role
as being able to compile+test, much less contribute any code.

Again, my apologies.  It shouldn't have required an external event like
this to kick start the process.

Good luck, Mark!

Cheers, mrc