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

Alex Fraser alex at vpac-innovations.com.au
Sun Mar 8 01:36:21 CET 2015


Hi,

Have you considered using the git flow workflow [1]? The idea is that you
keep one branch (probably master) always "ready" for release. Then you have
an unstable/staging branch called develop. All significant development is
done on feature branches. I've found it to be quite nice in my own
projects, although admittedly I don't have as many developers as Blender
does.

Cheers,
Alex

[1]
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
On 7 Mar 2015 02:12, "Sergey Sharybin" <sergey.vfx at gmail.com> wrote:

> 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>
> wrote:
>
> > @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
> _______________________________________________
> 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