[x265] Collaboration with topic branches

[Steve Borho]

On Thu, Sep 19, 2013 at 4:08 AM, SF Markus Elfring <
elfring at users.sourceforge.net> wrote:

> Hello,
>
> I have read a bit about a "default branch" (in the document section
> "Release Management").
> https://bitbucket.org/**multicoreware/x265/wiki/**
> Contribute#markdown-header-**release-management<https://bitbucket.org/multicoreware/x265/wiki/Contribute#markdown-header-release-management>
>
> How do you think about to work also with topic branches?
> http://git-scm.com/book/en/**Git-Branching-Branching-**Workflows<http://git-scm.com/book/en/Git-Branching-Branching-Workflows>
> http://stevelosh.com/blog/**2009/08/a-guide-to-branching-**in-mercurial/<http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/>
> http://mercurial.selenic.com/**wiki/BranchingExplained<http://mercurial.selenic.com/wiki/BranchingExplained>


If there will be development efforts that work away from the main default
branch for any length of time, I prefer for that development to happen in
separate clones (forks) rather than on a named branch.  Some of that is for
aesthetics, named branches live forever.  But mainly it is because of the
nature of our development, a single mailing list.  Keeping track of what
patches are destined to which branch would be a lot of pain, not to mention
the extra effort demanded of reviewers.

So instead I would like to allow development forks to have unlimited push
access to their own repositories, but when they wish to merge their
development with our default branch they submit patches from their fork to
our ML for review.

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130919/bf7ad456/attachment.html>