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

[Campbell Barton]

Its a real problem...

There are 2 main issues I have with current system.

- We don't have a good place to queue changes to be made after release.
  When looking at patches to review I found a reply of mine...
  something like: "I'll apply this after 2.61"
... its really weak there isn't a way to handle this, AFAICS
Phabricator doesn't have a good way to see all diffs and patches
associated with a project.

- When we do apply patches after release, we sometimes find problems
which need to be addressed by the original author.
... but weeks have passed and they not available anymore. so the patch
doesn't get applied or we have to re-work the patch ourselves.

----

The main concern with a staging branch is that this becomes the
new-and-shiny version of Blender that users want & devs like to spend
time on, so master gets less testing.

Theres also file-compatibility, if we have patches with Blend-file
versioning being applied to this branch it can get messy.
If managed carefully we can get away without too many problems, but
not convinced we'll be able to do it.

----

Suggest we instead have feature-branches for diffs/patches we want to
apply after release,
then we can rebase them into master and delete them.

We can use some convention "staging-D149-mist_type,
staging-T43678-mball_bvh" for eg, Then its easy to list all patches to
apply after release and we delete the branches once they're in master.

While this might seem a bit messy - we'll have <10-20 of these
branches, during bcon3-4.


On Fri, Mar 6, 2015 at 12:25 PM, Mitchell Stokes <mogurijin at gmail.com> wrote:
> I think the term you might be looking for is staging branch. I've
> considered making one for BGE patches. So, +1 from me for making such a
> branch.
>
> On Thu, Mar 5, 2015 at 2:42 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
>
>> Hey guys,
>>
>> I know it's really a double-edged sword, but still. What about having
>> branch which:
>>
>> - Called somewhat clear what it is: like continous_integration (not the
>> best name in the world perhaps)
>> - It allows developers to commit stuff, regardless of the BCon level
>> - Mainly used dugin bcon3 and bcon4 for the work which can't go to master
>> just because because of bcon.
>> - All the commits to this branch are considered master-ready, no
>> WIP/experimental work in there is allowed
>> - Get;s merged into master after git is open
>> - No commits happening t bcon1,2
>> - Naming could be improved
>>
>> Mainly motivation is coming from:
>>
>> - We're now trying to spend more time on patch reviews, and there are some
>> good patches which are ready for commit but can't go in because of BCon
>> level
>> - Leaving those patches open might lead to situation when we'll loose it
>> from the field of view and wouldn't commit during bcon1,2
>> - There're some ongoing improvements from all the guys around, not just
>> core developers and would be nice if those patches are not getting rottened
>> or so
>> - All the devs are still free to work on the "fun" projects, and could have
>> some stuff cooked during bcon3,4
>>
>> While it sounds like a good idea, i'm actually a bit skeptical about it.
>> Mainly because i would actually prefer everyone to concentrate on making
>> blender stable at bcon3,4. But on the other hand, we can't force all the
>> volunteers to wait, plus we can do some improvements at a spare time. So it
>> might actually work.
>>
>> This is actually a question to all the core developers: do you guys think
>> it might work (maybe with some tweaks to the workflow) and we should try or
>> it's somewhat just crazy?
>>
>> There might also be some other approaches to a problem i'm trying to solve,
>> those are also welcome!
>>
>> --
>> With best regards, Sergey Sharybin
>> _______________________________________________
>> 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



-- 
- Campbell