Being a windows platform dev this could pretty much be a list called 'things nobody will get exited about' but here's my plans/wish-list regardless
If I get nothing else, I hope it's this one (2.81): I think the most important one for stability is having working automated crash reporting, being able to see the top 10 reasons why people lose work and proactively fix them should go a long way in improving the end-user experience. I Have the client side code for win/linux is in a workable state, arto will have to take another look at the mac side since I'm pretty sure I broke that when I merged it from 2.7 to master. Nathan is looking into the server side of things. (D3576) Nice to haves (not attached to a release target): 1) I'd like to see the unit tests run nightly on BF infrastructure (I currently run them nightly on azure, but we cannot run the opengl based tests on there) but this is something the people at the institute need to work on. (Already on the list in T66306) 2) Cycles unit tests: Currently the cycles unit tests only test the kernel most appropriate for the host it runs on, small differences errors between architectures have been slipping though our test suite. All render tests should run on all kernels we build. If nobody picks this up I'll have stab at it. (not yet on the list in T66306, but probably should be there) Developer experience (not attached to a release target) 1) I'm planning some small tweaks to the build helper scripts on windows to give developers some features that have been asking for like being able to specify an absolute path for the build folder. I'm open for other suggestions/improvements here. 2) Enable JMC for compilers that support it JMC [1] drastically cuts down the time you spend stepping though boiler plate C++ code in the debugger, once master gets unfrozen I'll enable this for debug builds on VS2019. 3) Developer profile. Not my work, but i'd like to see brechts D5149 land sooner than later, just to get rid of some of the annoyances like buildinfo being on for developers by default leading to constant rebuilds which leads to less productive developers. (D5149) 4) Rewrite the build instructions for windows. The wiki could use a refresher, some things can be clarified better, other things can be skipped all together since the build scripts take care of it now-days. I have been dragging my heels on this. Libs 2.81: I'm mostly following here, If you want/need a dep update for your module speak up! 1) Python, I heard talk about a python version bump a while ago (but never saw the official request to bump it), also I have to repackage python on windows so `make format` can use it and we longer have to rely on a system python being installed, so these things will probably go together. (not yet on any list I'm aware of) 2) USD will need to be scripted and packaged if sybren wants to get USD into 2.81, I have this partially done already, but USD on windows is having an 'unhappy time', officially the windows support is experimental so our success may vary on this. The code builds and links but doesn't work due some plugin registration issues inside USD. I haven't found the time to debug this yet. (not yet on any list I'm aware of) 3) Removal of 32 bit support. Finally! (T67184) Libs Longer term: I've heard from multiple devs that dealing with deps is a pain, they just randomly sprinkle includes and linker commands until the errors go way, that's a great use of their time. While moving all of blender to a modern target based cmake style may be out of reach, I think we can do this for the deps integration without causing too much trouble. (not yet on any list i'm aware of) --Ray [1] https://devblogs.microsoft.com/cppblog/announcing-jmc-stepping-in-visual-studio/ On 2019-07-26 12:00 a.m., Dalai Felinto wrote: > Dear developers, > > Which areas would you like to focus on in the next few months? Which > code improvements, performance, stability, new features in those areas > would you work on first [1]? > > Finally which bigger new features are you confident would make it in > the 2.81 release, and which are the ones that might happen? These are > particularly important so we can allocate more time for code review > early in the release cycle and work together to assess their > feasibility. > > That should empower us to set priorities and keep our ongoing > development on track. The original goal of a more strict 2-3 month > release cycle is still on the table, and it is up to us to set dates > the deliverables. As long as we are working in the right priorities, > and strive for quality, which specific features land in 2.81 are > secondary. > > I'm away for Siggraph (28-1) so there is no need to rush to reply to this. > > [1] - Please update the module page to reflect this - > https://wiki.blender.org/wiki/Modules / > https://developer.blender.org/T63725 > > Best regards, > Dalai > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
