[Bf-committers] What's the turnaround on small fixes?

Sc Ch xchaoscontrolx at gmail.com
Sat Feb 25 20:34:57 CET 2017


I submitted my first code diff a week ago for a small fix, and I have yet
to receive any review regarding it. Who should I be tagging on small bug
fixes for review, and what's the usual turnaround for these things. I know
you guys have bigger problems to worry about (like the state of the 2.8
branch) so I thought I'd ask. For some context, here's my task:
https://developer.blender.org/T50704

On 25 February 2017 at 03:00, <bf-committers-request at blender.org> wrote:

> Send Bf-committers mailing list submissions to
>         bf-committers at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.blender.org/mailman/listinfo/bf-committers
> or, via email, send a message with subject or body 'help' to
>         bf-committers-request at blender.org
>
> You can reach the person managing the list at
>         bf-committers-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-committers digest..."
>
>
> Today's Topics:
>
>    1. Re: Blender 101 / workflow project (Dr. Sybren A. St?vel)
>    2. Blender 2.8 and "OpenGL Occlusion Queries" (Dalai Felinto)
>    3. Fracture_modifier_integration: tightening the     screws (
>       meeting ) (Jens Verwiebe)
>    4. Blender 2.78c RELEASE AHOY! (Sergey Sharybin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Feb 2017 15:03:49 +0100
> From: Dr. Sybren A. St?vel <sybren at blender.studio>
> Subject: Re: [Bf-committers] Blender 101 / workflow project
> To: bf-committers at blender.org
> Message-ID: <2239824.AUjcfUsdnu at ws-sybren>
> Content-Type: text/plain; charset="utf-8"
>
> On Friday, 24 February 2017 00:59:48 CET Campbell Barton wrote:
> > Hi, after a 7 months away I'm happy to announce I'll be working for
> > the Blender-Foundation again!
>
> Woohoo! Welcome back dude!
>
> --
> Sybren A. St?vel
>
> https://cloud.blender.org/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: This is a digitally signed message part.
> Url : http://lists.blender.org/pipermail/bf-committers/
> attachments/20170223/84222193/attachment-0001.pgp
>
> ------------------------------
>
> Message: 2
> Date: Fri, 24 Feb 2017 16:59:25 +0100
> From: Dalai Felinto <dfelinto at gmail.com>
> Subject: [Bf-committers] Blender 2.8 and "OpenGL Occlusion Queries"
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
>         <CAGjvzG3YyAGOmQo=b8cC7C2UaJbQd6y5DLq0AU9i5BJ9umamaQ at mail.
> gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi all,
> (Antonis and Campbell in particular)
>
> As part of Blender2.8 OpenGL version bump to 3.x, we will need to
> address our selection code "situtation". As you know we right now have
> the following selection methods in user preference:
>
> * "OpenGL Select"
> * "OpenGL Occlusion Queries"
>
> The former method works flawlessly in Blender (in most computers), but
> it relies on deprecated OpenGL calls (namely glRenderMode). Those
> calls are a no-go for the new OpenGL. And on top of that this mode is
> causing an extreme slow down in Blender 2.8 at the moment.
>
> The latter works fast and well in 2.8, BUT, it still has a few missing
> features/bugs compared to the former. Mainly the nearest object/bone
> is not always selected [*].
>
> What I would like to know is if this is a limitation of the "Occlusion
> Queries" method, or simply a bug in our current implementation.
>
> I don't think we have the dev-power to tackle a new selection code at
> the moment. But if the "Occlusion Queries" method is fixable we can
> try to prioritize that. And eventually make it the only supported
> method.
>
> [*] - https://www.youtube.com/watch?v=AA-Z_gB4OPk
>
> Thanks,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 24 Feb 2017 17:39:18 +0100
> From: Jens Verwiebe <info at jensverwiebe.de>
> Subject: [Bf-committers] Fracture_modifier_integration: tightening the
>         screws ( meeting )
> To: bf-committers at blender.org
> Message-ID: <cf654506-022c-3506-abef-d2e8d33f8eb0 at jensverwiebe.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Fracture_modifier_integration: tightening the screws ( meeting )
>
> Hi folks.
>
> You all know fracture_modifier ( called fm further ) is planned to be
> merged into Blender 2.8.
> Some reviews already happened but are unfortunately a bit outdated (
> https://developer.blender.org/D817 ).
>
> To settle this all we are going to have a meeting on 5th of march right
> after
> bf meeting ( around 5 - 6pm ), to get an insight about the current status:
>
> - whats to be done at all
> - who may be interested to give a helping hand
> - possible ideas to get over some complaints
>
> In general i propose to start following actions asap:
>
> 1) Ad hoc adapt the minor things complained about in D817 such as:
>
> - blender codestyle
> - using blender functions where possible
> - other syntax/guidelined stuff thats "peanuts"
>
> 2) Discuss the bigger more intrusive changes:
>
> - how to handle the "shards" subobjects
> - get a proper way for fm to handle the versioning
>
> To be clear, actual the fm branch is pretty nice compatible to master and
> and the delivered branch builds can just be used as an official blender.
> Fm is a now used in some productions and ppl where fully satisfied with
> the imho well thought features and speed.
>
> The biggest problem is that the main work is on the shoulders of Martin
> Felke
> only ( C stuff ) and you all know how hard it can be to keep code well
> up without
> having enough eyes looking over it.
>
> Personally i even propose to merge in fm even before 2.79 to fullfil my
> considerations.
>
> Anybody is welcome to join IRC #blenderfracture for the meeting as well
> as for random
> discussions.
>
> Jens
>
> --
>
> Jens Verwiebe
> Allerskehre 44 - 22309 Hamburg
>
> Tel.: +49 40 68 78 50
> mobile: +49 172 400 49 07
> mailto: info at jensverwiebe.de
> web: http://www.jensverwiebe.de
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 24 Feb 2017 21:02:04 +0100
> From: Sergey Sharybin <sergey.vfx at gmail.com>
> Subject: [Bf-committers] Blender 2.78c RELEASE AHOY!
> To: Blender Developers <bf-committers at blender.org>
> Message-ID:
>         <CAErtv25QFKadRAWi_zbG_ZqFzCf+fYVNY94OQ6=8GGF8xLapHA at mail.
> gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> As was agreed in the meeting, we do a crucial fixes update for 2.78b for
> those regressions which slipped in.
>
> Information for platform maintainers:
>
> - Branch: blender-v2.78c-release
> - Branch hash: e92f235283071c13759bc4e6e861e4e938985307
> - Locale hash: 0171e7ca48c845fce040d12a26d314d3c573f9af
> - Addons hash: fcdeee23b3ce58010692e949df65e4013279a499
>
> Suggested name: blender-2.78c-<platform>.
>
> Place builds to usual location and let me know when they're up.
>
> Tagging will happen soon after all the builds are up. Same applies to the
> source package. This is because there's still chance of re-AHOY needed if
> some platform encounters compilation error.
>
> Additionally i've shared Windows and Linux builds in the staging folder on
> FTP now [1] so everyone has a chance to test them while we wait for OSX
> builds.
>
> == Changes ==
>
> - Port all changes for automated Cycles testing {{GitCommit|c6e4a81d}}
> - Fix for wrong render result of hair with BVH motion steps
> {{GitCommit|b3b4084}}
> - Fix compilation error of GLSL viewport when using Light Path node
> {{GitCommit|9215848}}
> - Fix wrong Brick texture in material viewport {{GitCommit|8ba1dab}}
> - Fix crash with material preview and image sequences {{GitCommit|dd2e33b}}
> - Fix T50512: Linked Backround scene with animation not updating with new
> depsgraph {{GitCommit|e89145e}}
> - Fix T50687: Cycles baking time estimate and progress bar doesn't work /
> progress when baking with high samples {{GitCommit|67169e7}}
> - Fix T50748: Render Time incorrect when refreshing rendered preview in GPU
> mode {{GitCommit|b95645c}}
> - Fix wrong render results with texture limit and half-float textures
> {{GitCommit|909c8ec}}
> - Fix Cycles still saving render output when error happened
> {{GitCommit|d9e6268}}, {{GitCommit|90d96de}}
>
> [1] http://download.blender.org/ftp/sergey/tmp/staging/
>
> --
> With best regards, Sergey Sharybin
>
>
> ------------------------------
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
>
> End of Bf-committers Digest, Vol 151, Issue 20
> **********************************************
>



-- 
--Suchaaver Chahal


More information about the Bf-committers mailing list