Re: Membership request for group GNU LilyPond Music Typesetter

[Sylvain Beucler]

Hi,

Gitweb is a repository browser. repo.or.cz does more than that,
including repository instanciation, permissions replication, etc.

(In addition, repo.or.cz uses a custom gitweb branch which isn't
merged very often in the official repository.)

So no change is needed in gitweb to view such forked repositories, but
creating them and assigning them permissions, via a web interface,
needs to be contributed in the Savane code (somewhere in the Git
administration pages).

-- 
Sylvain

On Thu, May 29, 2008 at 11:21:12AM -0300, Han-Wen Nienhuys wrote:
> 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