Re: we now have "lilypond" organization on GitHub

[Urs Liska]

Am 17.09.2013 18:21, schrieb David Kastrup:
> Janek Warchoł<address@hidden>  writes:
>
> > 2013/9/16 David Kastrup<address@hidden>:
> > > So the question is what we should be telling the Savannah operators
> > > to make working on GNU projects using Git more feasible.
> > Here you go:
> > A web interface with online editor, allowing to create commits from a
> > web browser, on any branch (as well as creating branches), integrated
> > with pull requests and automatic forking (so that when someone without
> > write access tries to modify a file, Savannah automatically forks the
> > repository for him and when he's done making the change, a pull
> > request is sent to the original repository).  Also, being able to post
> > comments on commits, and integration of pull requests with code
> > review.  And the ability to update a pull request with new commits.
> >
> > As far as i know Savannah doesn't have these features.  When it will
> > have, i'll be happy to switch, but i don't expect it will happen today
> > or tomorrow, so i'm going to use Github for now.
> Now basically we have to split these into two different sets of
> requirements: Savannah does not provide accounts or services to the
> general public; its services will be restricted to actual developers.
>
> But what you list above mostly is _not_ related to participating with
> the project but rather with managing one's own repository using a
> graphical interface that just happens to be provided as a web service,
> in a similar vein to Gmail providing a web interface to handling a mail
> account.

I think that's not quite true.
IIUC Janek lists options that allow people to contribute to LilyPond 
without officially applying to be developers.

You are doing code reviews through a web interface already, isn't it?
And this is because that's a quite natural way to communicate, comment 
on code etc. You can't do _that_ with plain Git.

> Now making people dependent on a central server for an activity better
> done locally kind of defeats the point of Git as a distributed version
> control system: it means you can't do basic work offline.

That's not what he's talking about at all. Janek is excited about the 
possibilities Github's web interface offers so that people _without Git 
knowledge_ are able to contribute to a project.
This won't downgrade the role of 'real' developers but will open up the 
process for _small_ contributions by volunteers.

For example:
If I find an issue with a translation or have a small documentation 
suggestion I currently have the options:
- write to bug-lilypond and hope _someone_ will take care of it
- have LilyPond as a Git clone, apply a change, create a patch, try to 
get that patch somewhere where it will be considered - and hope someone 
will take care of that.

With a web interface as offered by Github (or Bitbucket, and probably 
others too), I could directly edit a file and have it up for review 
automatically. My 'pull request' is inserted in the list of issues where 
it can be accepted, discussed or rejected.
If I had this opportunity I'm sure I would have submitted dozens or 
hundreds of commits by now. As I don't have that opportunity I have in 
fact submitted exactly _one_ commit by now, which served as a test and 
corrected a single typo, and which wasn't followed by any more.

Now don't tell me I'm too lazy and actually _could_ have done more 
because the road isn't blocked to contribute.
But an open source project should do what is possible to 'invite' people 
to contribute.

> Obviously, Github is not interested in promoting workflows bypassing
> their central servers,

I don't think that's completely fair, but I don't care enough to go into 
it right now.

> but that does not mean that one can't think about
> that oneself.
>
> So the question is: what kind of tools should people have for working on
> their own repository, and what kind of tools are needed at the server
> side?  Naturally, it would appear to make sense to have some sort of
> submission mechanism.

OK, how do I see it, what is my position as a potential contributor?

Anybody interested in any serious contribution can be expected to know 
and use Git.
So we assume I have cloned lilypond from Savannah.

Now I can work on it, keep my clone in sync and add branches and commits 
to my local clone.
But now when I have done some work that I want to contribute I don't 
have any way to get that work into the official repository because I 
don't have push access.
What seems natural to me is to get a fork of the official repo to which 
I have push access.
When I have pushed my commits to that fork I need some way to tell the 
maintainers that there is something and that I ask them to merge that 
into the main code base.
That's what pull requests are on Github, and they are so very convenient 
because they incorporate review and merging.
But I would also do with a less refined interface. Basically a pull 
request is a message like: "I have commits to share. Please add my fork 
as a remote, inspect it and possibly merge it into the upstream repo."

Of course this would require some way for anybody to create an account. 
And if that's not possible or wanted there should be some other 
semi-automatic way of getting code from my clone into upstream.
For example I could imagine some sort of access policy that allows 
non-registered authors to push only to a certain class of 'sandbox-like' 
branches. Maybe branches could automatically be prefixed with something 
like 'external/useremail/' or the like. Once the commits are on the 
server one could start reviewing and finally merging them.

But as far as I've understood, code doesn't get into upstream master 
that way anyway, there is the Rietveld code review stage in between?
How do commits (from developers) actually end up in master?
Are they a) pushed to some branch, the diff uploaded to Rietveld, and 
upon acceptance the branch merged to master?
Or are b) commits uploaded to Rietveld and then applied as patches to 
the upstream repository?

For an outsider this process is quite obscure, and probably that's the 
point where one could start to improve.
If it works like b) one should simply make the process more transparent 
so it's not as adventurous to dive in.
If it works like a) it's as I've said: there should be a way an external 
contributor can get commits into the repository.

####

By now I seem to be completely lost ...
But maybe someone can help me out and at that occasion have good ideas 
about the issue ...

Best
Urs