[Bf-committers] Bump MacOS minimum requirements to 10.15 for Blender 3.5
Hello all, A few weeks ago we enabled the Metal back-end for the viewport. By default Blender will start using OpenGL, but in the User preferences the Metal backend can be enabled. The first responses and test are very positive and currently it is very likely that Metal will be released as a secondary backend in Blender 3.5. Currently Master is only able to build on MacOS 10.15 and above due this change. The current minimum requirement is MacOS 10.13. So there are some options to consider here. * Do we release blender 3.5 with Metal Backend? * Do we bump the minimum version from 10.13 to 10.15 for Blender 3.5? * Add logic in many places to make sure that 10.15 code-paths aren't used when run in 10.13? Sergey mentioned that there are already ideas to bump the version to 10.15 for Blender 3.6. So this proposal is to do this one release earlier. My proposal would be to do the version bump for Blender 3.5 due to these reasons. Would like to have some feedback if this is acceptable. Jeroen. ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Buildbot status
Hi all, The last few days the buildbot was down and had some issues to start again. Good news is that the buildbot should work again. So daily builds should be available tomorrow. Jeroen ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] JSON/YAML parsing in CPP
Hey Ray, thanks for the clarification on the platform module. I did a quick search and couldn't find this on wiki or phabricator. I think it would be a good idea to share it somewhere as it could optimize the workflow for devs. I have no strong preferred solution, as long as I am able to store and read structured data to something that is somewhat human readable for debugging and or TD tooling. I didn't consider pugixml, but could also work and is already available. On the plus side xml has better validation and querying facilities, on the down side it is xml... :-) Will check with the admins... Jeroen. On Wed, Sep 15, 2021 at 5:19 PM Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: > My official position is : The platform module is > not in the business of making library recommendations, > or deciding what library does or doesn't go into blender. > > As long as the admins are willing to sign off on it, > we'll build any library you want, with whatever options > you require. When the render module goes "hey we need > the vulkan SDK" it's really not our place to go "lol > no! Go write a DX12 or Metal back-end instead". A module > has a need and it's the platform modules job to > support that need to ensure their success. > > Once a decision to gain an additional dependency has been > made, we'll go out of our way to ensure a smooth landing > in the blender Eco-system, no need to concern your self > with platforms, compiler flags, linkers or build systems, > we got this! Once we're done the module should just be able > to #include "libfoo.h" and be on their way. > > In short, the platform module is essentially a service > module to empower the other modules to do their work > with the least amount of distractions from the platform > side of things. However your needs are your needs, building > libfoo vs building libbar it's honestly all the same to us. > > So with that said and hopefully clarified that my personal > opinion on this subject should hold no more value than > any other blender contributor. > > "I need a Yaml, or Json library" from the tone of > your email you don't really seem to care what format > one or another, would you accept XML? we already have > and ship pugixml, opinions may be divided here but I'd > rate XML human readable. We could bump it from optional > to required with virtually no work. > > T91430 seems to hint that you'd like a C++ API, if that's > the case nlohmann's library [1] is by far the most pleasant > library I've used. rapidjon or simdjson (read-only) may have > the performance edge, but there's something to be said for good looking > maintainable code especially if we're not going to end up parsing > gigabytes of json. > > Whatever you decide on doing, I understand time is of > the essence, and I will make myself available to make > whatever option you chose available to you as quickly > as possible. > > --Ray > > [1] https://github.com/nlohmann/json > > On 2021-09-15 3:22 a.m., Jeroen Bakker via Bf-committers wrote: > > Hi All, > > > > For the asset browser we would like to store an index per asset file > > (.blend file inside an asset library) to reduce the overhead of showing > > assets in the asset browser. > > > > The high level solution we are thinking of is to store an index file next > > to the asset file that can be read quickly to find out what assets are > > inside the file. The challenge I want to address is the used data format > of > > that file. We prefer these supporting files to be human readable, but the > > structure can be complex. From this point of view we are looking for > > YAML/JSON. > > > > Currently we don't have a YAML/JSON parsing library in our core. As we > want > > to add indexing still as part of Blender 3.0 we might have a timing > issue. > > > > In https://developer.blender.org/T91430 2 valid options are desribed. > > - use a header only JSON parser. > > - use cpp-yaml that is already used by OCIO/OIIO and make it a hard > > dependency. > > > > T91430 also mentions an abstration to switch implementations if needed. > > > > We would like to have discussion/feedback from the platform maintainers > to > > see what would be a valid option for inclusion of asset indexing in > Blender > > 3.0. > > > > Jeroen > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > List details, subscription details or unsubscribe: > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] JSON/YAML parsing in CPP
Hi All, For the asset browser we would like to store an index per asset file (.blend file inside an asset library) to reduce the overhead of showing assets in the asset browser. The high level solution we are thinking of is to store an index file next to the asset file that can be read quickly to find out what assets are inside the file. The challenge I want to address is the used data format of that file. We prefer these supporting files to be human readable, but the structure can be complex. From this point of view we are looking for YAML/JSON. Currently we don't have a YAML/JSON parsing library in our core. As we want to add indexing still as part of Blender 3.0 we might have a timing issue. In https://developer.blender.org/T91430 2 valid options are desribed. - use a header only JSON parser. - use cpp-yaml that is already used by OCIO/OIIO and make it a hard dependency. T91430 also mentions an abstration to switch implementations if needed. We would like to have discussion/feedback from the platform maintainers to see what would be a valid option for inclusion of asset indexing in Blender 3.0. Jeroen ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patches for 2.93 LTS
Hello everyone, Blender 2.93 has been out for almost 3 months (2nd jun 2021), has received 4 releases so far and one is in the making. The first number of releases we allow smaller fixes that would normally also be added to corrective releases. Normally this period would end when the next version of blender is in BCON 4 as then our user base also switches to the upcoming blender version. The consequence that we currently are seeing is that we were almost releasing a blender release every week (2.83/2.93) and that takes away time from the people who are managing, executing or communicating about the releases. To mitigate the time spent on releasing we want to be more strict on the patches that will be included in 2.93 from now on and not wait for BCON4 to happen. As a reminder fixes should be high-prios or critical issues (these include platform support issues). These issues can directly be added to the maintenance task for 2.93 (https://developer.blender.org/T88449). If you're not certain if a fix falls inside the criteria, please contact me in blender.chat and we see how to handle it. We will handle it with the same flexibility as we did for 2.83. With these changes we target to release 2/3 LTS versions per month. One 2.83 release and one or two 2.93 releases depending on the amount of fixes available. Jeroen. ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Harmonious collaboration - reverting commit process
A common reason why I revert commits is that submodules were changed by mistake. Is reverting a good solution? Perhaps worth mentioning. Jeroen On Wed, Jun 9, 2021 at 12:55 PM Sergey Sharybin via Bf-committers < bf-committers@blender.org> wrote: > Hi, > > Today I continued to update the development process guidelines and policies > on the Wiki. This is based on previous discussions with the other > bf-admins, and I'm working with Dalai on the final text adjustments. So > today we handled the "polemic" topic of reverting commits: > https://wiki.blender.org/wiki/Process/Revert_Commit > > Feedback and suggestions are welcome. > > Please note that we do read the feedback you are giving. Currently we are > focusing on finishing the first pass of the process update. We will then > look into addressing your feedback to make the development process fun and > smooth! > > Best regards, > - Sergey - > > Sergey Sharybin - ser...@blender.org - www.blender.org > Principal Software Engineer, Blender > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.93 release AHOY
Hi, The Blender 2.93 release is on track for release on Wednesday 2nd June * As of now, do not commit to `blender-v2.93-release` branch without clearing up with Dalai or me directly. * From 9:00 to 10:00 CET we will do a final pass in the tracker to see if there are any showstoppers. * Subversion bump and final tagging will be handled by me. * The plan is to start the build process Wednesday night CET. For anything release related join #blender-coders on blender.chat. Thank you, Jeroen ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] (no subject)
Hi, The Blender 2.93 release is on track for release on Wednesday 2nd June * As of now, do not commit to `blender-v2.93-release` branch without clearing up with Dalai or me directly. * From 9:00 to 10:00 CET we will do a final pass in the tracker to see if there are any showstoppers. * Subversion bump and final tagging will be handled by me. * The plan is to start the build process Wednesday night CET. For anything release related join #blender-coders on blender.chat. Thank you, Jeroen ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Planning Blender 2.91.1 Release
Hi all, Last Monday it was announced to do a 2.91.1 release this week. I do think this is a bit to early as I didn't had time to do the backports due to other activities. I would strive for a release next week. See here the overall planning. * Until Sunday 17 January every module can go over the list of commits (https://developer.blender.org/T83216) that needs to be backported to 2.91.1 release. * On Monday 18 January I will perform the backports to the blender-v2.91-release branch. * On Wednesday 20 January we can release 2.91.1 Regards, Jeroen ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting notes - 2021.01.11
Hi all I don't mind doing it. It is just strange that on Monday there is an announcement that we do the release on Wednesday. Also during the rendering meeting it was mentioned that the list should be checked and updated. I will send an official email to the mailing list with the planning for 2.91.1 Jeroen On 12-01-2021 22:43, Dalai Felinto via Bf-committers wrote: Hi Jeroen, I would propose to clean up the task list and perform the backports this week. Compared to the previous corrective releases I don't find the number of commits (33) absurd. For comparison: * 2.90.1 had 39 commits [1] * 2.83.1 had 33 commits [2] * 2.82a had 25 commits [3] * 2.81 had 13 commits [4] * 2.79a had 202! commits [5] All the commits for 2.91.1 were suggested by developers actively involved in the project. So I would rather we try to trust their judgment and apply them all. That said it is not hard to cherry-pick the most pressing fixes (crashes and regressions) while leaving some good-to-have behind (transform tools and uv pin drawing). But I don't see the ultimate benefit of doing that, all considered. [1] - https://wiki.blender.org/wiki/Reference/Release_Notes/2.90/Corrective_Releases [2] - https://www.blender.org/download/lts/ [3] - https://wiki.blender.org/wiki/Reference/Release_Notes/2.82/a [4] - https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/a [5] - https://wiki.blender.org/wiki/Dev:Ref/Release_Notes/2.79/a Op di 12 jan. 2021 om 18:44 schreef Dalai Felinto : Hi, Status update on the pending 2.92 projects: Sculpting: - All the new tools have icons now. Geometry Nodes - Still a target for 2.92. - A few nodes are still planned to be merged by Wednesday. Asset Manager - Will be moved to the Experimental features, which means it won't be available for the beta and final builds. - It miss the asset bundle (T55239) and some polishing/known todos. - Part of the initial feedback shows that some users may be confused on how to create assets and repositories. Regards, Dalai Op di 12 jan. 2021 om 14:20 schreef Jeroen Bakker via Bf-committers < bf-committers@blender.org>: Hi, A release this week is a bit to early. There are some patches that needs to be in that were only committed this Monday. I would propose to clean up the task list and perform the backports this week. And release next week. As I quickly counted there are not that many crashes, but there are regressions. Jeroen. On 11-01-2021 11:38, Bastien Montagne via Bf-committers wrote: Hi, Notes for meeting of Monday, 11 January 2021. 11:00 CET / UTC 10:00 on [#blender-coders](https://blender.chat/channel/blender-coders) on blender.chat. # Announcements ## Corrective Blender 2.91.1 Release It is schedule for this Wednesday 13th. Jeroen Bakker will handle the release, in coordination with Dalai Felinto. The [list of commits](https://developer.blender.org/T83216) is growing a little bit too much... Probably needs some review pass? ## Blender 2.92 BCon3 for 2.92 release should happen this week on Wednesday 13th. Dalai Felinto will go over the 2.92 tasks, but so far there are still a lot of open ones for features, missing icons, etc. All developers are encouraged to go over the workboard and address or re-assign tasks to next 2.93 release (as a reminder, after BCon3 we should only have bug tasks tagged for 2.92). Things like missing icons must be tackled, otherwise we'll have to revert corresponding features. Also Asset Browser and Geometry Nodes will need to be evaluated to check if they are ready. Dalai Felinto will coordinate final decisions there in next two days. * Julian Eisel would rather hide Assets Browser in the 'experimental features' for 2.92 release, it needs a lot more polishing, fixing, and even some design decisions may need to be re-evaluated. * Jacques Lucke notes that the Geometry Nodes sprint planning is postponed to Tuesday 12th. Status for 2.92 will be evaluated there. # Google Summer of Code 2021 Application for organizations [opens on January 29th](https://summerofcode.withgoogle.com/how-it-works/), but all developpers are already welcomed to update the [ideas page](https://wiki.blender.org/wiki/GSoC/Ideas_Suggestions). Cheers, Bastien ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers -- -Dalai- Dalai Felinto - da...@blender.org - www.blender.org Blender Development Coordinator Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting notes - 2021.01.11
Hi, A release this week is a bit to early. There are some patches that needs to be in that were only committed this Monday. I would propose to clean up the task list and perform the backports this week. And release next week. As I quickly counted there are not that many crashes, but there are regressions. Jeroen. On 11-01-2021 11:38, Bastien Montagne via Bf-committers wrote: Hi, Notes for meeting of Monday, 11 January 2021. 11:00 CET / UTC 10:00 on [#blender-coders](https://blender.chat/channel/blender-coders) on blender.chat. # Announcements ## Corrective Blender 2.91.1 Release It is schedule for this Wednesday 13th. Jeroen Bakker will handle the release, in coordination with Dalai Felinto. The [list of commits](https://developer.blender.org/T83216) is growing a little bit too much... Probably needs some review pass? ## Blender 2.92 BCon3 for 2.92 release should happen this week on Wednesday 13th. Dalai Felinto will go over the 2.92 tasks, but so far there are still a lot of open ones for features, missing icons, etc. All developers are encouraged to go over the workboard and address or re-assign tasks to next 2.93 release (as a reminder, after BCon3 we should only have bug tasks tagged for 2.92). Things like missing icons must be tackled, otherwise we'll have to revert corresponding features. Also Asset Browser and Geometry Nodes will need to be evaluated to check if they are ready. Dalai Felinto will coordinate final decisions there in next two days. * Julian Eisel would rather hide Assets Browser in the 'experimental features' for 2.92 release, it needs a lot more polishing, fixing, and even some design decisions may need to be re-evaluated. * Jacques Lucke notes that the Geometry Nodes sprint planning is postponed to Tuesday 12th. Status for 2.92 will be evaluated there. # Google Summer of Code 2021 Application for organizations [opens on January 29th](https://summerofcode.withgoogle.com/how-it-works/), but all developpers are already welcomed to update the [ideas page](https://wiki.blender.org/wiki/GSoC/Ideas_Suggestions). Cheers, Bastien ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patching the manual as a team responsibility
Hi all, In the geometry nodes project we are using the scrum methodology. We are currently performing a sprint that will commit new multiple small features to master. As part of this we are updating the manual. In the non-scrum way of development the developer who is responsible for a patch can use a local branch/or copy for keeping track of changes to bf-manual and pushes the changes together with the patch. Using the scrum methodology the patches are a team responsibility and therefore updating the manual is also a team responsibility. We would like to update the manual side by side to the patches that land to make sure that the manual is in sync with master. The manual is hosted on SVN what doesn't (have good) support for distributed version control. In the short term we created a git repository hosted outside of blender.org with the main reason to not confuse manual writers. Using the scrum methodology with blender projects is still experimental, but if it is successful more projects could adopt this methodology. It would be good to know if the chosen solution is fine for the short term (as part of the experiment). What might be issues that other writers would see with our chosen solution? In the longer run we could see if we want to do some changes to our current infrastructure. Taken into account the community efforts on updating the manual and therefore the tactically choice to host the manual in SVN. Regards, Jeroen Bakker. ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] v2.90.0 retagged
Hi all, During the process of releasing 2.90 I had to retag. To make sure all your local tags are in sync with the server run: $ git fetch --tags --force Thank you, Jeroen ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
