Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!gatech!psuvax1!vu-vlsi!dsinc!syd
From: syd@dsinc.UUCP (Syd Weinstein)
Newsgroups: comp.mail.elm
Subject: Re: Future Elm patches
Keywords: full or self service
Message-ID: <409@dsinc.UUCP>
Date: 11 Jun 88 17:37:24 GMT
References: <1095@bellboy.UUCP>
Reply-To: syd@dsinc.UUCP (Syd Weinstein)
Organization: Datacomp Systems, Inc., Huntingdon Valley, PA 19006
Lines: 49

Greg proposed posting patches openly, I have to counter`

I agree with using patches, but not open posting of them.  I feel
the patches should be moderated by the coordinator. 

I say so for the following reasons:

1.  This will avoid multiple patches for the same issue.

2.  Many patches might involve machine specific code.  The poster
might not notice this problem, however the coordinator would be more
likely to.

3.  A patch might conflict with a development problem, the coordinator
might be able to change the patch or ask the patch author to change it
to accomplish the same thing without stepping on future development.

4.  Although the patch poster is doing us all a favor, not all net
posters are equal level programmers.  Some patches might be poor
programming that will limit elm or introduce side effects.
The coordinator could use his/her judgement in looking at the patch.
I have seen many 100 line patches to some software I manage that could
easily have been done with a two line change.  The problem was that
the author didnt see the forest for the trees. I may be flamed for this
but most bugs require simple changes.  If a major change is needed,
perhaps the module should be rewritten for a future release.

5.  The coordinator can the make sure that official patches are
incorporated into future releases and can also mark such patches
as official so everyone knows that they will not have to back
them out by hand for the next official patch.  (Note how
Larry Wall issues official patches this way.)

Anyway, my $.02, and I am willing to do it that way.

As for another topic about elm coordinators while I am posting,
I do not feel we need both and RCS and an SCCS tree.  One or the other
will do.  As long as the coordinator checks in and out modules for
editing by the developers, only one tree is needed.  I use SCCS here
due to history reasons (We have used unix since PWB was released and
PWB had SCCS).  One feature we need to use within SCCS is the 
branch delta.  This will allow bug fixes to current releases as well
as future development.  We use this method on several large projects
here at Datacomp Systems, Inc.

-- 
=====================================================================
Sydney S. Weinstein, CDP, CCP
Datacomp Systems, Inc.				Voice: (215) 947-9900
{allegra,bellcore,bpa,vu-vlsi}!dsinc!syd	FAX:   (215) 938-0235