[Bf-committers] GP Branch to 2.8 Merge Plan

Joshua Leung aligorith at gmail.com
Mon Mar 26 16:00:14 CEST 2018

Regarding Antonio's comments:
* Indeed, I was initially keen on taking a similar approach, where we
basically do a high-level review of things like the overall architecture of
the system, then fix smaller/less-rigid things post-merge. Specifically,
this review would likely focus on certain areas that are likely to be
contentious (e.g. how exactly the GP draw engine integrates with the
viewport/renderer/compositor, how does GP cache its drawing data, how
modes/mode-switching are handled, does the GP-depsgraph integration handle
COW properly, etc.), as well as checking on anything that gets saved to a
file (e.g. the brush/palette changes, are all file-io bits and pieces in
place, etc.). Everything else we can slowly review/fix post-merge.

(Things like UI layout and some of the modal operators are probably best
tackled post-merge, when it becomes easier for the rest of the UI team to
go in and fix it without delaying the bulk of the functionality).

* Also, +1 to the comment about the current GP having been "battle tested"
so to speak :)

Regarding Campbell's comments:
* Hmm... most of the DNA changes  are actually just related to us changing
the bGPDbrush/bGPDpalette/bGPDpalettecolor types for the standard Blender
Brush/Palette/PaletteColor types (and shoving all the GP settings into
those places.  However, because we change this, most of the UI changes (and
the operators to support those) also have to come along, or else the UI
scripts will bug out and nullify the entire UI.

* As for the drawing system stuff, those changes are what end up bringing
in the rest of the branch's changes that the Brush/Palette changes didn't..

On Mon, Mar 26, 2018 at 9:26 PM, blendergit <blendergit at gmail.com> wrote:

> Hi all,
> I'm not sure what it's the best way to merge the branch, but I think it
> worth to evaluate if the effort to make by parts is more than make a
> general review in the branch first and then merge in one step. Later we
> could fix or change small things here and there.
> I want to bring here an important point, grease pencil is being using for
> months in a real production environments and currently it's one of the most
> stable areas of Blender 2.8. I make a merge of 2.8 branch on a daily basis
> and we have been for weeks without any big bug or crash.
> Definitely, make the merge by parts will not be an easy task.
> Regards,
> Antonio Vazquez
> De: Campbell Barton
> Enviado: lunes, 26 de marzo de 2018 8:59
> Para: bf-blender developers
> Asunto: Re: [Bf-committers] GP Branch to 2.8 Merge Plan
> Wouldn't it be possible to merge DNA, file io and drawing first?
> On Mon, Mar 26, 2018 at 8:30 AM, Joshua Leung <aligorith at gmail.com> wrote:
> > Hi all,
> >
> > As discussed during last week's meeting, I've gone through putting
> together
> > a first pass attempt at figuring out how we could merge the GP branch
> into
> > 2.8 in smaller pieces that are easier to review.  [1]
> >
> > Unfortunately, there is the problem that we have a rather
> large/non-trivial
> > part of the branch where all the groups of changes all depend on all of
> the
> > others being present, making it tricky to find a good way to split that
> up.
> >
> > Regards,
> > Joshua
> >
> > [1] https://developer.blender.org/T54426
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list