Op 5-3-2012 1:03, Lars Gullik Bjønnes schreef:
I have added some more gitolite functionality.
(only viewable for the people that has sent me their ssh public key.)
ssh g...@git.lyx.org help
You will not be able to fork anything yet, but as you can see at
http://git.lyx.org/
Browsing the repos seems to be broken right now.
this is basically what it will look like.
The plan forward is:
1. Get the required hooks in place
- This is mostly the post-commit (post-receive really) hook that
sends messages to lyx-...@lists.lyx.org
2. See if we can get the trac connection setup.
- Should just be config, and a another hook to get updates to
the repo signaled to trac.
3. Cleanup and verify the svn->git conversion that I already have in place.
- Unless I have to redo anything this will be quite easy.
4. Make the subversion repo read-only
5. Enable the new lyx-devel git repo at git.lyx.org.
I might be able to do this within the week.
Comments or objections to the plan forward?
We need to agree on how the workflow will be in the future. I'm
convinced that a three-step approach is the best:
1. A developer develops a feature in a branch in his personal fork,
2. The branch gets pulled/pushed into a 'cooking' repo. It will stay in
this repo until the feature is really finished, good and cleaned up.
3. Finally the feature gets merged into a release branch in the main repo.
Trivial features might get skip step 1, and might get to step 3 quickly,
whereas more complicated features take much more time to travel.
My main motivation for this workflow is to make sure:
- features do not change anymore after being merged into the main repo,
therefore not cluttering the history,
- it's easier to review groups of commits (branches) than to review all
seperate commits of which a large part is not interesting or does not
seem interesting (documentation updates, translations, cosmetics, small
corrections to previous commits, fixing typos etc.
This might also have consequences to which messages get send to the
cvs-log list.
Last, I propose to have some mechanism to keep track of the status of a
branch. This can be git notes, or a thread in the mailing list (with the
subject designating the branch). Then it is easy to review all comments
and changes to a certain branch before deciding whether it is ready or not.
Vincent
