Re: Repo user

[Han-Wen Nienhuys]

Erlend Aasland escreveu:
> Hello Han-Wen,
>
> I've registered with username eaa on repo.or.cz <http://repo.or.cz>. Can 
> you set me up with push access?

Hi,

it's done. We don't have much of a policy for branches at the moment, 
but here's an overview of what we currently have

 - cvs-head : hourly sync of CVS HEAD
 - cvs-lilypond_2_8 : hourly sync of CVS lilypond_2_8
 - master : default branch for development.

notes:

 * There are more branches, but they're currently unused.

 * don't push into CVS branches. This either breaks our sync cron job, 
or your changes will be discarded (I think the latter, but am not sure).

 * if unsure of a change, just push into a new branch. With the last 
releases of GUB, it's easy to build from separate branches.

Creating a new branch goes like

   git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
       my-branch:refs/heads/new-remote-branch

Then  you can push with

   git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
       my-branch:new-remote-branch



I have two proposals for organizing branches, I hope Johannes (our 
resident GIT guru) will weigh in on what's best

 * have a single branch: master

more or less the current model. Everyone hacks on the same thing: this 
is less confusing, but makes it more difficult to build reliable 
releases quickly. New features tend to creep in when we're busy doing 
build fixes (for getting the release out of the door), potentially 
wrecking the stability of the GUB releases. This is what happened 
yesterday with the quarter rest BPB-bug.

 * have a debian-like: stable, unstable, exp

where features start out in the exp branch, and 
  go into unstable after initial testing. Every once in a while, we 
sync unstable to stable, and build a GUB release. We could have 
autobuild cron daemons that automate testing on unstable and exp, so we 
know when is a good time to sync.

 * have developer centered branches,

   master, master-hanwen, master-jan, master-eea, etc.

and a build-meister who will pull in changes from different developers 
to synthesize a new release which will be the basis for the official GUB 
builds.


Of course, this requires that we have someone who volunteers to be a 
build-meister.  It requires regular access to a fast linux running 
machine for running GUB, and some affinity with compiling packages. Most 
of the grunt work has already been done by Jan & me.

 * have functionality centered branches,

   master, master-doc, master-streams,

this is much like the previous option. However, I would probably go mad 
if I worked on several branches at the same time.





Johannes?



--
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen