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

[Gaia]

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
>>
>
>