From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 793 invoked by alias); 10 Dec 2011 19:34:19 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29985 Received: (qmail 4079 invoked from network); 10 Dec 2011 19:34:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: zsh-workers@zsh.org Subject: Re: Next release In-Reply-To: <20111210171956.32b37a06@pws-pc.ntlworld.com> (Peter Stephenson's message of "Sat, 10 Dec 2011 17:19:56 +0000") References: <20111209141117.52c1e37a@pwslap01u.europe.root.pri> <87iplpzfr0.fsf@ft.bewatermyfriend.org> <20111210171956.32b37a06@pws-pc.ntlworld.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux) Date: Sat, 10 Dec 2011 20:20:10 +0100 Message-ID: <877h24xmhh.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Df-Sender: NDMwNDQ0 Peter Stephenson wrote: > Frank Terbeck wrote: [...] > That message seems to be mostly about branch structure which isn't > really relevant to us; our case is much simpler. Obviously the ease of > people having their own private areas without reference to the main > repository is a big gain, but that's up to them. FVWM is pretty much in maintenance-only mode for a while now, so that mail was merely to show possible development models, which might be a helpful insight given that not everybody uses git regularly. >> Thomas later followed up on himself with the following mail regarding the >> ChangeLog file: >>=20 >> >>=20 >> ...and I couldn't agree more. > > I'd prefer to have the ChangeLog, at least to begin with. I find it > much more visible; Really? I find manual ChangeLog updates (even with the help of emacs' `add-change-log-entry') to be the single most annoying thing about CVS from a mere user's perspective, because it doesn't work with changesets. It also makes merging different changes virtually impossible, because there will always be a conflict at the top of the ChangeLog file (although I hear people have automatic merge drivers for that now=C2=B9). > I'm planning to spend as little time as I can playing > with source control, whose job is to stay in the background while I look > at the files (and I find git infuriatingly geeky). If we get rid of it > on a day-to-day basis, we would need to get into the habit of including > all the same information in commits --- which is a perfectly reasonable > aim, particularly when the notion of changesets becomes meaningful. > Generating it at the time of a release rather than immediately might be > something to aim at. If we get to the point where we have a simple > utility (i.e. doesn't demand detailed knowledge of git) that can > generate a readable one, that becomes possible. Yes, ChangeLog conversion could be automated from the output of "git log". A one line approach might be as "easy" as this: git --no-pager log --format=3D"%ai %aN %n%n%x09* %s%d%n" $(git describe --= abbrev=3D0).. ...which would make for a nice alias in ~/.gitconfig. But the result could be better. And people have done better. That's not rocket science. Either we use an existing script from someone else, or we cook up one of our own. >> I don't know if dropping the stable- vs development versions, is somethi= ng >> that would work for zsh (although I think it could - everybody uses 4.3.x >> anyway) > > We've only had separate development branches when needed for long term > work on particular features, first ZLE widgets and then multibyte > characters. [...] Agreed. And even if we'd need a feature branch for stuff like that, it's extremely easy to one such branch in git (as Thomas from FVWM outlined in his mail). [...] > Feel free to bring up anything you think is relevant --- other than the > basic move I didn't see much that seemed to affect our much simpler case > --- but obviously anything that makes administration more complicated is > out (there's no reason moving to git should generally have that effect, > though). Yes. Git can be used with an CVS-like workflow to a central server just fine. And almost exactly the same way as with CVS (except that you make a commit locally first and push the complete commit over to the server after that). It's absolutely up to the individual developer to decide how much of git's feature-set he/she wants to use locally. I also think that there are quite a number of apt git users on -workers, who should be able to assist if something odd comes up (which may or may not happen). As for the actual move to git: Wayne is keeping the CVS repository in sync pretty darn well and I guess it's just a setting somewhere in the sourceforge configuration to turn off CVS commits and enable commit pushing into the git repository. I don't know the sourceforge admin interface, but I'm sure Wayne will have a pretty good idea on how to do that final switch-over. Regards, Frank =C2=B9 (I didn't try that one)