Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!rsk
From: rsk@s.cc.purdue.edu (Rich Kulawiec)
Newsgroups: comp.mail.elm
Subject: Re: Future Elm patches
Keywords: full or self service
Message-ID: <3159@s.cc.purdue.edu>
Date: 10 Jun 88 20:11:50 GMT
References: <1095@bellboy.UUCP>
Reply-To: rsk@s.cc.purdue.edu.UUCP (Rich Kulawiec)
Organization: Purdue Computing Center Unix Systems Staff
Lines: 57

In article <1095@bellboy.UUCP> hack@bellboy.UUCP (Greg Hackney) writes:
>This caused a problem for me. I had a number of bugs that
>had to be resolved immediately, or my boss and the users would
>hang me. So, I tended to hack Elm on my own. I, being a slug, didn't
>put it under SCCS control. So, it is always real hairy for me to
>go to a new release.

I strongly recommend using the facilities of a source code control
system such as SCCS or RCS; it makes upgrading to new releases
much, much easier at the expense of some initial learning and
setup time.  Random hacking of sources leads to a state of
entropy in the source directory that I find undesirable.

Incidentally, we use RCS; I guesstimate that it will take us
about half an hour to bring in 2.0 and apply all of our local
changes (which were made to 1.7) to it, and most of the process
will be automated.

>(And, I like the idea of releasing everything
>officially through comp.sources.unix via Rich Salz.)
>
>One thing that is debatable, is whether or not the subscribers
>ought to post bug reports and fixes, or whether to not post them
>but to send them directly to a coordinator. I personally think
>we should openly post everything.

This would create several problems:

1. It will make it difficult to correctly identify patches by
number (and thus to identify the release number of the version
of Elm so generated).  For instance, if you and I release
patches simultaneously, is mine #7 or is yours?  What version
of Elm is thus generated, 2.0.7 or 2.0.7.and.the.other.7?
Sequencing the patches through a coordinator prevents this
from happening.

2. If you're going to send these things through Rich Salz,
and thus to comp.sources.unix, you're much better off having
them pre-organized before shipping them.  I don't purport
to speak for Rich, but it seems to me that he'd much rather
receive bundled, well-organized patch sets from a single person
than scattered random changes from numerous people.  Again,
having a coordinator avoids this problem.

3. It is likely that some problems will have more than one
solution; it's also likely that some of those solutions will
be incompatible.  Someone, unfortunately, must choose which
solution is best for everyone, or else the software will
diverge at different sites.  To avoid endless argument, it
would probably be best to have someone (who is qualified
and interested) resolving conflicting changes.

In view of these considerations, I strongly recommend the
use of a central clearinghouse for changes to Elm.

-- 
Rich Kulawiec, rsk@s.cc.purdue.edu, s.cc.purdue.edu\!rsk
PUCC Unix Staff