[Queue-developers] Introduction

[Mike C. <da...@ix...>]

Hello.

As most of you know, I have volunteered to become the new GNU Queue
maintainer.

My apologies for taking so long to make my announcement.  In retrospect,
I probably should have written something sooner, but I did want to put
my full attention into this announcement.

In mid-June, when Werner first announced that he felt he no longer has
the time to give Queue the attention it deserves, I toyed with the idea
of taking over.   I had just started a large, time-consuming personal
project, and thought that if, when I finished it, if no one else had yet
taken over, I'd see what I could do.  Not too long later, though, Richard
Stallman put out a feeler on the info-gnu mailing list, and I decided
to throw my hat in the ring, even though I wasn't quite in a favorable
position yet.  Things progressed a bit faster than I had anticipated, and
in early July, RMS selected me to take over.  It wasn't until late-August,
however, that I had time to actually start the actual work on taking
over Queue.  The large-time consuming part of my personal project is over,
and now I have the time to concentrate on Queue.  [One would think that
being unemployed, you'd have more time on your hands!]

If I remember correctly, I first became interested in Queue when someone
posted about portability of tty settings/changes across platforms.
I have been following Queue development off and on since.

My personal use for Queue is across my home network of a bunch of Linux
based boxes at home, maybe expanding to using Cygwin.

In a recent email, Werner commented on the differing opinions on what
Queue should be.   The comment about simplicity is somewhat amusing, as
that is what appeals to me.  At one point, when having difficulties with
getting Queue to work, I wrote a bunch of shell scripts that I called
the Simple Queuing System.  So I guess that probably gives a hint at
which direction I would tend, but is certainly no guarantee that is the
direction I will go.

There are a lot of other points that Werner brought up in his
introduction, such as IPv6 support and client-server v. peer-peer,
for example, that I need to get up to speed on.

My current short term plans are this:

1) Review the code base and make sure I'm familiar with all of the
elements in the package.

2) Review all of the messages on the multiple queue-* lists to make sure
I know all of the current issues.

3) Familiarize myself with the facilities that SourceForge has to offer,
and see how they are currently being used within the project.

4) Look at the tools necessary to product a release and make sure there
is suitable access to correct versions (I tend to run bleeding edge on
all of my tools, which may not be acceptable).  I'm talking about things
like auto* tools and the such here.

After I know that I can package a release, I will probably do another
beta release, if with no other changes than current CVS plus contact
information changes.  Then start work towards an official release.

Longer term plans are a bit more up in the air.

Some things I'd personally like to see would be (in no order):

+ Better cross-platform capabilities.  For example, I'm not sure on the
current status of load determination, sharing determination of load,
tty capabilities, and so on.  They might all be fine, but I want to
verify that.  It _might_ be a case where something like XML-RPC would be
a good solution.  If XML did become introduced in the package, it would
probably make since to turn the configuration files into something XML
capable as well.

+ Library support.  I would really like to be able to use Queue and GNU
Make together transparently and do something like 'make -j' across all
available machines.  I would imagine it should be possible to create an
API that can be linked in.

+ Resource allocation facilities.  Extend the spooldir notion to identify
arbitrary resources, and a client can specify that it is going to use
those resources and scheduling can occur as appropriate.

Can't think of anything else to say at the moment.

Unsurprisingly, I will probably pester Werner quite a bit as things
progress.

Meanwhile, must now go entertain the munchkin while an SO fixes dinner.

Cheers,
mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc