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
