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

[Sergey Sharybin]

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)?

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