On Mon, 2009-10-26 at 00:12 +0100, Øyvind Harboe wrote: > What about testers, how should they behave?
Any way they please. ;) Seriously, that's perfectly valid question. Testers should: 1) Clone/pull from a branch that interests them. 2) Run tests. 3) Provide feedback to the branch's maintainer. If maintainers each have their own fork on repo.or.cz, then "ownership" of branches can be determined by the repository's gitweb information. As I see it, the openocd/testing repository can serves as an "unstable" master branch. Things proven to work there get pushed by their maintainer to SF. It should be easy and fast to automate the process of periodically updating the testing repository with a fresh merge from a bunch of branches, with a tag for each. > > For clarity, the cycle of development should go something like this: > > > > 1) Clone from the sacred SF.net (or its mirror on repo.or.cz). > > 2) Commit branch in your local repository. > > 3) Push to repo.or.cz with propery Signed-off-by lines: > > Which repository? Who gets access to the testing > repository? The one for which I forgot to the mention. Developers with commit privileges on SF.net should have access, but we could be more open than that with the repo.or.cz clone than with the primary clone. > > 4) Maintainer pulls branch into testing repository mainline. > > 5) Push branch after it receives sufficient Signed-off-by lines. > > Push branch from what repository to where? > > How do I add a sign-off line? Do I do this after I've tested > something that someone else committed or just something > that I committed myself? There are several ways to sign-off; it's often the '-s' option. One trick I have usd for signing a branch of your patches: git checkout master git branch signed-branch git format-patch --stdout ^master unsigned-branch | git am -s > >but be sure to post a message telling us your branch head, so subsequent > >commits to that branch do not cause the changes to be lost. > > Could you explain this a bit more? I have not tested it, but anonymous users can push to the mob branch. If that branch allows fast-forwards only, then there's no problem. Otherwise, user A could push to the branch with head A', and user B could might push and overwrite that reference with head B'. That would leave A' dangling, so you'd need a direct reference to the relevant commit object to pull it out of thin air. You could push some commits into my private sandbox fork to find out. The test will be if 'git push repo +mob' works at all. If so, that opens the door to the above scenario, unless I am missing something. > Once we have the process a bit more down documentation > in the doxygen docs of the process would be good, but to > get the rules down and to help users, contributers and > maintainers understand what to do and what not to do. Yeah, my writing to the list has aimed to attack that front. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
