[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