release management

release management

[Clint Adams]

Since Peter is apparently MIA and Bart is not going to make any more
3.1.6 interim releases, does anyone have a current "snapshot" tarball
available for retrieval somewhere?

Re: release management

[Ollivier Robert]

According to Clint Adams:
> Since Peter is apparently MIA and Bart is not going to make any more
> 3.1.6 interim releases, does anyone have a current "snapshot" tarball
> available for retrieval somewhere?

I think the best idea is to use the anonymous CVS server from Tanaka-san
(do I have the order right here ?). That's what I'm doing...

-=-=-
From: Tanaka Akira <akr@jaist.ac.jp>                                          
Date: 07 Sep 1999 03:55:56 +0900                                              

Personally, I'm tracking latest zsh by cvs. And it can be accessed by
anonymous cvs.

Try `:pserver:anonymous@crane.jaist.ac.jp:/projects/zsh'.
The password is empty string and module name is `zsh'.

The main trunc should be latest zsh.
-=-=-
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- roberto@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.

Re: release management

[Clint Adams]

> I think the best idea is to use the anonymous CVS server from Tanaka-san
> (do I have the order right here ?). That's what I'm doing...

Wow.  I completely missed that message.  Thanks.

Re: release management

[Adam Spiers]

Ollivier Robert (roberto@eurocontrol.fr) wrote:
> I think the best idea is to use the anonymous CVS server from Tanaka-san
> (do I have the order right here ?). That's what I'm doing...

It's not a bad idea, but there are two problems:

  1. Tanaka's machine is in Japan, which is quite a long way away from
     most of us.

  2. It would effectively place Tanaka under the burden of being the
     current patch pumpking, which he may not want.

[ Warning: the following is tedious and contains no patches.  But it
  is /not/ in any way a rant, so apologies if it comes across as one! ]

I may be wrong, but it seems to me that the key developers amongst us
don't feel an urgent need for some central CVS (or other)
repository[0].  This is presumably because after years of hacking
they're genuine gurus when it comes to applying patches of all
different shapes, sizes and ages to zsh.  Alas, some of us (well, me
at least) are not so expert, and personally even with the
semi-automatic patch applying procedure I've created, I'm finding that
trying to keep up to date is taking so much of the time I allocate for
zsh hacking, that in the last few weeks[1] I've been unable to do
anything useful on it[2]...  which kind of defeats the point of
tracking development in the first place.

As a result, I can't realistically continue contributing in my small
way until there is a CVS facility which is declared the authoritative
line of development.  This is certainly no great disaster for zsh, but
it's a shame for me, and there may be others out there with more
worthwhile things to contribute who are hampered in doing so through
the same problem.  So, at this point I get down on my knees and beg:
please can we set up CVS very very soon?!  (Or of course just declare
Tanaka's as authoritative.)  As I think I mentioned before, if no-one
else wants to do it, just say the word and I'll immediately set it up
myself on a reliable RedHat box[3], with write-access for whoever
volunteers as coordinator.  I could even set up a commit mechanism so
that commits from anonymous read-only users would not get committed
but instead forwarded to this list for approval, or similar.

The longer this issue gets left, the more everyone's ideas of what the
current snapshot looks like will diverge, so let's get moving!  And
besides, I have some tasteless prompt colours which urgently need
taming ;-)

Adam


[0] Just a guess based on the fact that despite several discussions on
    the topic, nothing has appeared yet.
[1] It's become harder since the regular intermediate releases stopped.
[2] Ignoring for a moment whether I'm ever able to produce anything
    useful :-)
[3] in the UK, with good bandwidth and plenty of spare resources

Re: release management

[Bart Schaefer]

On Nov 2,  4:50pm, Adam Spiers wrote:
} Subject: Re: release management
}
} I may be wrong, but it seems to me that the key developers amongst us
} don't feel an urgent need for some central CVS (or other)
} repository[0].  This is presumably because after years of hacking
} they're genuine gurus when it comes to applying patches of all
} different shapes, sizes and ages to zsh.

In my case, it's because I do all my zsh work at home, where my net
connection is only 56K at the best of times (usually slower).  I can't
reliably commit into (nor even update from, based on attempts with the
server Tanaka has set up) a remote CVS repository.  If patches stopped
appearing on the mailing list, I'd quickly be as far out of it as you
now believe yourself to be, or else I'd have to set up some kind of
two-stage download through a machine at the office. [*]

} trying to keep up to date is taking so much of the time I allocate for
} zsh hacking, that in the last few weeks[1] I've been unable to do
} anything useful
[...]
} [1] It's become harder since the regular intermediate releases stopped.

I'm trying to see to it that they haven't stopped, just gotten farther
apart, but I'm at if not over my limit on zsh-time.

} As I think I mentioned before, if no-one else wants to do it, just say
} the word and I'll immediately set it up myself on a reliable RedHat
} box[3], with write-access for whoever volunteers as coordinator.

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 could even set up a commit mechanism so that commits from anonymous
} read-only users would not get committed but instead forwarded to this
} list for approval, or similar.

I think something like this is going to be essential.

[*] To get the copy from which I made bart-8, I checked out from Tanaka's
    server while at work, then made a tarfile and scp'd that home.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: release management

[Adam Spiers]

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

Re: release management

[Clint Adams]

> 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.

I'll set up a US mirror(s) if we're going to go this way.
None of that nasty rpm stuff though.  :)

Re: release management

[Dan Nelson]

In the last episode (Nov 04), Adam Spiers said:
> 
> 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:

If you're planning on mirroring CVS trees, cvsup ( at
http://www.polstra.com/projects/freeware/CVSup/ ) is even faster than
rsync, since it knows how to transmit CVS diffs quickly.  It will also
mirror regular files (it falls back to the rsync protocol for those
files).  You can use it to either mirror the whole CVS tree, or keep a
checked-out copy up to date.

-- 
	Dan Nelson
	dnelson@emsphone.com

Re: release management

[Tanaka Akira]

In article <19991104144755.A802@dan.emsphone.com>,
  Dan Nelson <dnelson@emsphone.com> writes:

> > 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:
> 
> If you're planning on mirroring CVS trees, cvsup ( at
> http://www.polstra.com/projects/freeware/CVSup/ ) is even faster than
> rsync, since it knows how to transmit CVS diffs quickly.

Maybe, I successed to setup CVSupd on crane.jaist.ac.jp.  At least, I
can retrieve the repository with following supfile.

*default host=crane.jaist.ac.jp
*default base=.
*default release=cvs
*default delete use-rel-suffix
zsh
-- 
Tanaka Akira

Re: release management

[Adam Spiers]

Tanaka Akira (akr@jaist.ac.jp) wrote:
> Maybe, I successed to setup CVSupd on crane.jaist.ac.jp.  At least, I
> can retrieve the repository with following supfile.
> 
> *default host=crane.jaist.ac.jp
> *default base=.
> *default release=cvs
> *default delete use-rel-suffix
> zsh

It works for me too.  Brilliant!  I'm now setting up a mirror.  I'll
announce here when it's ready.

Re: release management

[Clint Adams]

> > *default host=crane.jaist.ac.jp
> > *default base=.
> > *default release=cvs
> > *default delete use-rel-suffix
> > zsh
> 
> It works for me too.  Brilliant!  I'm now setting up a mirror.  I'll
> announce here when it's ready.

Well, in the absence of better coordination, I'm mirroring this nightly
at :pserver:zsh@cvs.scowler.net:/cvs/zsh, password 'zsh'.
read-only, of course.

I was hoping that we could have arranged something more "push" oriented.

Re: release management

[Dan Nelson]

In the last episode (Nov 05), Clint Adams said:
> > > *default host=crane.jaist.ac.jp
> > > *default base=.
> > > *default release=cvs
> > > *default delete use-rel-suffix
> > > zsh
> > 
> > It works for me too.  Brilliant!  I'm now setting up a mirror. 
> > I'll announce here when it's ready.
> 
> Well, in the absence of better coordination, I'm mirroring this
> nightly at :pserver:zsh@cvs.scowler.net:/cvs/zsh, password 'zsh'.
> read-only, of course.
> 
> I was hoping that we could have arranged something more "push"
> oriented.

You can sort-of do this by having the "CVSROOT/loginfo" action send an
email to everyone running CVS mirrors (possibly using a list alias) on
commits.  Each mirror site would have a procmail script that triggers
off the subject and runs "cvsup -s zsh-supfile".  That line takes about
15 seconds to run assuming no changes have been made, so it shouldn't
tax the network.

Alternatively, you can simply cvsup hourly, or at whatever intervals
you wish.

-- 
	Dan Nelson
	dnelson@emsphone.com

Re: release management

[Adam Spiers]

Dan Nelson (dnelson@emsphone.com) wrote:
> You can sort-of do this by having the "CVSROOT/loginfo" action send an
> email to everyone running CVS mirrors (possibly using a list alias) on
> commits.  Each mirror site would have a procmail script that triggers
> off the subject and runs "cvsup -s zsh-supfile".  That line takes about
> 15 seconds to run assuming no changes have been made, so it shouldn't
> tax the network.

Yep, something like this would be nice.  There's a slight problem in
that commits tend in practice (I find) to be done in bursts, so you
might be sending more than one `do a cvsup -s now' instruction to the
mirrors within a small time span.  However I get the impress that
cvsup is so efficient this would be no great disaster anyway.

P.S. Tanaka, if you decide to do this loginfo trick, could you include
zsh-mirror@thelonious.new.ox.ac.uk on the list of e-mail addresses to
notify?

Re: release management

[Clint Adams]

> Alternatively, you can simply cvsup hourly, or at whatever intervals
> you wish.

cvs.scowler.net is now cvsupping -s hourly and straight once a day.

Re: release management

[Adam Spiers]

Clint Adams (schizo@debian.org) wrote:
> > Alternatively, you can simply cvsup hourly, or at whatever intervals
> > you wish.
> 
> cvs.scowler.net is now cvsupping -s hourly and straight once a day.

So is thelonious.new.ox.ac.uk.  (I hope you don't mind all this load
on your machine, Tanaka!)  Alas, until I punch a whole in the
firewall, the only way to access it is via ssh with port forwarding
... but as far as I can see to do that you already need to have a
local account, since you need to type something like

  ssh -L 5999:thelonious.new.ox.ac.uk:5999 thelonious.new.ox.ac.uk

Or is there another way?

Re: release management

[Sven Wischnowsky]

Adam Spiers wrote:

> ...
> 
> I may be wrong, but it seems to me that the key developers amongst us
> don't feel an urgent need for some central CVS (or other)
> repository[0].  This is presumably because after years of hacking
> they're genuine gurus when it comes to applying patches of all
> different shapes, sizes and ages to zsh.  [ ... ]

Well, I have these reasons:

- Almost no experience with CVS.
- Enough other things to do.
- I'm lazy.

But I think noone would really object if you offer to put up an
(more or less) official CVS server. Although I think most people
around here hoped that it would be build at sunsite.auc.dk -- in fact
Karsten once offered us the space for a CVS server, if I remember
correctly. Since I don't know CVS, I don't know how difficult it would
be to move the server from your host to sunsite if that ever becomes
possible (not too hard, I guess?).

Anyway, my opinion in this case probably shouldn't count that much
considering that -- ahem -- I have fewer patches to apply than most of 
you. Ahem.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de