[Bf-committers] Cursors, Patches, and Process
dfelinto at gmail.com
Wed Aug 7 15:22:42 CEST 2019
I personally find it useful to have all the changes in a single diff
for review/testing. The criteria I use is not much in regard to size
though, but to added noise to the review. If the OS specific changes
are isolated in specific files I think it is ok to be a single commit.
That said, before committing you could split it to separate the
original (windows-only) bug fix and further improvements.
Note regarding our current review process: We have no way to create a
review for a branch, and even, to clean that branch up (rebases, ...)
during the review process. That would be a more elegant solution for
cases like yours. In this hypothetical scenario we could see a 1:1
snapshot of what will be merged, with individual commits and their
individual commit messages.
Anyways, one thing you can do, however, is to make sure you either use
arcanist to create/update your patches, or use git diff with context
when submitting them (e.g., `git diff -U100` to include 100 lines
before and after the modified changes).
Em ter, 6 de ago de 2019 às 13:14, Harley Acheson
<harley.acheson at gmail.com> escreveu:
> I have been working on something silly that might have some useful bits,
> but I’m worried that it might have grown beyond the ability to evaluate it
> well. So I’m wondering if I should break it up into smaller non-breaking
> incremental changes that can be evaluated and (hopefully) approved
> My *experiments with the cursors <https://developer.blender.org/D5197>*
> started with something I haven’t even done yet, which is the idea of having
> alternatives to choose from while painting / sculpting. But in moving
> toward that my “work in progress” has grown to something huge. Every
> single blender cursor has been redrawn, large versions added for all of
> them. The way that the best cursor type per operating system is selected
> has been changed. New cursors added. And then the entire set of cursors
> has a nicer antialiased replacements for Windows users.
> But that would mean, for example, that a Windows user would not see any of
> the built-in blender cursors in order to give any feedback on those. Even
> Mac users would see more OS-supplied cursors so would not see all blender
> cursors and would (obviously) see no Windows cursors.
> So I ‘m wondering if I should break this project into pieces. All the
> windows cursors can be added at once, just some files added and changes to
> GHOST_WindowWin32.cpp. With that and just a few lines changed in
> wm_cursors.c it would fix a bug where our cursors are invisible in Windows
> when HDR and WCG are turned on:
> Afterward I could add a separate patch that only edits the images of the
> built-in cursors and maybe adds a few more. Then some changes to how the
> best cursor per-OS is selected, some small changes to GHOST_WindowCocoa.mm
> so Macs will use some more OS-supplied cursors. Then lots of small changes
> to allow use of the new cursors in different tools, etc. All atomic changes
> that break nothing but add only smaller improvements.
> Is that kind of approach more reasonable, or do I keep bumbling forward
> with a patch that was 132K the last time I checked? LOL
> Cheers, Harley
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers