From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10304 invoked from network); 4 Nov 1999 20:33:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Nov 1999 20:33:55 -0000 Received: (qmail 19313 invoked by alias); 4 Nov 1999 20:33:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8552 Received: (qmail 19306 invoked from network); 4 Nov 1999 20:33:47 -0000 Date: Thu, 4 Nov 1999 20:33:39 +0000 From: Adam Spiers To: zsh-workers@sunsite.auc.dk Subject: Re: release management Message-ID: <19991104203338.C12554@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh-workers@sunsite.auc.dk References: <19991027104033.A29314@dman.com> <19991027165016.A79545@caerdonn.eurocontrol.fr> <19991102165034.A12065@thelonious.new.ox.ac.uk> <991103082052.ZM3082@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <991103082052.ZM3082@candle.brasslantern.com> X-URL: http://www.new.ox.ac.uk/~adam/ X-OS: Linux 2.2.12 i686 Bart Schaefer (schaefer@candle.brasslantern.com) wrote: > Aside from the unresponsiveness of the staff at sunsite.auc.dk lately, > I think in fact that a volunteer coordinator is the missing bit. We've > had several offers of places to put such a thing, but no one with the > bandwidth (time and network together) to run it. I've only just started using it, but it's obvious already that Tanaka's repository is first-class, and as he's doing such a good job, it's pointless duplicating effort elsewhere. Tanaka, would you mind if we started viewing your repository in a (more) official light? > I can't reliably commit into (nor even update from, based on > attempts with the server Tanaka has set up) a remote CVS repository. Might this be because of its location? Even if it isn't, presumably in an ideal world you'd want to work offline, build up a collection of patches, and then somehow commit them locally which would put them in a queue to be delivered to zsh-workers or the repository next time you went online. This would be great for me too, another `56K at best, 0K at worst, 2K most of the time' sufferer. However, I just realised that it's not possible. From the CVS info documentation: Note: when CVS is accessing a remote repository, `commitinfo' will be run on the *remote* (i.e., server) side, not the client side (*note Remote repositories::.). So to be able to commit offline and do some clever queuing you'd need a local copy of the repository, which brings us back to the connectivity problem. I just had an idea. Tanaka, if it's not too much to ask of you and your machine, what would you say to adding an entry in your $CVSROOT/CVSROOT/loginfo file something like this: ^zsh rsync -rlpt -e ssh $CVSROOT/zsh zshmirror@thelonious.new.ox.ac.uk: (or put the rsync command in your crontab)? Then we would have an exact, read-only[1] mirror of your repository which might be quicker to access for some people. (I'd have to set up the zshmirror account first of course, but this would be no problem at all.) Likewise if someone has a machine in the USA which could act as another mirror then that would presumably greatly help Bart and others. I could then also set up automated nightly rpm builds (a la Mozilla Tinderbox idea), which would be quite cute. Add to this some sort of automated e-mail notification of which patches actually make it into the repository, and I think we're getting near a setup which satisfies everyone -- those who want CVS have it, and those who don't, don't need it. Thoughts? Adam [1] I guess that it would be way too risky/complex having a two-way read-write mirror, unless the concurrency issues can be resolved easily in some very cunning way (by using the existing CVS locking mechanism somehow?)