Vincent van Ravesteijn <v...@lyx.org> writes: | 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.
I am not sold on the cooking repo. I agree completely on step 1, except that I think it should be compbined with the parts from step 2 about staying there until the feature is finished and cleaned up. This repo should be shared with other developers by using a public repo (developers/larsbj/lyx), or even email, One reason why I am not sole on the cooking repo is that we have very limited testing resources and I am not sure if dividing those between a cooking repo and a master repo is a good idea. > | 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, There will be bugs. | - 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 means that all features/changes should as much as possible we developed in their own branches and shown to others with a public repo (developers/larsbj/lyx) | This might also have consequences to which messages get send to the | cvs-log list. I think only the master repo should send anything 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. This really seems awfully complex. And IMHO any kindo of freetext status storage is bound to be incomplete and wrong. Use the log and shortlog, and refere to bugs in commit messages. -- Lgb
