From: Adam Spiers <adam@spiers.net>
To: zsh workers mailing list <zsh-workers@sunsite.auc.dk>
Subject: Re: sourceforge.net CVS tree ready for use
Date: Sun, 2 Apr 2000 01:45:40 +0100 [thread overview]
Message-ID: <20000402014540.D22212@thelonious.new.ox.ac.uk> (raw)
In-Reply-To: <E12bUrd-0002V3-00.2000-04-01-21-51-26@cmailg5.svr.pol.co.uk>; from pws@pwstephenson.fsnet.co.uk on Sat, Apr 01, 2000 at 09:51:24PM +0100
Peter Stephenson (pws@pwstephenson.fsnet.co.uk) wrote:
> One question is whether we commit CVS changes straight away, i.e. when the
> patch is posted to the list, or wait for comments. The latter will be a
> little messy, since other developers would have to apply the patch to try
> it, then remove it to avoid CVS reporting a conflict. So I think with
> non-contentious patches we might as well do it simultaneously.
I'm in agreement with that, FWIW.
> We should certainly think about Andrej's suggestion that the patches can be
> moved offlist now we have a regular repository.
It's a nice idea, doesn't it then become hard to refer to
individual patches? There needs to be some clearly accessible
many-to-many relationship between e-mails to zsh-workers and
patches (including patches which don't ever get committed).
> As we have write permission on sourceforge, a way for doing
> that over the net could probably be handled. Or maybe Geoff
> can think of something he can set up.
I propose the following system (which should probably be taken
with a pinch of salt, as I am very far from being a core
developer):
We set up automatic e-mail notification of any commits. (This
would be easy enough[0].) These notifications would contain the
CVS commit log message (a brief summary of the patch in the same
style as pws' ChangeLog entries, i.e. including zsh-workers
referral numbers) and the patch itself, and they would go to
zsh-workers in some computer-filterable format. (They could go
to a separate list, e.g. zsh-cvs-commits. The important thing
is that they get stamped with a sequence number for referral
like all e-mails to the lists currently do. Personally I would
prefer them to go to zsh-workers, as we probably all have basic
filtering capabilities, and we don't want to have two sets of
overlapping sequences numbers which we're regularly referring
to.)
Patches continue to be sent to zsh-workers with the normal
accompanying explanation; however in the cases where a developer
with write-access[1] is making a trivial non-contentious change,
this could probably be skipped, as the CVS commit log message
would suffice as an explanation.
Patches sent to the list by a developer with write-access would
simultaneously be committed to the tree. Patches sent to the
list by anyone else would either be rejected or committed to the
tree by the pumpking (currently Peter).
This system would mean:
- most importantly, not too much extra work for those with
write-access (I think?),
- also importantly, the flow of discussion interspersed with
patches would not be interrupted,
- there would be a clear distinction between ideas (patches
proposed) and action (patches used), and developers without
write-access would have a nice easy way to see whether their
own patches have made it into the tree,
- developers could choose quite precisely how closely they wished
to monitor development (some may only want to follow
discussion, others may only want to see commits to the tree), and
- the pumpking wouldn't have to worry about
last-minute-before-release minor tweaks being hidden and
hence puzzling people as to how they happened.
Does it have any problems I've missed?
> - all the other stuff I've forgotten to do which you're going to
> remind me.
One small change to the guide -- in 6.5.3, under `URLs for web
browsers', you wrote `Arguably the system should be able to scan your
browser's bookmarks file, but currently it won't.' This isn't
entirely true, as the distribution includes Misc/make-zsh-urls for
this purpose.
Adam
[0] We've already done this at the place I work at.
[1] Incidentally I include myself in this category even though I
currently have write-access -- I'm not a core developer, so I'm
deliberately using the repository via :pserver:anonymous to avoid
messing anything up.
next prev parent reply other threads:[~2000-04-02 0:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-26 0:50 zsh license preventing move to sourceforge.net? (fwd) Adam Spiers
2000-03-26 19:06 ` Clint Adams
2000-03-26 22:19 ` Peter Stephenson
2000-03-28 0:28 ` move to sourceforge.net in progress Adam Spiers
2000-03-27 21:24 ` Peter Stephenson
2000-04-01 11:11 ` sourceforge.net CVS tree ready for use Adam Spiers
2000-04-01 20:51 ` Peter Stephenson
2000-04-02 0:44 ` Bart Schaefer
2000-04-02 0:45 ` Adam Spiers [this message]
2000-04-02 4:37 ` Bart Schaefer
2000-04-02 6:02 ` Geoff Wing
2000-04-02 22:02 ` Adam Spiers
2000-04-02 23:16 ` Bart Schaefer
2000-04-02 10:10 ` Andrej Borsenkow
2000-04-02 10:35 ` Geoff Wing
2000-04-02 23:29 ` Bart Schaefer
2000-04-03 8:50 ` Geoff Wing
2000-04-03 10:30 ` Oliver Kiddle
2000-04-03 13:06 ` Adam Spiers
2000-03-28 1:46 ` move to sourceforge.net in progress Bart Schaefer
2000-03-28 11:45 ` Andrej Borsenkow
2000-03-28 16:51 ` Bart Schaefer
2000-04-02 14:06 sourceforge.net CVS tree ready for use dmeyer
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=20000402014540.D22212@thelonious.new.ox.ac.uk \
--to=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).