On Sat, 2009-10-24 at 20:28 -0700, Zach Welch wrote:
> Hi all,
> 
> There has been talk about creating branches on the server, but
> local branches eliminate the pressing need for public branches.
> I believe public branches often result in tragedy of the commons;
> without clear ownership, they may not be managed as efficiently as with
> branches managed wholly individual developers.  Cleanup is a problem.
> 
> Last night, I started creating a mirror of my repository (as a fork on
> repo.or.cz).  While I am having problems trying to push my branches, our
> past issues were resolved by its maintainer promptly, so something
> should appear there soon enough.  I encourage other active developers to
> follow a similar approach, so let me know if a similar attempt works for
> you on that site.  
> 
> Pulling between repositories should be much easier than sending patches
> or working with centrally managed branches:  that's no better than SVN.
> Further, any mistakes in these branches will be localized to the clones,
> rather than getting pushed into the main repository.  It seems like it
> will be sufficient to post "pull requests" to visit (or pull from) these
> mirrors rather than sending the long series of patches through here, and
> this takes advantage of the full P2P potential that GIT has to offer.
> 
> This avoids proliferation of unfinished branches on SF.net and keeps
> pressure on a branch's author(s) to get the changes finished and merged.

Following on some discussion in other threads, I have gone ahead and
created a new 'openocd/testing' fork on repo.or.cz:

This fork will allow anyone to commit on the mob branch:

  http://repo.or.cz/mob.html

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.

I will give other maintainers push access upon request, so this can
serve as our community sandbox.

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:
4) Maintainer pulls branch into testing repository mainline.
5) Push branch after it receives sufficient Signed-off-by lines.
6) Go to step 2 if serious rebasing would be required before step 5.

For non-maintainers, this still involves the usual process:
1) git clone
2) git checkout -b abc/fixes
3) git -m 'Some changes...' ....
3) git push git://repo.or.cz/openocd/testing.git abc/fixes:mob

This cycle eliminates the churn caused by repeating steps 2-5
indefinitely from ever reaching the master repository.  Basically, it
provides the central repository, but in an isolated environment.

Cheers,

Zach

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to