From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14154 invoked from network); 2 Apr 2000 00:45:46 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Apr 2000 00:45:46 -0000 Received: (qmail 22188 invoked by alias); 2 Apr 2000 00:45:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10379 Received: (qmail 22181 invoked from network); 2 Apr 2000 00:45:41 -0000 Date: Sun, 2 Apr 2000 01:45:40 +0100 From: Adam Spiers To: zsh workers mailing list Subject: Re: sourceforge.net CVS tree ready for use Message-ID: <20000402014540.D22212@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh workers mailing list References: <20000401121150.A18158@thelonious.new.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pws@pwstephenson.fsnet.co.uk on Sat, Apr 01, 2000 at 09:51:24PM +0100 X-Home-Page: http://www.new.ox.ac.uk/~adam/ X-OS: Linux 2.2.12 i686 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.