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

Fri Mar 6 09:50:08 CET 2015

On Fri, Mar 6, 2015 at 7:38 PM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> Hi,
>
> First of all, i it's not going to be distractive for developers, i'm fine
> with per-feature branch as well, especially if they're using some common
> prefix. "staging" is a bit misleading tho, but can't think of something
> better atm. However, there are still some issues with that. Mainly, who
> does the merge of staging branches? Do we commit all of them or we'll be
> poking author of the branch for the merge? What if author is not really
> available after git is open?
>
> We can also a bit different: per-developer branch. That'd be even less
> branches than features and that way it;s clear who is responsible to what
> changes an so.

Not really a fan of this & reminds me of when we made mistake of
mixing in students GSOC branches.

It means if a dev's not available someone else cant so easily commit
there work, and its not obvious what patches it contains by looking at
the name (need to check it out and read over commit log... this stuff
isnt always clear).

It means if theres conflicts with one patch it makes applying the
other patches a hassle too.

So I'd rather stick with `staging-$DIFF-$brief_description` format (or
something similar).

That said, we could be a bit relaxed about this and just state that
`staging-***` branches are to be merged in after release. And if a
developer really wants their own they can do it. But then they're
responsible sorting out own mess at bcon1.

> ----
>
> We could approach to the issue of applying patches from a totally different
> angle tho. Screw it creating branches in the main repository, just whoever
> is responsible for that patch could have a local staging branch with all
> the commits ready for master. So workflow would be something like:
>
> - Developer sees a good patch
> - He applies it in a local staging branch
> - Gives some reasonable explanation on when it'll be in actual master
> (we'll also need to have a way to mark patches as applied in someone's
> staging branch)
> - Rebases the local staging after the release and pushes changes ot actual
> master
> - Drops the local branch
>
> Not perfect, but addresses concerns of work being spreaded at the
> stabilization period. Plus it could be combined with per-developer /
> per-feature branches (if develoeprs thinks those branches needed).
>
>
>
> On Fri, Mar 6, 2015 at 9:56 AM, Campbell Barton <ideasman42 at gmail.com>
> wrote:
>
>> 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
>> _______________________________________________
>> 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