Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!rutgers!psuvax1!vu-vlsi!dsinc!syd
From: syd@dsinc.UUCP (Syd Weinstein)
Newsgroups: comp.mail.elm
Subject: Re: A Call For Votes [REPOST]
Summary: My qualifications at least
Keywords: Send me your vote
Message-ID: <411@dsinc.UUCP>
Date: 18 Jun 88 02:01:42 GMT
References: <3189@tness7.UUCP> <568@sialis.mn.org>
Reply-To: syd@dsinc.UUCP (Syd Weinstein)
Organization: Datacomp Systems, Inc., Huntingdon Valley, PA 19006
Lines: 70

In article <568@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes:
>In article <3189@tness7.UUCP> mechjgh@tness7.UUCP (Greg Hackney ) writes:
>>
>>This is a call for votes to elect the official Elm
>>Coordinator for future releases of Elm and bug fixes.
>
>(No offense intended to the individuals involved... I'm sure they may
>all be qualified, but someone should still say why...)

OK, folks here goes with my qualifications.  I suggest each of the other
three to do likewise.

I am the owner of Datacomp Systems, Inc. a Unix software development and
testing house that has been developing under Unix since 1979.  We
currently do systems testing and kernel development for several Unix 
OEM's.

We have been using elm since 1.5 and have made many changes to it for
local needs.

We have a site that is relatively well connected, as well as supporting
anon uucp on TB+'s.  We have, currently at least, disk space to spare
for a while (two spare drives even) on our backbone node in our local
net.  We run Unix V.2 and V.3 locally.

We are used to supporting large distributed development projects.  One
of which we have been managing for 11 years is the Medicare
Reimbursement System, and that is about 50MB of C source code.
we have been using Source Code Librarians from back in my CDC 6600 
days of 1973 and do use SCCS extensively for our in house projects.

As for time committments, I am willing to devote the time to elm,
However, I cannot state that I always will be able to do so.  All I
can promise is that I will pass the baton when I find I cannot support
it.

Does that help?

I have made various policy statements in previous discussions with
Greg, these include:

1.  The coordinator will have to be a moderator of sorts, deciding
what features get into the new elm, as some features are bound to
conflict with some others and some might not be universally desirable.
(In fact the corrdinator might have to ifdef some features to allow
for smaller systems and size or for local choice of conflicts)

2.  I guess the coordinator will have to keep two copies of elm.
Their local copy for their system and a master copy without their
local mods that is not localized.

3.  It would help if the coordinator kept annon uucp for the full
system or even ftp if so connected.  But a archive server like the
alt.gourmand one for patches to distribute bug fixes and new features
would be useful.

4.  I don't think posting patches is the best way. I feel we need
some minor control, such as was used for the Perl Patches.  Using
a coordinator to send out official patches would prevent some conflicting
ones from going out.  I can see simple workarounds being posted, but
real patches should come from some central source.

5.  I do believe in sending out patchs, not just releases.  The dist
package for patches should be used.  Also branch sccs id's for
patch revs vs development revs should be used.
-- 
=====================================================================
Sydney S. Weinstein, CDP, CCP
Datacomp Systems, Inc.				Voice: (215) 947-9900
{allegra,bellcore,bpa,vu-vlsi}!dsinc!syd	FAX:   (215) 938-0235