Re: source mgt. requirements solicitation

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Mon, 9 Dec 2002, Walter Landry wrote:

> Well, there is anonymous ftp.  But if all you have is plain http, I
> would think that you would have problems checking out from CVS as
> well.

FTP is probably useful in most such cases (for arch, since I didn't think
svn provided FTP transport; and I don't know about the other systems
mentioned).  The case I was thinking of is the common situation where most
outgoing ports are free but port 80 is redirected through a "transparent"
proxy to save ISP bandwidth.  (In such situations, a few other outgoing
ports such 25 are probably proxied but are irrelevant here.)  That's one
common (consumer) situation, and FTP and HTTPS probably work there, but
another (corporate) situation may well have HTTPS tied down more tightly.  
Where people have got pserver or ssh allowed through their firewall, there
may be more problems with protocols used for other purposes and restricted
or proxied for other reasons.

(Some blocks might be avoided by choosing nonstandard ports, but then
everyone is likely to choose different ports and create more confusion.  
Arranging that both write and anonymous access is tunnelled over ssh - as
some sites do for anonymous CVS access - simplifies things.)

> That, presumably, would be the release manager's branch.
> Periodically, people would say, "feature X is implemented on branch
> Y".  If the release manager trusts them, then he does a simple update.
> If there is no trust, then the release manager can review the patches.
> In any case, assuming the submitter knows what they are doing, the
> patch will apply cleanly.  It would be very quick.  If it doesn't
> apply cleanly, then the release manager sends a curt note to the
> submitter (perhaps automatically) or tries to resolve it himself.
> This is how the Linux kernel development works, although a release
> manager wouldn't have to do as much work as Linus does.

There are about 100 people applying patches to the mainline (half
maintainers of some of the code who can apply some patches without review,
half needing review for all nonobvious patches).  Having the release
manager manually handle the patches from all 100 people is not a sensible
scalable solution for GCC; the expectation is that anyone producing a
reasonable number of good patches will get write access which reduces the
reviewers' effort (to needing only to review the patch, not apply it) and
means that the version control logs clearly show which user was
responsible for a patch by who checked it in (the case of someone else,
named in the log message, being responsible, being the exceptional case).
Note that the 50 or so maintainers all do some patch review; it's only at 
a late stage on the actual release branches that the review is 
concentrated in the release manager.

(You might then say that the release manager could have a bot
automatically applying patches from developers who now have write access,
but this has no real advantages over them all having write access and a
lot of fragility added in.)

The Linux model of one person controlling everything going into the
mainline is exceptional; GCC, *BSD, etc., have many committers to mainline
(the rules for who commits where with what review varying) and as Zack
explains <http://gcc.gnu.org/ml/gcc/2002-12/msg00492.html> (albeit missing
the footnote [1] on where releases are made from) this mainline on a
master server will remain central, with new developments normally going
there rapidly except for various major work on longer-term surrounding
branches.  Zack notes that practically the main use of a distributed 
system would be for individual developers to do their work offline, not to 
move the main repository for communication between developers off a single 
machine (though depending on the system, developers may naturally have 
repository mirrors) - it is not in general the case that development takes 
place on always-online systems or systems which can allow remote access to 
their repositories.

I expect for most branches it will also be most convenient for the master
server to host them.  The exceptions are most likely to be for
developments that aren't considered politically appropriate for mainstream
GCC, or those that aren't assigned to the FSF or may have other legal
problems, or those done under NDA (albeit legally dodgy), or corporate
developments whose public visibility too early would give away sensitive
information or which a customer would like to have before they go public
(i.e., work eventually destined for public GCC unless too specialised or
ugly, where the customer and company would be free under the GPL to
release the work early but choose not to).  In general, I expect most
development would be on the central server, except for small-scale
individual development (often offline) on personal servers and corporate
development on internal systems that definitely will not be accessible to
the public.

This is, of course, all just hypothesis about how GCC development would
work with distributed CM, but it seems a reasonable extrapolation
supposing we start from wanting to preserve security, accessibility and
long-term survival of all the version history of developments that
presently go in the public repository (mainline and branches).

-- 
Joseph S. Myers
jsm28@cam.ac.uk