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

Sergey Sharybin sergey.vfx at gmail.com
Fri Mar 6 16:11:59 CET 2015

I would say:

- Being able to filter in dev.b.o is omsething we must have. I've created a
quick patch to filter differencial revisions by project [1]. It was
rejected by upstream because phabricator team wants to have general way to
filter all objects which depends on project without having duplicated code
all over the place [2].

It'll take some time still i think, but meanwhile i don't see anything bad
in applying D11999 for our installation for until generic filtering is
implemented in an upstream. Likely some latest updates from upstream allows
to get rid of other hacks in our copy :)

- I still think we should allow having staging-PATCH branches for
non-trivial changes at least. WOuld be kinda temp- but we'll know those
branches are subject to be merged sooner when the git is open.

[1] https://secure.phabricator.com/D11999
[2] https://secure.phabricator.com/T5595

On Fri, Mar 6, 2015 at 7:46 PM, Campbell Barton <ideasman42 at gmail.com>

> @Gaia,
> Users like to use the *best* version of Blender (who can blame them!)
> if there is a version with 3+ interesting improvements which will be
> in the next release. I'm sure they'll use it, build on graphicall...
> etc.
> Of course anyone can make some patches version of Blender, but if we
> have a lot of users running it, it means we get issues with file
> versioning, and generally less users running master.
> And as I said before, more developers building the staging branch,
> less time finishing up master, more time moving onto the next version
> before we released this one.
> @Julien,
> Right -  there is a `blender-next` project, but no good way to collect
> all diff's and tasks associated with it. This looks like it may be
> getting implemented (Sergey can post on this topic since he's
> investigating), even in this case it could be good to have
> feature-branches for non-trivial patches so we get to apply the patch
> and make any minor changes needed, which we would normally do before
> going into master.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

With best regards, Sergey Sharybin

More information about the Bf-committers mailing list