Re: Next release

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:
> Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> 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:
>> 
>>   <http://www.mail-archive.com/fvwm-workers@xxxxxxxx/msg02471.html>
>> 
>> ...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¹).

> 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="%ai %aN %n%n%x09* %s%d%n" $(git describe --abbrev=0)..

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

¹ <http://gcc.gnu.org/wiki/GitMirror#git-merge-changelog> (I didn't try
  that one)