[Savannah-hackers-public] Re: Membership request for group GNU LilyPond Music Typesetter

[Sylvain Beucler]

Hi,

This is a bit different than what is usually done, because currently
repository permissions are based on Unix groups. These seperate
branches would get permissions of a finer grain. Maybe they could be
implemented using setfacl.

So this requires a bit of web interface to define the new repositories
and the permissions, and a bit of backend job to create the
repositories on the filesystem (in /srv/git/$project/$subrepo.git).

Currently our backup system doesn't support ACLs, but if these ACLs
can be recreated from the subrepositories definition that wouldn't be
a problem.

If you're interested in this feature, the more efficient is to submit
a patch :)
http://git.savannah.gnu.org/gitweb/?p=savane-cleanup.git

Cheers,

-- 
Sylvain

On Tue, May 27, 2008 at 08:41:01PM +0200, John Mandereau wrote:
> 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.