[Bf-committers] RFC: "Continuous integration" branch?

Campbell Barton ideasman42 at gmail.com
Fri Mar 6 10:07:53 CET 2015

On Fri, Mar 6, 2015 at 8:05 PM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> Yeah, fair enough about per-developer branch would only confuse patch
> applying more.
> Applying in a local branch does not mean you close the patch immediately.
> You close them when the branch gets committed to master. Differencial
> revisions will be closed because of "Differnecial Revision: FOO" mention,
> for patch tracker think we can make it so "Patch TXXX" also closes tasks
> (that we can/should do anyway i think).
> But i'm still fine with just "staging-" branches, would help organizing
> work with the patch tracker a bit more. But what's your opinion about
> staging- branch for non-tracker patches (like regular development things)?

Think its fine as long as the feature branches are clearly marked.
This is almost what `temp-` branches are being used for already.
`staging-` is just indicator its ready for master.

> On Fri, Mar 6, 2015 at 1:56 PM, Campbell Barton <ideasman42 at gmail.com>
> wrote:
>> On Fri, Mar 6, 2015 at 7:48 PM, Bastien Montagne <montagne29 at wanadoo.fr>
>> wrote:
>> > Hi,
>> >
>> > I’m not fan at all of a 'global staging' branch idea, afaik gooseberry
>> > was supposed to be that… What I mean is, I think it will always diverge
>> > one way or the other. We could make per-patch staging branches, but
>> > would add some noise in our git repo…
>> >
>> > I really prefer storing such things locally. That way, each dev can
>> > handle things under his responsibility the way he prefers (local
>> > branches of course, but maybe also mere list of patches to apply, or
>> > whatever). "Public" branches should be kept for reasonably big projects,
>> > or sensitive things that need early testing/team work/whatever, imho.
>> The problem with storing things locally is...
>> - Its not clear to the patch submitter what happened.
>> - We rely on each devs hard-disk/backups... or knowing the URL of
>> their github repo.
>> - Another dev can't easily apply the patch (or wont have access to any
>> improvements made after applying).
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

- Campbell

More information about the Bf-committers mailing list