This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: source mgt. requirements solicitation


"Joseph S. Myers" <jsm28@cam.ac.uk> wrote:
> On Mon, 9 Dec 2002, Walter Landry wrote:
> 
> > Anonymous access requires for HTTP + WebDAV (no DeltaV).  However, the
> > set of WebDAV commands needed are much smaller than what subversion
> > needs.  It just needs whatever anonymous ftp has that http doesn't (I
> > believe PROPFIND is one).  In particular, you can run a server using
> > apache 1.3.
> 
> I'm sure some "transparent" proxies will fail to pass even that (though
> WebDAV may be better supported by them than DeltaV).  This is similar to
> Zack's first point - just as any new system must be no less portable to
> running on different systems, it must be no less portable to working
> through networks restricted in different ways.

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.

> > So you don't, in general, have a repository that is writeable by more
> > than one person.
> 
> For GCC there clearly needs to be some server that has the mainline of
> development we advertise on our web pages for users, from which release
> branches are made, which has some vague notions of the machine being
> securely maintained, having adequate bandwidth, having some backup
> procedure, having maintainers for the server keeping it up reliably,
> having a reasonable expectation that the development lines in there will
> still be available in 20 years' time when current developers have lost
> interest.  (gcc.gnu.org presents a remarkably good impression of this to
> the outside world, considering how it operates purely by volunteer
> effort.)

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.

Regards,
Walter Landry
wlandry@ucsd.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]