- From: Robin Berjon <robin@w3.org>
- Date: Thu, 21 Feb 2013 10:44:42 +0100
- To: Mounir Lamouri <mounir@lamouri.fr>
- CC: public-sysapps@w3.org
Hi Mounir, a few notes about using GH for this. On 20/02/2013 21:48 , Mounir Lamouri wrote: > - we no longer use master but only gh-pages (to reduce the amount of > overhead); Note that you can make gh-pages the default branch instead of master. That has the advantage that it's what people will then go to directly, it's what any clone or fork will be set to automatically, and most important of all it will make it the branch against which by default the PRs will come (otherwise you'll get confused merging things if you forget to check the branch against which the PR was made). And if you start from a fresh repo and plan to use gh-pages as your master, it's even better if you delete the master branch immediately after creating the gh-pages branch, as the first thing you do after initialising the repo. That will remove confusion. A lot of this would be simpler if GitHub allowed any branch to be selected as the one from which web content is served, but when I brought that feedback to them (which I've heard several times in W3C) they said it's not something people have asked for otherwise, which surprised me a bit. > - as soon as a specification goes to FPWD, we should move it to a > repository in the root; Do you mean move out of proposals and go to a directory at the root of the sysapps repo, or to a repo of its own under the sysapps organisation? I recommend the latter. You will be much better off with separate repos for each deliverable. Especially if you use branches, or if you want to tag releases (which is a good idea IMHO). You also want to avoid having too many people using the same repo for different products: down that path lies merge conflicts, generally on things that you're not in charge of. The only problem is that you lose history from the proposal. I don't think that's a big deal, you can always point to it. > - at least one person per specification should be given write access to > the sysapps github repository; The editor, presumably. > - contributions should be done with PR (Pull Requests) and the person(s) > in charge of the specification are the one allowed to merge them; +1 > - issues should be opened directly in the sysapps repository; That's cool, but keep in mind that you then won't get the trackbot integration. I think that's fine, but it's an aspect to consider. > - persons with write access on the main repository are also requested to > do PR and get review if possible. Perhaps only for larger changes, not for editorial things. Note that there's one thing that people often don't know: you can use a Pull Request flow without having to fork the repo. If you have write access to it, what you can do is this: make your large change in a topic branch, and push it to the repo. If you then hit the web UI it should immediately show an affordance to make a pull request to the master branch based on your topic branch (if not, you can do it from the pull requests tab). The advantage is that you don't have to remember to sync with upstream as you do in a fork. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 21 February 2013 09:44:51 UTC