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

Eugene Minov minov.eug at gmail.com
Fri Mar 6 11:17:53 CET 2015


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
>


More information about the Bf-committers mailing list