Re: Membership request for group GNU LilyPond Music Typesetter

[Han-Wen Nienhuys]

I would think it was already supported by gitweb, since repo.or.cz
supports it too.

2008/5/28 Sylvain Beucler <address@hidden>:
> 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.
>
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>



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