Re: Membership request for group GNU LilyPond Music Typesetter

[John Mandereau]

On 2008/05/27, Trevor Daniels wrote:
> Graham Percival wrote Tuesday, May 27, 2008 4:42 AM
> > Hmm.  I guess I don't quite understand what you mean by a fork vs.
> > a branch.  
> 
> A fork is a clone of a repository which then runs 
> independently, right?  Unlike a branch a developer
> can be granted access to it without gaining access
> to the main repository.

Yes, this is the idea as far as I understand.  However, I wonder how to
update the forked repository: the most sensible way I can think of is
that somebody who has a forked repo pulls from the upstream repo and
pushes to his forked repo.  If this works like this, it could work as
well as branches like lilypond/translation[*], which are regularly
merged from and into master, but a fork has the big advantage that we
don't have to give the important responsability implied by push access.
So, in brief, it would be very cool to have this on Savannah!

[*] lilypond/translation is just an example that fits well, but this
doesn't mean we're going to change the current way of handling
translations with Till and Francisco: they use push access only for
lilypond/translation, which has worked well so far.


> > Since I don't really understand what you mean by "forks", I don't
> > know how this would improve things... unless you're suggesting
> > that we split the documentation away from the source code, and put
> > it in an entirely separate doc tree.

Err, splitting the two trees would be a nightmare in terms of makefiles.


> It wouldn't be split; it would exist in parallel.  So 
> edits to the docs would be pushed there, the nightly doc
> compiles would be made there, and every so often someone
> with access to both repos would either cherry-pick all 
> the commits into the main repo, or simply copy the latest 
> tested and accepted versions of the .itelys and push them
> en bloc to the main repo.  

Yes, cherry-picking commits, or even merging the branch from the forked
repo if all commits are approved and there are two many commits, is the
way of doing things, if I understand it right.



> Forking wouldn't change anything in the main 
> repo- so little work would be needed.  The
> doc fork could be updated from the main one
> nightly, so it would remain up to date.

I'm not sure this can be automated: doc changes and core code changes
are not always independent, and conflicts that sometimes arise would
prevent an automatic merge from working.


> >> Also, you mention that you spend a lot of time on people that do not
> >> have push access.  The interesting question is: where is that time
> >> going?  If we can make all those contributors spend a few minutes more
> >> each day on preparing and verifying their changes, a lot of time can
> >> be saved.
> 
> Someone would need to be identified to manage this.
> They would need to be able to compile the docs and
> fix any errors which breaks the build - much like 
> Graham does now.  Finding someone is the hard bit!

I already do this for translations, I don't mind doing the same thing
with docs contributors.  Another solution is using management tools like
http://transifex.org (but this would need to be adapted to our needs for
documentation editing), but that's certainly a lot of work to set up.

Cheers,
John