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

Fri Mar 6 13:42:47 CET 2015

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