Re: sourceforge.net CVS tree ready for use

[Adam Spiers <adam@xxxxxxxxxx>]

Peter Stephenson (pws@xxxxxxxxxxxxxxxxxxxxxxxx) 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.