zsh-workers
 help / color / mirror / code / Atom feed
From: Adam Spiers <adam@thelonious.new.ox.ac.uk>
To: zsh-workers@sunsite.auc.dk
Subject: Re: release management
Date: Thu, 4 Nov 1999 20:33:39 +0000	[thread overview]
Message-ID: <19991104203338.C12554@thelonious.new.ox.ac.uk> (raw)
In-Reply-To: <991103082052.ZM3082@candle.brasslantern.com>

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?)


  reply	other threads:[~1999-11-04 20:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-27 14:40 Clint Adams
1999-10-27 14:50 ` Ollivier Robert
1999-10-27 14:52   ` Clint Adams
1999-11-02 16:50   ` Adam Spiers
1999-11-03  8:20     ` Bart Schaefer
1999-11-04 20:33       ` Adam Spiers [this message]
1999-11-04 20:39         ` Clint Adams
1999-11-04 20:47         ` Dan Nelson
1999-11-05  2:21           ` Tanaka Akira
1999-11-05 16:28             ` Adam Spiers
1999-11-05 20:21               ` Clint Adams
1999-11-05 22:39                 ` Dan Nelson
1999-11-06 11:35                   ` Adam Spiers
1999-11-08 14:18                   ` Clint Adams
1999-11-08 17:12                     ` Adam Spiers
1999-11-03  8:22 Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19991104203338.C12554@thelonious.new.ox.ac.uk \
    --to=adam@thelonious.new.ox.ac.uk \
    --cc=adam@spiers.net \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).