[Bf-committers] RFC: "Continuous integration" branch?
gaia.clary at machinimatrix.org
Fri Mar 6 11:38:04 CET 2015
I just was thinking about something similar, but possibly easier to
- A development branch for committing ongoing work.
- Release branch created as soon as "only patches allowed" applies.
Then while the release branch is active any commit there could possibly be
automatically merged into the development branch. Of course whenever
a conflict happens, then the "release developer" would have some extra
work to resolve this.
So, as soon as the release is done, the release branch contains the finished
release (ready for delivery) and the development branch is still up to date
because all release fixes have been propagated to the development branch.
Would something like this make sense?
On 06.03.2015 11:17, Eugene Minov wrote:
> I'm not a developer but just read the thread and have been thinking, what
> if instead of making branch per feature, try to make branches for each BCon
> level or one branch for BCon in general and delete that branch after
> Sorry if this is not acceptable way or you already discussed that. Just a
> On Fri, Mar 6, 2015 at 11:07 AM, Campbell Barton <ideasman42 at gmail.com>
>> On Fri, Mar 6, 2015 at 8:05 PM, Sergey Sharybin <sergey.vfx at gmail.com>
>>> 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
>> 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>
>>>> On Fri, Mar 6, 2015 at 7:48 PM, Bastien Montagne <montagne29 at wanadoo.fr
>>>>> 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
>>>>> 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
>>>>> 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
>>> With best regards, Sergey Sharybin
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> - Campbell
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers