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

Julien Duroure julien.duroure at gmail.com
Fri Mar 6 14:42:04 CET 2015


Hello,
Sorry, seems there is already a "blender next" project....


> Le 6 mars 2015 à 13:42, Julien Duroure <julien.duroure at gmail.com> a écrit :
> 
> Hello,
> 
> What about a "ready to merge" phabricator project to identify patches that are ready, but not merged yet because of bcon4.
> This will solve lost patches into phabricator from occasional developers. But not solve core developer commits , that are not linked to phabricator tasks.
> 
> Regards,
> 
> 
>> Le 6 mars 2015 à 13:26, Gaia <gaia.clary at machinimatrix.org> a écrit :
>> 
>> Are these assumptions based on common sense or
>> are these approved observations?
>> 
>> - Basically everyone will just stick to shiny
>>  development branch
>> - release wouldn't even be well-tested by artists.
>> - Plus file compatibility issues will still exist.
>> 
>> 
>>> On 06.03.2015 12:03, Sergey Sharybin wrote:
>>> If you'll read conversation with Campbell a bit more accurate Gaia's
>>> proposal will cause the same issue as staging branch mentioned above.
>>> Basically everyone will just stick to shiny development branch and release
>>> one wouldn't even be well-tested by artists. Plus file compatibility issues
>>> will still exist.
>>> 
>>>> On Fri, Mar 6, 2015 at 3:55 PM, Joshua Leung <aligorith at gmail.com> wrote:
>>>> 
>>>> Gaia's suggestion makes a lot of sense IMO.
>>>> 
>>>> Basically, when we get to BCon4 time, we fork off a release branch for the
>>>> upcoming release. Development can continue in master, but fixes will be
>>>> backported to the release branch one by one. This acts as an extra level of
>>>> protection against accidental last-minute cleanups sneaking in.
>>>> 
>>>> On Fri, Mar 6, 2015 at 11:38 PM, Gaia <gaia.clary at machinimatrix.org>
>>>> wrote:
>>>> 
>>>>> I just was thinking about something similar, but possibly easier to
>>>>> maintain:
>>>>> 
>>>>> - 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?
>>>>> 
>>>>> cheers,
>>>>> Gaia
>>>>> 
>>>>>> On 06.03.2015 11:17, Eugene Minov wrote:
>>>>>> Hi!
>>>>>> 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
>>>>>> release.
>>>>>> 
>>>>>> Sorry if this is not acceptable way or you already discussed that.
>>>> Just a
>>>>>> thought..
>>>>>> 
>>>>>> Eugene
>>>>>> 
>>>>>> On Fri, Mar 6, 2015 at 11:07 AM, Campbell Barton <ideasman42 at gmail.com
>>>>>> wrote:
>>>>>> 
>>>>>>> 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
>>>>>>> _______________________________________________
>>>>>>> Bf-committers mailing list
>>>>>>> Bf-committers at blender.org
>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>> _______________________________________________
>>>>>> Bf-committers mailing list
>>>>>> Bf-committers at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list