[Bf-committers] CMake cleanup
All, As some of you have possibly noticed, I have been making some changes/cleanups to our build system, some new and foreign concepts to some may have shown up. I was planning to send an update about this once the work was completed, but several community members have reached with various levels of confusion and/or venom, so I’ll just go ahead and send an update now. As it is quite a read and may cause some Q you can find the full text on devtalk over at: https://devtalk.blender.org/t/cmake-cleanup/30260 If you have questions/comments/suggestions, please reach out on devtalk, or if you'd rather not reach out publicly feel free to reach to me out on blender.chat Greetings, Ray ___ 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] Handling of user data.
Ton, It's been nearly a year and we're seemingly still hurting people [1] you're a clever one! you only said it deserved priority, not that it would actually get priority, i fell for that one! I don't see this realistically happening for 3.6, but please I beg you, make it a prio for 4.0 this really has got to stop. Greetings, Ray [1] https://www.reddit.com/r/blender/comments/12f8nh9/omg_spent_hours_texture_painting_and_its_gone_any/ On 2022-05-13 7:09 a.m., Ton Roosendaal via Bf-committers wrote: > Hi Ray, > >> deleting the users data without their consent >> isn't OK, has never been OK, will never be OK, > > Fully agree with that. > > The list of critical issues is way too long. But this deserves top priority > for fixing. > > -Ton- > > -- > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation, CEO Blender Institute / Studio > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > On 12/05/2022 22:17, Ray Molenkamp via Bf-committers wrote: >> I don't think there's any disagreement between me and bastien >> we both agree it's a problem that just isn't getting the >> attention it deserves. The disagreement is with the people who >> set the priorities. >> >> Most of the priories are seemingly set by the needs of the >> blender studio, they have learned a long long time ago, how >> to "not lose data" to the point it has seemingly become a >> out of sight out of heart style problem. >> >> My somewhat cheeky prod on the mailing list was meant as >> a reminder, deleting the users data without their consent >> isn't OK, has never been OK, will never be OK, and we should >> be fixing it rather than waving it away going "it's fiiine, >> work on this instead" it's very much not "fine" >> >> --Ray >> >> >> >> On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote: >>> Hi, >>> >>> I'm also curious about this issue. It seems like Ray is giving one side of >>> the argument, but I'm not clear on the other side. This can't simply be a >>> debate between one group that is in favor of destroying user data, and >>> another group that opposes it. >>> >>> Looking at the developer task, it seems like one concern is that any >>> solution to the problem would need to take account of workflow issues, so >>> that production workflows won't be slowed down. I'd like to hear an example >>> of a production workflow that relies on blender's current behavior, and how >>> it might be slowed down if the data were simply not deleted instead. >>> >>> There definitely seems to be something to what Ray says, about saving users >>> from a data-loss baptism of fire. And there also seems to be something to >>> what Bastien says, about various big projects that currently have a higher >>> priority than fixing a standard blender behavior that has always been this >>> way. I know there are a lot of features I eagerly look forward to, more >>> than fixes for some of the known misfeatures. But I also know that I got >>> bit by the inexplicable data-loss issue myself at first, and it was a pain >>> in the butt. >>> >>> Could someone take a stab at explaining what this debate really is about, >>> in such a way that both sides would feel fairly represented? All I know >>> right now is that there's a disagreement about something that currently >>> feels over my head. >>> >>> Be well, >>> Zack >>> >>> >>> >>> >>> >>> On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < >>> bf-committers@blender.org> wrote: >>> >>>> That task is over 3 years old though, it mostly reconfirms >>>> the notion that the people who set the priorities just >>>> don't see silently destroying end user data being a problem. >>>> >>>> I hope this short thread serves as a wake-up call and this >>>> and the other core improvements you mentioned will be made >>>> more of a priority and time will actually be allocated for >>>> it in the next release cycle. >>>> >>>> But I'm not getting my hopes up here. >>>> >>>> --Ray >>>> On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: >>>>> Hi Ray, >>>>> >>>>> We already have a task to address this issue: >>>>> >>>>>
Re: [Bf-committers] Bump MacOS minimum requirements to 10.15 for Blender 3.5
I have to admit, I don't have a whole lot of experience with macs, I have honestly no idea of the real-world impact of a version bump. However, given we committed to follow the VFX platform for 2023/2024 which targets 11.0 for 2023 shouldn't we either : a) Follow the VFX platform and Target 11.0 b) Have some rationale documented somewhere why we are deviating from the VFX platform by targeting 10.13 or 10.15. Following the VFX platform for just the things we liked (ie we follow it!. but not for the python version) hasn't worked out overly well for us in the past, and I’d rather not repeat that phase of our commitment to the VFX platform, so my naive grasp of the situation has me leaning towards option a. --Ray On 2023-01-05 8:26 a.m., Brecht Van Lommel via Bf-committers wrote: > I think it's reasonable to do the bump now, instead of 3 months from now > when we definitely have to do it. And doing it together with the VFX > platform updates and new Linux minimum requirements makes some sense. > > It's always unfortunate to leave behind hardware, but even macOS 10.15 is > already EOL and no longer receiving updates. > > On Thu, Jan 5, 2023 at 4:10 PM Jeroen Bakker via Bf-committers < > bf-committers@blender.org> wrote: > >> 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 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
Re: [Bf-committers] move prebuilt libs from svn to git?
Except for you just now i don't think anyone is questioning the need for version control on the 3rd party dependencies. This tree was there long before i joined the blender project so can't give any insights on any controversy in creating it. However whenever this subject (why svn) comes up, it tends to be one or both of these scenario's 1) svn is giving people a hard time, calling it "quirky" would be generous, it doesn't recover nicely whenever it runs into trouble, and with the large size of the libraries and the slow download speeds for some people it's just bound to run into trouble. And these people rightfully question "Why is it like this?" 2) SVN is old, everything uses git these days it's the hip and trendy new kid on the block. they never have these kinds of issues with git! why is blender being so silly, just use git! on the other hand, no-one is using pure git to manage a large collection of binaries since it is just not designed for this job, in much the same way the hand basket at your local hardware store is not designed to pick up that 25kg bag of cement. git-lfs is one of the proposed solutions, but also not free of problems [1] (written by the maintainer of an different version control system, be aware of "some" bias there) Yet another alternative is to go, 3rd party dependencies are no concern of us, developers can go obtain/build these on their own. This is the stance taken by the majority of opensource projects. And I'll admit, as one of the people responsible for the contents of this repository I can't help feeling some envy there, maintaining the libs and guaranteeing a smooth experience for developers is *VERY* time consuming. However seeing new people join the blender project going "building blender was much easier than I expected, I finished my small first patch fixing something that had been bothering me in under a day" negates those feelings and makes me realize as a project the blender project is better for everyone by having these libs available. SVN is what we have and it's mostly working for us there's alternatives but there's a lot more nuance to it than "just use X I never have problems with X" [1] https://gregoryszorc.com/blog/2021/05/12/why-you-shouldn%27t-use-git-lfs/ On 2022-06-18 11:24 a.m., Zack Brown wrote: > Thanks, I appreciate the explanation. It still seems weird. I'm sure the > original conversation that led to this particular svn tree must have involved > some amount of controversy. > > But at this point in the project's history there's definitely something to be > said for "if it ain't broke, don't fix it." Especially with so many amazing > blender features in rapid development. > > Be well, > Zack > > > On Sat, Jun 18, 2022 at 6:45 PM Ray Molenkamp wrote: > > libraries change over time, sometimes they have large api changes > where we have to do reintegration work into blender. > > Which then leads to, if we have a single folder with libs, what > do the 2 concurrent LTS releases use? that same lib folder? they > need major rework to use them, we can't land rework in an lts release > brand new bugs will likely come with it. option b: well we'll give > every release their own folder on that shared drive so they won't have > issues when the libs change. > > wait a minute... we've just reinvented version control :) > > --Ray > > On 2022-06-18 1:04 a.m., Zack Brown wrote: >> Hi everyone, >> >> It's fascinating to see this discussion. It never occurred to me that >> anyone might continue to prefer svn once git came into existence, and yet >> here is a sample case, right under my nose! I guess svn is still relevant >> even after all these years! >> >> But actually I'd be curious to know why revision control is used at all >> in this particular case. We're talking about precompiled binaries, right? >> That's sort of the poster child for situations where revision control is >> *not* what one wants, exactly for the reason why git would be a bad choice. >> >> Please, could someone explain why the blender project doesn't simply use >> a dev-accessible shared folder somewhere? I love revision control, but it's >> only useful if it's useful. >> >> Be well, >> Zack > > ___ 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] move prebuilt libs from svn to git?
Just an update with some new numbers, dan's changes brought down the time for a full clone from my home connection down to 5m48s (down from 27m39s previously) well done dan! --Ray On 2022-06-17 3:45 p.m., Dan McGrath wrote: > Just a heads-up that Ray and I took a packet capture on both ends for me. > > Thanks to his capture, I noticed that the SVN server host was not sending TCP > window scale or SACK options. Ultimately this turned out to be due to that > host using the PF firewall "synproxy" state option, which apparently was > causing the TCP header options to be removed, which limited the window size > to 64k. > > I have corrected this change to match the www host, and we did observe some > improvements that were hidden from me before due to my and the studio IPs > special treatment that bypassed this feature. > > While it should help, I also tuned a few sysctl settings for send and receive > buffers. In addition, I noticed that the SVN server is also not sending > gzip/deflate accept headers for the files. No doubt this is going to be a > factor. However, there was a note from 2016 from myself explaining that > Brecht asked for the SVN compression to be disabled due to some client > problems. So, this will require some research, perhaps next week. > > Anyway, hopefully it helps a bit until I can review some more settings. > > Enjoy your weekend everyone! > > > Dan > > On Fri, Jun 17, 2022, 2:22 PM Ray Molenkamp via Bf-committers > wrote: > > =8<==[Editors note]=8<== > I'll be honest I'm 100% convinced mailinator will ruin > the little formatting I have done, I put a copy of this > email on https://developer.blender.org/P3014. > =8<8<8<8<== > > How much as I like the sentiment of "lets move to git will it > solve all these problems" lets be honest here, git.blender.org > <http://git.blender.org>'s > speed is nothing to write home about either it may or may not be > as glitchy as svn, but it still wouldn't be fast. > > from my 300mbit connection in western Canada > > Receiving objects: 6% (135931/2078159), 33.34 MiB | 458.00 KiB/s > > total time for a clone off git.blender.org <http://git.blender.org> 27m39s > > Cloning off https://github.com/blender/blender.git however > > total time for a clone off github.com <http://github.com> 1m 52s > > Now amount of finger pointing to client settings will convince me > it's a client setting at this point, but I'll be honest, I am all > the way in western Canada and that could definitely be a factor. > > so, lets investigate! > > Let’s spin up an AWS EC2 instance in London, I'd say that be close > enough to Amsterdam, and let’s rule out any other CPU or Bandwidth > related factors as well, I threw a few dollars at it and got a > cn5.18xlarge instance (72 CPU’s 192gb memory, 100gbit ethernet) > overkill to do a git/svn test? yes.. yes indeed > > first to rule out the blender.org <http://blender.org> servers lets grab > a ubuntu iso > off an .nl mirror ( > https://mirror.nl.datapacket.com/ubuntu-releases/22.04/ ) > > 2022-06-17 17:13:21 (232 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved > [3654957056/3654957056] > > all right bandwidth is NOT going to be an issue on this box! > > On to blender stuff: > > cloning from git.blender.org <http://git.blender.org> 2m32.895s > svn checkout of lib/win64_vc15 2m56.388s (iftop said 65Mbit peak rate) > > yowza! > > All right, so in London, safe to say all is well > > lets move closer to my location, us-east-2 Ohio (same instance type and > os) > > grabbing ubuntu from that same mirror > > 2022-06-17 17:31:00 (29.5 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved > [3654957056/3654957056] > > all right, that has lost quite a bit of steam, but it's > still nothing to sneeze at, just to be sure lets grab > an iso off the Princeton university mirror 120MB/s ok.. > good enough... > > onto cloning blender > > Receiving objects: 5% (104235/2078173), 25.44 MiB | 692.00 KiB/s > > well... that's not looking promising... lets wait it out > > cloning from git.blender.org <http://git.blender.org> 17m23.449s > > sadface... lets try svn next, i lost patience and did not let > it finish.. iftop reported a top RX of 5.59Mbit though.. > > To summarize: > > Ubuntu iso from mirror.nl.datapacket.com > <http://mirror.nl.datapacket.com> (Speed taken from wget) > My home - western Canada - 1.3 MB/s >
Re: [Bf-committers] move prebuilt libs from svn to git?
=8<==[Editors note]=8<== I'll be honest I'm 100% convinced mailinator will ruin the little formatting I have done, I put a copy of this email on https://developer.blender.org/P3014. =8<8<8<8<== How much as I like the sentiment of "lets move to git will it solve all these problems" lets be honest here, git.blender.org's speed is nothing to write home about either it may or may not be as glitchy as svn, but it still wouldn't be fast. from my 300mbit connection in western Canada Receiving objects: 6% (135931/2078159), 33.34 MiB | 458.00 KiB/s total time for a clone off git.blender.org 27m39s Cloning off https://github.com/blender/blender.git however total time for a clone off github.com 1m 52s Now amount of finger pointing to client settings will convince me it's a client setting at this point, but I'll be honest, I am all the way in western Canada and that could definitely be a factor. so, lets investigate! Let’s spin up an AWS EC2 instance in London, I'd say that be close enough to Amsterdam, and let’s rule out any other CPU or Bandwidth related factors as well, I threw a few dollars at it and got a cn5.18xlarge instance (72 CPU’s 192gb memory, 100gbit ethernet) overkill to do a git/svn test? yes.. yes indeed first to rule out the blender.org servers lets grab a ubuntu iso off an .nl mirror ( https://mirror.nl.datapacket.com/ubuntu-releases/22.04/ ) 2022-06-17 17:13:21 (232 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved [3654957056/3654957056] all right bandwidth is NOT going to be an issue on this box! On to blender stuff: cloning from git.blender.org 2m32.895s svn checkout of lib/win64_vc15 2m56.388s (iftop said 65Mbit peak rate) yowza! All right, so in London, safe to say all is well lets move closer to my location, us-east-2 Ohio (same instance type and os) grabbing ubuntu from that same mirror 2022-06-17 17:31:00 (29.5 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved [3654957056/3654957056] all right, that has lost quite a bit of steam, but it's still nothing to sneeze at, just to be sure lets grab an iso off the Princeton university mirror 120MB/s ok.. good enough... onto cloning blender Receiving objects: 5% (104235/2078173), 25.44 MiB | 692.00 KiB/s well... that's not looking promising... lets wait it out cloning from git.blender.org 17m23.449s sadface... lets try svn next, i lost patience and did not let it finish.. iftop reported a top RX of 5.59Mbit though.. To summarize: Ubuntu iso from mirror.nl.datapacket.com (Speed taken from wget) My home - western Canada - 1.3 MB/s AWS - London - 232 MB/S AWS - Ohio - 29.5 MB/s Clone of git.blender.org (time taken from linux time command) My home - western Canada - 27m39 AWS - London - 2m32 AWS - Ohio - 17m23 SVN Clone: (peak RX bitrate taken from iftop) My home - western Canada - 1.5 Mbit/s AWS - London - 64 Mbit/s AWS - Ohio - 5.59 Mbit/s Think the only thing we really can conclude is that being further from the server is leading to an "unhappy" time for the developer. Given the fact the EC2 instances were 100% identical between London and Ohio, it's unlikely to be a client configuration issue. --Ray On 2022-06-17 10:10 a.m., Dan McGrath via Bf-committers wrote: > Hi, > > Really, I would need to see a capture from both sides to dig into it. I > need to see what is being sent, and what is received on each side. There > could be some weird firewall stuff happening that is causing fragmentation > or blocking TCP options, or window scaling issues, etc. > > As for the default settings for tortoisesvn, the connection stuff I was > referring to was about TCP/IP behaviour, rather than an application > setting. Either way, I need to see what is actually happening. The fact > that I can pull 5-8MB/sec (~40mbit) from Canada and not have a single > interruption is telling. Granted, the host only has around 100 or 200mbit > allocated, iirc. Multiply that by a few dozen people and you have a problem. > > For a simpler test, maybe try a large svn check, perhaps some old FreeBSD > ports svn repo if you can find one, something also in .NL, and see how it > goes, just to help eliminate your PC/firewall. Worst case scenario, you can > also poke me in chat and we can try some server side and client side > captures. > > TBH though, 1gig uplink just isn't a whole lot to serve our user base ;) > > On Fri, Jun 17, 2022 at 11:45 AM Tom M wrote: > >> On Fri, Jun 17, 2022 at 5:20 AM Dan McGrath >> wrote: >>> Hi Tom, >>> >>> Long time no see :) >>> >>> I did some tests from home and found that, aside from slow speeds, I was >> able to checkout at least 5 or 6 gig of the bf-blender repo without error >> or having to retransmit. >> >> Yeah, looks like I was mistaking really slow download of the larger >> (.7 GB) libraries as freezing. I was averaging about .3 MB/s. I used >> a different SVN client and saw that it was indeed downloading (the >>
Re: [Bf-committers] Handling of user data.
The core team has bought blender to where it is today, they seem to have a pretty good handle on things. I'm not sure design by committee on bf-c is what this problem was lacking. Just give 'm time, guys, they got this. --Ray On 2022-05-17 6:19 p.m., Harley Acheson via Bf-committers wrote: >> The Idea being to put all of the unlinked stuff into some trash can of > sorts... > > That is what we would have if we would simply just save everything, with > your "trash can" > just being the items that have zero users. Then you can choose, at any > time, to remove > those items. > > These two approaches to data - only save things that are in use except for > items the user > has explicitly marked, versus saving all user data and allowing them to > delete what they > want - are not symmetrical. The former creates an emergency at the point > of exit that we > will not be able to fix with warnings. The latter removes that emergency > and allows the user > to deal with it at leisure. > > I have heard the argument that "OMG, this will make our files bloat". But > you can turn such > a "bloated file" into one without saved orphans with the currently existing > "purge orphans" > operator. You can run this all the time, make it an option to run on save, > or never run it. But > it leaves this to you to deal with when you want, not done *for *you. > > With the thought of (slowly) moving toward saving orphan data, the > following experimental > patch replaces the current File / Clean Up menu of items with a single > "Clean Up" dialog > that can be used remove orphans, set all orphans to fake user, or to bring > up a window > with Outliner set to "Orphan Data" mode so you can manage them granularly. > > https://developer.blender.org/D14030 > > Harley > ___ > 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
Re: [Bf-committers] Handling of user data.
I don't think there's any disagreement between me and bastien we both agree it's a problem that just isn't getting the attention it deserves. The disagreement is with the people who set the priorities. Most of the priories are seemingly set by the needs of the blender studio, they have learned a long long time ago, how to "not lose data" to the point it has seemingly become a out of sight out of heart style problem. My somewhat cheeky prod on the mailing list was meant as a reminder, deleting the users data without their consent isn't OK, has never been OK, will never be OK, and we should be fixing it rather than waving it away going "it's fiiine, work on this instead" it's very much not "fine" --Ray On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote: > Hi, > > I'm also curious about this issue. It seems like Ray is giving one side of > the argument, but I'm not clear on the other side. This can't simply be a > debate between one group that is in favor of destroying user data, and > another group that opposes it. > > Looking at the developer task, it seems like one concern is that any > solution to the problem would need to take account of workflow issues, so > that production workflows won't be slowed down. I'd like to hear an example > of a production workflow that relies on blender's current behavior, and how > it might be slowed down if the data were simply not deleted instead. > > There definitely seems to be something to what Ray says, about saving users > from a data-loss baptism of fire. And there also seems to be something to > what Bastien says, about various big projects that currently have a higher > priority than fixing a standard blender behavior that has always been this > way. I know there are a lot of features I eagerly look forward to, more > than fixes for some of the known misfeatures. But I also know that I got > bit by the inexplicable data-loss issue myself at first, and it was a pain > in the butt. > > Could someone take a stab at explaining what this debate really is about, > in such a way that both sides would feel fairly represented? All I know > right now is that there's a disagreement about something that currently > feels over my head. > > Be well, > Zack > > > > > > On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < > bf-committers@blender.org> wrote: > >> That task is over 3 years old though, it mostly reconfirms >> the notion that the people who set the priorities just >> don't see silently destroying end user data being a problem. >> >> I hope this short thread serves as a wake-up call and this >> and the other core improvements you mentioned will be made >> more of a priority and time will actually be allocated for >> it in the next release cycle. >> >> But I'm not getting my hopes up here. >> >> --Ray >> On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: >>> Hi Ray, >>> >>> We already have a task to address this issue: >>> >>> https://developer.blender.org/T61209 >>> >>> But this needs time to be properly handled, and these days we spend >> everything besides regular maintenance on 'big projects', so... this one >> and several other relatively small core improvements and fixes keep being >> delayed from one release to the other. >>> -- Bastien >>> >>> On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: >>>> All, >>>> >>>> It's been years [1] (2018) since I last was rather >>>> vocal on this subject, but how is this [2] still >>>> happening? "Yes, blender deleted your data (and silently >>>> at that), that means it's working correctly!" cannot >>>> possibly be the best we can do, is it? >>>> >>>> While I'm excited with all the directions blender >>>> development is currently going, it's utterly depressing that >>>> users are still losing data on a daily basis because >>>> we can't quite get the basics right like "do not delete the >>>> users data without their consent". >>>> >>>> These are *NOT* isolated incidents [3]. Losing your >>>> data and learning about "the fake user" shouldn't be >>>> a right of passage to become "a real blender user". >>>> Users shouldn't be silently *losing* data in an operation >>>> ironically called *saving*. That's crazy, no other >>>> application behaves like this! >>>> >>>> Yes, I know this is how we have always done it. No, >>>> this is not OK, n
Re: [Bf-committers] Handling of user data.
That task is over 3 years old though, it mostly reconfirms the notion that the people who set the priorities just don't see silently destroying end user data being a problem. I hope this short thread serves as a wake-up call and this and the other core improvements you mentioned will be made more of a priority and time will actually be allocated for it in the next release cycle. But I'm not getting my hopes up here. --Ray On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: > Hi Ray, > > We already have a task to address this issue: > > https://developer.blender.org/T61209 > > But this needs time to be properly handled, and these days we spend > everything besides regular maintenance on 'big projects', so... this one and > several other relatively small core improvements and fixes keep being delayed > from one release to the other. > > -- Bastien > > On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: >> All, >> >> It's been years [1] (2018) since I last was rather >> vocal on this subject, but how is this [2] still >> happening? "Yes, blender deleted your data (and silently >> at that), that means it's working correctly!" cannot >> possibly be the best we can do, is it? >> >> While I'm excited with all the directions blender >> development is currently going, it's utterly depressing that >> users are still losing data on a daily basis because >> we can't quite get the basics right like "do not delete the >> users data without their consent". >> >> These are *NOT* isolated incidents [3]. Losing your >> data and learning about "the fake user" shouldn't be >> a right of passage to become "a real blender user". >> Users shouldn't be silently *losing* data in an operation >> ironically called *saving*. That's crazy, no other >> application behaves like this! >> >> Yes, I know this is how we have always done it. No, >> this is not OK, never was. >> Ton: Please make protecting the user’s data a >> priority, as it doesn’t seem this will happen otherwise. >> >> --Ray >> >> >> [1] https://devtalk.blender.org/t/oh-no/505/2 >> [2] https://developer.blender.org/T97968 >> [3] https://devtalk.blender.org/t/more/22715 >> >> ___ >> 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] Handling of user data.
All, It's been years [1] (2018) since I last was rather vocal on this subject, but how is this [2] still happening? "Yes, blender deleted your data (and silently at that), that means it's working correctly!" cannot possibly be the best we can do, is it? While I'm excited with all the directions blender development is currently going, it's utterly depressing that users are still losing data on a daily basis because we can't quite get the basics right like "do not delete the users data without their consent". These are *NOT* isolated incidents [3]. Losing your data and learning about "the fake user" shouldn't be a right of passage to become "a real blender user". Users shouldn't be silently *losing* data in an operation ironically called *saving*. That's crazy, no other application behaves like this! Yes, I know this is how we have always done it. No, this is not OK, never was. Ton: Please make protecting the user’s data a priority, as it doesn’t seem this will happen otherwise. --Ray [1] https://devtalk.blender.org/t/oh-no/505/2 [2] https://developer.blender.org/T97968 [3] https://devtalk.blender.org/t/more/22715 ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Retiring MSVC 2017 Support
All, After years of loyal service we will be retiring support for MSVC 2017, making the new requirement at least MSVC 2019 16.9.16. The build scripts and wiki will be updated in the coming days to remove VS2017 support. If you have updated your VS 2019 installation in the last year you will likely have no issues, otherwise it is best to do so before these changes land. Any version of VS2022 will also work. Greetings, Ray ___ 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] Proposal for clarified VFX Reference Platform Support
I don't think any of the major vendors (nor us) will build openvdb with a wonky blosc version that will give compatibility issues, point is neither the danger of using a "wrong" blosc version nor any other mention of file compatibility is in the platform (but it is in the openvdb documentation) So my argument was about not referring to the platform as an authority on file compatibility, since they aren't. The choice to follow the platform or not is a completely separate choice. I'm desperately trying to get us to a point where rather than an uncommitted, "we follow some things, not others, kinda depends on our mood, and if we like to make a random exception or not, also here are some arbitrary commitments to things that platform doesn't even seem to do" to a crystal clear: -These are the things we do -These are the things we don't I'd rather give users like you solid hard disappointment you can count on, than comforting false hope that will disappoint. Guaranteed platform adherence would have been acceptable as well, but that does not appear to be the direction we are appear to be leaning. My objective is to minimize/eliminate the "gray zone" blender has been in for the last few years regarding the platform, VFX Platform in or out, I'm cool either way, but we have to pick a team and communicate it clearly to our users. --Ray On 2022-01-20 12:40 p.m., Scott Wilson wrote: > I'm sort of out of the loop, but has there been communications with the VFX > Reference Platform recently? I think that some of the issues brought up such > as build flags for OpenVDB could be resolved. I know that as a pipeline TD in > a studio, having all of the vendors on the same page about all attributes of > the build environment makes my life much easier. So, I throw what little say > I have into getting Blender and the platform aligned. > > On Thu, Jan 20, 2022, 11:22 AM Ray Molenkamp via Bf-committers > wrote: > > While I do not mind the practical nuts and bolts of this > proposal at all, I do mind the language, referring to the > VFX Platform as something worth looking at regarding file > or platform compatibility is unfortunate. > > The Platform as is makes no attempt to manage file compatibility > throughout the pipeline, the big-ticket items in this space such > as USD and/or MaterialX aren't even in the platform, the things > that are in the platform, such as OpenVDB that have _severe_ > file compat issues if build incorrectly do not even have a footnote > about it. The only logical conclusion here is, the VFX Platform > is a not authority to appeal to regarding file compatibility, so > best not to. > > As for platform compatibility, the messaging in the VFX Platform > is confusing, for linux it declares a glibc version, for macOS it > declares a deployment target, so far so good, but then for windows > it does none of these things, and just recommends a compiler and SDK of > which neither determine the OS versions the resulting code can > run on, the inclusion of python 3.9 indirectly implies windows 8.1 > is their minimum windows deployment target, but honestly I'm unsure > if even they are aware of this implication. > > I'd like to see the proposal move more into concrete direction: > > > Blender does NOT follow the VFX platform. > > > > - Blender aims be compatible with operating systems VFX Platform > compatible software will be able run on. > > - blender aims not to break file compatibility for 3rd party formats > such as EXR, VDB, Alembic: files exported from Blender should be usable in > other software used in the pipeline, and vice-versa. > > The last item > > > - Not to break external render engines > > Is just not something I think we can we can practically commit to, > these are generally linked directly to the python shared libs, > and bumping python versions will definitely break most if not all > of them. > > To put an end to having to have this conversation every year, I'd > like to break the loop with the following text: > > > Major blender releases will ship with the latest major python version > available during BCON1 in its development. > > My proposal > > - Clarifies our stance on the VFX Platform > - Doesn't appeal to an authority the VFX Platform clearly lacks regarding > file compat. > - Somewhat commits to running on the same platforms as the VFX platform > (as much as it can be deduced from the platform, they are vague about it, > hard to make any solid commitments here). > - Makes the python version blender will ship with predictable. > > Note that personally, I may or
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
While I do not mind the practical nuts and bolts of this proposal at all, I do mind the language, referring to the VFX Platform as something worth looking at regarding file or platform compatibility is unfortunate. The Platform as is makes no attempt to manage file compatibility throughout the pipeline, the big-ticket items in this space such as USD and/or MaterialX aren't even in the platform, the things that are in the platform, such as OpenVDB that have _severe_ file compat issues if build incorrectly do not even have a footnote about it. The only logical conclusion here is, the VFX Platform is a not authority to appeal to regarding file compatibility, so best not to. As for platform compatibility, the messaging in the VFX Platform is confusing, for linux it declares a glibc version, for macOS it declares a deployment target, so far so good, but then for windows it does none of these things, and just recommends a compiler and SDK of which neither determine the OS versions the resulting code can run on, the inclusion of python 3.9 indirectly implies windows 8.1 is their minimum windows deployment target, but honestly I'm unsure if even they are aware of this implication. I'd like to see the proposal move more into concrete direction: > Blender does NOT follow the VFX platform. > > - Blender aims be compatible with operating systems VFX Platform compatible > software will be able run on. > - blender aims not to break file compatibility for 3rd party formats such as > EXR, VDB, Alembic: files exported from Blender should be usable in other > software used in the pipeline, and vice-versa. The last item > - Not to break external render engines Is just not something I think we can we can practically commit to, these are generally linked directly to the python shared libs, and bumping python versions will definitely break most if not all of them. To put an end to having to have this conversation every year, I'd like to break the loop with the following text: > Major blender releases will ship with the latest major python version > available during BCON1 in its development. My proposal - Clarifies our stance on the VFX Platform - Doesn't appeal to an authority the VFX Platform clearly lacks regarding file compat. - Somewhat commits to running on the same platforms as the VFX platform (as much as it can be deduced from the platform, they are vague about it, hard to make any solid commitments here). - Makes the python version blender will ship with predictable. Note that personally, I may or may not approve of the direction being taken here, but judging from your internal discussions this seems to be the way we want to go as a project, in which case clear language is undoubtedly better than vague commitments that sound nice but may set unrealistic expectations. --Ray ___ 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] Proposal for clarified VFX Reference Platform Support
The reason that is, most of the people involved are in the discussion are not in a position to make this decision (and that includes me) We can have good arguments on either side of following or not following, but none of us can decide. This is something that will have to be decided at the top. It's essentially between Ton and the project admins, decide what what the position is of the blender project, VFX Platform are we in or are we out? The stance we had for the last few years, "We're in, this year, since it kinda aligns, next year? maybe not? there's exceptions... if we feel like it.." isn't working, the sooner we realize that the better. If we again do not take a solid stance, I guarantee you we will have the same song and dance in between 6 and 12 months from now. I'm not overly interested in deciding on the python upgrade right now (even though that personally puts me in a rough spot with bcon3 this close) I'd rather see this through and have HQ sort it out once and for all. --Ray On 2022-01-19 8:34 p.m., Campbell Barton via Bf-committers wrote: > This discussion seems to suffer the same fate as other VFX platform > threads... fizzle out with no conclusion. > ___ 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] Proposal for clarified VFX Reference Platform Support
You may feel like you're alone in this, however you may have an ally in me, and I may even go further than you. If you read my previous emails in this thread carefully you'll notice I have personally made no call regarding the python version, I Don't feel it's my place to make that call, I'm not on the python team, nor am I a project admin, and as platform dev, building python 3.9.10 or 3.10.2, I'll be honest it's all the same to me. I did make the case that if we don't follow python, there's no point to follow any other recommendations, no-one is going to care about our TBB or OpenVDB versions if we're out of line on python, so let’s not make any commitments that benefit no-one. However, *IF* we decide to follow it for python, I'd say we follow the whole thing, actually we ought to go even further than what we did previously,and ship the python bindings for components that support it, ship most libraries shared rather than static (at-least on windows, unsure how much of a pain-point this is on the *nix based platforms), and make sure QT/Pyside integrate nicely, perhaps even go as far as shipping QT. Since once you clear the python version hurdle, that be the next most common issues that these sorts of pipeline tools will run into. You could say I'm an either all in, or all out kind of guy, picking the bits that we like of the VFX Platform that happen to align, and have that change between years, isn't a position I think we should be in, since it's effectively an "all out" position, with more (Rightfully so) complaining users due to ambiguity on whether we are in or out for any given blender release. --Ray On 2022-01-17 8:39 a.m., Brecht Van Lommel via Bf-committers wrote: > For reference there is more discussion about this in the two tasks: > 2021: https://developer.blender.org/T83246 > 2020: https://developer.blender.org/T68774 > > My preference is still to track the full VFX platform, including the Python > version. However I know I'm in the minority on this, and I'm not expecting > that to change. > > I don't think it's practical to support multiple Python versions. For > add-ons and particularly those with binaries, supporting both Python > versions would be more work. Likely many of the add-ons would just not be > tested and not work with the older Python version. > > I think other libraries do matter. We still wanted to switch to OpenColorIO > 2 around the same time as other apps for example, regardless if file > compatibility is a goal of the VFX platform. It should be a goal for us. > Further some of these libraries have Python APIs that we'd like to expose, > like pyopenvdb. > > In my opinion we should stick to the VFX platform by default and make > exceptions as needed. We don't need to retread the Python discussion every > year, the situation is still the same and it's reasonable to assume we > continue being incompatible there. For other libraries, if it's not causing > incompatibility I don't even see that as deviating from the VFX platform. > If it does lead to incompatibility, I think we should take that into > consideration. > > On Mon, Jan 17, 2022, 15:16 Ray Molenkamp via Bf-committers < > bf-committers@blender.org> wrote: > >>> I don't really feel great about Python >>> being the only exception allowed to be digressed >>> from the platform. >> I think you're misunderstanding the VFX Platform goals, >> it has nothing to do with asset compatibility throughout >> the pipeline. Otherwise, it would specify what formats >> would have to be supported in OIIO, or what version >> of blosc should be used for OpenVDB since using the >> "wrong" blosc version will cause files to be unreadable >> by older versions. It does none of these things. >> >> No, what it sets out to do is define a tightly controlled binary >> runtime environment, if I link my binary addon to the library >> versions in the platform, I will be able to load it into the host >> applications that follow the platform without issues. >> >> If we break on python, none of the other things in the platform >> matter, With the only notable exception being the glibc version >> I suppose. >> >> Any commitments we may make to the platform while simultaneously >> breaking on python are pointless, so no, that case I make is not >> "Only python is/should be the exception", the case is, "If we >> break on python there's no need to commit to anything else, so >> best not to make any commitments." >> >> --Ray >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> List details, subscription details or unsubscribe: >> https://lists.blender.or
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
> I don't really feel great about Python > being the only exception allowed to be digressed > from the platform. I think you're misunderstanding the VFX Platform goals, it has nothing to do with asset compatibility throughout the pipeline. Otherwise, it would specify what formats would have to be supported in OIIO, or what version of blosc should be used for OpenVDB since using the "wrong" blosc version will cause files to be unreadable by older versions. It does none of these things. No, what it sets out to do is define a tightly controlled binary runtime environment, if I link my binary addon to the library versions in the platform, I will be able to load it into the host applications that follow the platform without issues. If we break on python, none of the other things in the platform matter, With the only notable exception being the glibc version I suppose. Any commitments we may make to the platform while simultaneously breaking on python are pointless, so no, that case I make is not "Only python is/should be the exception", the case is, "If we break on python there's no need to commit to anything else, so best not to make any commitments." --Ray ___ 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] Proposal for clarified VFX Reference Platform Support
All right, looks like we're tiptoeing around the elephant in the room, time to rip that Band-Aid off (feels like this metaphor kinda got away from me, but I'm sticking with it!) Let’s not beat around the bush, no-one has ever complained about our OIIO, Boost, VDB or TBB versions. People get ..passionate.. about python, anytime someone brings up the VFX Platform it's python, It's never anything else, it's python, the rest of the VFX platform may as well not exist. The issue is, and will always be python. The real question is, are we going to follow the platform in regards to python or not. The way the python [1] and VFX Platforms [2] are released those most we'll ever have is a 5-month window where the two will overlap and there will actually be active bug fix support on python the python version of the VFX Platform. Are we OK with that? People get upse..uhh passionate when we "suddenly" change our python version. What is needed is a clear and decisive message regarding how we pick our python versions. Are we following: A) The python release schedule B) The VFX platform schedule C) Well, you know maybe, VFX kind of works out this year so why not, next year maybe not so much, we'll see, oh hey this years python has …. [check notes]..better….. error.. messages? we got to upgrade! D) Other We have been doing C, and I don't think anyone is super thrilled about how this is working out. I mostly don’t even care what we pick (not C!!) pick something, write it down somewhere, so people can rely on it. --Ray [1] https://www.python.org/dev/peps/pep-0602/ [2] https://vfxplatform.com/about/ ___ 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] Let's Encrypt SSL certificates incident on the blender.org servers
For people having ssl issues with arcanist, the easiest solution is 1) grab the latest cacert.pem from https://curl.se/docs/caextract.html 2) copy it to [arcanist_installation_folder]/resources/ssl/custom.pem Pay attention to the slightly different filename it *NEEDS* to be custom.pem the original filename cacert.pem will not work. This should do the trick on all platforms (but it's only been tested on Linux and Windows). --Ray On 2021-09-30 1:06 p.m., Sergey Sharybin via Bf-committers wrote: > Hi, > > Just a quick memo about the issue of expired Let's Encrypt certificates. It > might be useful for developers who experience issues with HTTPS connection > to our servers. > > One of the root Let's Encrypt certificates did expire today which affected > parts of our development infrastructure. In all cases it doesn't seem to be > an issue with the server configuration but is caused by quirks on the > client side. We are only aware of issues on Windows. > > The Subversion clients did not trust the SSL certificate of > https://svn.blender.org/. The work-around we did for the builder.blender.org > was to install the Let’s Encrypt R3 intermediate certificate [1]. This > "worked (tm)", although ideally intermediate certificates shouldn't need to > be installed and the system should go by the root CA certificates from the > Windows Certificates Store. > > The Arcanist uses the CURL extension of PHP, and it does not use the > Windows Certificates Store. The way it was fixed on the buildbot workers > was by creating a cacert.pem with the "ISRG Root X1" certificate which was > exported from the Store (and matched the one from Let's Encrypt information > page [1]). > > Our server administrator Danny McGrath also took the liberty of disabling > TLSv1.0 and TLSv1.1 on some of the sites during tests. Provided that this > doesn't make matters worse, the changes are likely to be kept. > > [1] https://letsencrypt.org/certificates/ > > Best regards, > - Your Engineering Team Danny and 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 > 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
Re: [Bf-committers] JSON/YAML parsing in CPP
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
Re: [Bf-committers] Nightly builds on Steam and Snap stores
Is the developer wiki is the ideal place to communicate with end-users? There's no denying these are pretty good looking docs with plenty of screenshots, the top of the page is clearly aimed at developers and will just scare off most end users that do manage to find it. (end users are unlikely to visit the dev wiki) Even if they do find it, and make it past the first page there's following progression: - Pipeline talk - end-user: Eek! - Downloading from the website! - end-user: Yay - Scary looking 10 line regex - end-user: Eek! - Using steam! - end-user: Yay This page just seems to have no idea who its audience is and it makes for a somewhat incoherent experience for all parties involved. --Ray On 2021-07-16 9:40 a.m., James Monteath via Bf-committers wrote: > Hi all, > > Nightly builds are now available on Steam (BETA) test branches and Snap > channels. > > **Steam** > The automated delivery of *2.93 / 2.83 LTS - Candidates* > and *3.0 - Alpha* builds are now accessible via Steam (BETA) Test branches. > Blender nightly builds are available for all supported platforms on Steam. > > Using Steam Test Branches: > https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Steam_Test_Branches > > **Snap** > For Linux systems with Snap support, *2.93 / 2.83 LTS - Candidates* > and *3.0 - Alpha *builds can be refreshed using channels. > > Using Snap Test Channels: > https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Snap_Test_Channels > > Cheers ! ___ 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] Blender developer week notes - 2021.07.12
Dalai, Think some small clarification is in order here Jesse is a very capable and diverse developer [1] Now he did have a few patches in my module (as he did in many others), and while I will happily commit contributors patches, there is a point where you go "wait? why am I still committing patches for this dev? He's a capable dev, submitted many patches, and has been around for quite a bit now, he ought to be trusted to commit his own work!" So while I did lobby to get him commit rights, this was in no way, shape, or form an attempt to "claim" Jesse for my own module. He's doing great work all over the place, best not to constrain wonderful developers like that. If you go, every dev needs a home module, I would happily give him one in the platform module, but afaik that's not how we currently operate. --Ray [1] https://developer.blender.org/people/revisions/126877/ On 2021-07-13 1:47 a.m., Dalai Felinto via Bf-committers wrote: > Hi all, > > Here are the compiled notes for this week's development. For the complete > report with modules and projects updates, links and images read it on: > https://devtalk.blender.org/t/12-july-2021/19521 > > Welcomes > > * Jesse Yurkovich (deadpin) joins the "Platforms, Builds, Tests & Devices" > module. > > Announcements > = > * Google Summer of Code 1st evaluation deadline is Friday 16/July 20:00 > CEST. > * New performance testing framework [1] in master. > ** Used for Cycles now, but developers are encouraged to use it for testing > and tracking performance of more Blender features. > > Geometry Nodes > = > * Nodes workshop June 2021 write up [2] > > [1] - https://wiki.blender.org/wiki/Tools/Tests/Performance > [2] - https://code.blender.org/2021/07/nodes-workshop-june-2021/ > > -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 > 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
Re: [Bf-committers] Buildbot Update - June 14, 2021
May I suggest moving the change log to the bottom of the page (or even better its own page) ? While I absolutely love having the change log, having users/devs scroll though it before they can learn how to use the build infra structure seems less than ideal, given the change log is not going to get any shorter over time they may even bail out thinking they are on the wrong page. --Ray On 2021-06-14 10:17 a.m., James Monteath via Bf-committers wrote: > Hi all, > > Buildbot has been updated. > https://builder.blender.org/admin/#/builders > > Notable changes on the Wiki. > https://wiki.blender.org/wiki/Infrastructure/BuildBot#Notable_Changes > ___ 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] Simple steps to get an harmonious collaboration
I'm somewhat confused on the goal some of the (proposed?) rules. But I'll just pick on the "Patch description should match the commit message."-rule for now not to make this longer than it needs to be. Most people are much more verbose in their patch description, some have visual aids (images/clips), benchmark results, and perhaps test files attached to them. Rich content is possible and often used. While commit messages are a much more somber endeavor, no rich content and strict requirements on the formatting (50 chars for the first line ie) The guidance we offer for what should be in a patch [1] and what should be in a commit message [2] also paint two rather different pictures. Personally, I welcome justifications in a diff on al the ways the problem could have been solved, but were ultimately not chosen for reason X, Y or Z. While in commit messages I honestly only care for "what does it do, how does it do it" when I'm bisecting I have no interest whatsoever in learning about all the ways a certain commit doesn't solve the issue. Patch descriptions and commit messages just seem fundamentally different things, and I struggle a bit on seeing why unifying the two would be a "good thing" I have similar concerns with many of the other rules on this list, most seem perfectly fine rules on first sight, but without a clear justification on how they contribute to.. [check notes] .. "harmonious collaboration in the code review platform", its just a list of seemingly oddball rules, I could add a "keyboard layout must be set to dvorak while typing patch description" rule and it wouldn't even look out of place. --Ray [1] https://wiki.blender.org/wiki/Process/Contributing_Code#Ingredients_of_a_Patch [2] https://wiki.blender.org/wiki/Style_Guide/Commit_Messages On 2021-06-01 5:05 a.m., Sergey Sharybin via Bf-committers wrote: > Hi, > > Just a quick note. The bf-admin team worked on several process related > documents to ensure a pleasant and efficient development process. > > Today we've updated wiki with the patch review process: > https://wiki.blender.org/wiki/Process/Patch_Review > > Feedback is welcome. > > 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
Re: [Bf-committers] VFX reference platform 2022 draft
imho 3.9 is the only version they could have picked, the proposed release date for 3.10 is 2021-10-04 [1]. While the VFX platform aims to finalize in august [2]. I was rather vocal last year for them putting versions on that had not been released yet (some of which got delayed well into 2021) I'm happy to see for 2022 a more conservative stance has been taken. With bugfix support for 3.9 ending on 2022-05-02 [3] that does put them in an odd situation, they'll either have to recommend a version that may not be released on time, or recommend a version that will not see bug fixes for most of the year. There seemingly is no winning solution here since the problem appears to be the somewhat short support window for python releases. As much as I picked on them last year for making very strange recommendations, I feel they struck a good balance for 2022. --Ray [1] https://www.python.org/dev/peps/pep-0619/ [2] https://vfxplatform.com/about/ [3] https://www.python.org/dev/peps/pep-0596/ On 2021-05-18 2:47 a.m., Sybren A. Stüvel via Bf-committers wrote: > Hello, > > On Mon, 17 May 2021 at 19:54, Brecht Van Lommel via Bf-committers < > bf-committers@blender.org> wrote: > >> There is a draft for the next VFX reference platform up now. Since we had >> some issues with the last one, it would be good to give feedback if >> necessary. >> > Good call. > > >> Python was upgraded to 3.9, which will still trail behind 3.10 that will be >> released this year. So the question about diverging or not will remain. >> > My preference would be to, for non-LTS releases at least, stick to versions > of Python that still receive bugfixes. In the past we've had crashes of > Blender that were due to a bug in Python. The only way to solve that was to > upgrade Python itself. This in itself is rare, but I don't remember having > such issues at all until we stuck to the old py3.7 to adhere to the VFX > Platform. > > Is there anything known about the policy of the VFX Platform when it comes > to picking which Python version to stick to? Is it always going to be > "whatever version was released a year earlier"? Or is there still an > acceleration happening after sticking to py2.7 so long, and will they > eventually be targeting the latest versions? If it's the latter I'd be fine > with following the VFX Platform and sticking to py3.9 for a while longer. > If sticking to the platform means that for a significant amount of time > we'll be on versions of Python that don't receive bugfixes any more, I'm > less positive. > > Sybren > ___ > 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] C -> C++ Conversions / Failing build
All, More and more code is getting converted to C++ and honestly couldn't be happier about that. What I'm less thrilled about is the way this is being done, devs work with GCC, don't test on windows, violate the standard (use of designated initializers in c++ breaks the build every...single ..time...) and skip code review all together and just commit the work. then build bots start failing, and if you're lucky the dev is still around to fix issues, if not someone else will have to janitor behind them. This is not how things are supposed to go, we run into the same issues over and over and over, enough is enough, go trough review! Things I am unhappy about is this [1] commit specifically - Converted a bunch of code from C->C++ in master since he was doing "an experiment" - Did no go through review - Did not clean up the use of designated initializers (C++20 feature) - Did not test on other platforms/compilers - Did not check if work that "usually" breaks the build, broke the bots - I was forced to spend a couple of hours on an issue that should not have been an issue if the review process was used, time i did not have really Hans Goudey kindly fixed the initalizers, but sadly there was more trouble hiding in this commit, the core issue is the `WM_msg_subscribe_rna_anon_prop` macro called in `info_header_region_message_subscribe` has this little nugget _WM_MESSAGE_EXTERN_BEGIN; \ extern PropertyRNA rna_##type_##_##prop_; \ _WM_MESSAGE_EXTERN_END; \ given it's C++ a decorated symbol was generated, which naturally can't be found at link time. And before you go just `extern "C"` it, that is only allowed at global scope, it appears, this macro is in its current form is just not compatible with C++. What I'd like to see in the future - USE THE REVIEW PROCESS, C->C++ conversions have issues... every... single.. time... What I'm going to do I prodded the dev in chat before starting this email, if i have gotten no response by the time I hit send , I will revert this commit, we can't have master failing for this long. [1] https://developer.blender.org/rB9cce18a5858cb93da626f5f0fd7e09cd66637e05 ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] ASAN now supported on windows
All, Normally I don't do notify bf-c on platform changes I do but this one seemed note worthy. I landed ASAN support (D7794) for windows a few minutes ago, it requires the latest VS update (16.9) but beyond that it functions the same way as it does on Linux, just toggle `WITH_COMPILER_ASAN` ON in cmake, rebuild and you should be good to go. If anyone has issues using it, feel free to come bug me Greetings, Ray ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.93 modules roadmap confirmation 15/Mar 11 CET
It felt somewhat strange to me for the modules to present their targets 2 days before the bcon1 deadline, I mean at this point all work should be done/in already, seems a little late to determine their feasibility. Perhaps it's better to do add a similar style meeting earlier in the process to solidify the targets and perhaps make any priority changes? Greetings, Ray On 2021-03-15 8:27 a.m., Dalai Felinto via Bf-committers wrote: > Hi, > > These are the modules targets / meeting notes: > https://devtalk.blender.org/t/2021-03-15-blender-2-93-targets/17902 > > Thanks everyone for joining. The meeting was long (2 hours + some time to > wrap up VFX later). But I think it was useful, with a lot of participation > and to the point. If anyone has any feedback on how we can do these release > meetings in the future let me know. > > Best regards, > -Dalai- > > Dalai Felinto - da...@blender.org - www.blender.org > Blender Development Coordinator > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > Op ma 8 mrt. 2021 om 21:35 schreef Dalai Felinto : > >> Hi, >> >> I would like to propose a meeting on blender.chat next Monday (15/Mar) at >> 11:00 CET for the modules to present their 2.93 targets. >> >> The modules can prepare a list of the planned new features, and their >> current state ahead of time. I created a placeholder to help with that. >> During the meeting I will move this to hackmd so we can edit it at the same >> time. >> >> https://devtalk.blender.org/t/2021-03-15-blender-2-93-targets/17902 >> >> At the meeting we then go over them in order and confirm the targets and >> their feasibility. >> >> Let me know what you think of this idea, >> -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 ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer week notes - 2021.02.15
>* 2.93 bcon2 on 17 February. This is listed on developer.blender.org as march 17 on both the front page [1] and the 2.93 schedule [2] Did this change, or is it a typo? --Ray [1] https://developer.blender.org/ [2] https://developer.blender.org/project/view/125/ On 2021-02-15 11:19 a.m., Dalai Felinto via Bf-committers wrote: > Hi all, > > Here are the compiled notes for this week's development. For the complete > report with modules and projects updates, links and images read it on: > > https://devtalk.blender.org/t/15-february-2021/17475 > > Announcements > = > * Google Summer of Code Ideas page is still mostly with old ideas, deadline > is February 19th (Friday). > * Bulidbots will be on maintenance 16 February, Tuesday. > * 2.92 bcon4 on 17 February. > - We will go back to using release_candidate tags. > - High frequency tablet input will be removed since it introduced many > problems for old drivers, but will come back in 2.93. > * 2.93 bcon2 on 17 February. > * Python 3.9 support has landed for 2.93 alpha. > - This has ended Blender support for Windows 7 and 8. > - The new minimum requirement is Windows 8.1. > > Have a great week everyone, > -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 ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] No Monday or Tuesday meetings for the time being
Apologies, my weakness for "snappy" responses got the better of me rather than taking a deep breath and discussing the issue at hand. The decision has been unilaterally made, which is your prerogative, however when questioned why this decision was made I do not think "why don't you explain why not?" is a satisfying answer. The Monday meetings have been a stable of blender development for as long as i have been involved with blender, having them canceled without even a mention it was being considered is strange and some explanation how this came out of nowhere would be appreciated --Ray On 2021-02-09 9:14 a.m., Ray Molenkamp via Bf-committers wrote: > i hear the Tuesday meetings are a joy > > --Ray > > On 2021-02-09 8:59 a.m., Dalai Felinto wrote: >> Hi Ray, >> >> Which reasons do you see to keep the meeting(s)? >> >> Thanks, >> Dalai >> >> Op ma 8 feb. 2021 om 17:46 schreef Ray Molenkamp via Bf-committers >> mailto:bf-committers@blender.org>>: >> >> That seems somewhat strange and out of the blue (at least for me), the >> lack of reasoning for putting them on hold especially for the Tuesday ones >> you seem fond of is concerning, what am i missing here? >> >> --Ray >> >> On 2021-02-08 9:33 a.m., Dalai Felinto via Bf-committers wrote: >> > Hi, >> > The Monday (developers) and the Tuesday (modules) meetings are >> currently on >> > hold. The Monday one has very little quorum and is rarely useful. >> > >> > The Tuesday talks (module meetings) are quite a joy actually and I will >> > miss talking to the modules owners 1:1. But they have always being more >> > like a healthy check then a permanent solution. What we need instead >> is to >> > make sure the modules are properly structured and can operate >> autonomously. >> > But this is a separate topic. >> > >> > I have a new idea on how to do the weekly communication of the ongoing >> > module and projects: >> > >> > * We keep the weekly online page in devtalk for the weekly notes [1]. >> > * Developers keep adding their weekly reports there. >> > * Everyone adds relevant announcements there >> > * [new] Modules and projects then add their notes there as well, >> > asynchronously. >> > * [new] At the end of Mondays I do a final pass in the page and post it >> > here. >> > >> > [1] - https://devtalk.blender.org/t/15-february-2021-upcoming/17475 >> <https://devtalk.blender.org/t/15-february-2021-upcoming/17475>. >> > >> > Any feedback is welcome. >> > >> > Best regards, >> > -Dalai- >> > >> > Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - >> www.blender.org <http://www.blender.org> >> > Blender Development Coordinator >> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org <mailto:Bf-committers@blender.org> >> > https://lists.blender.org/mailman/listinfo/bf-committers >> <https://lists.blender.org/mailman/listinfo/bf-committers> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org <mailto:Bf-committers@blender.org> >> https://lists.blender.org/mailman/listinfo/bf-committers >> <https://lists.blender.org/mailman/listinfo/bf-committers> >> >> >> >> -- >> >> -Dalai- >> >> Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - >> www.blender.org <http://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 ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] No Monday or Tuesday meetings for the time being
i hear the Tuesday meetings are a joy --Ray On 2021-02-09 8:59 a.m., Dalai Felinto wrote: > Hi Ray, > > Which reasons do you see to keep the meeting(s)? > > Thanks, > Dalai > > Op ma 8 feb. 2021 om 17:46 schreef Ray Molenkamp via Bf-committers > mailto:bf-committers@blender.org>>: > > That seems somewhat strange and out of the blue (at least for me), the > lack of reasoning for putting them on hold especially for the Tuesday ones > you seem fond of is concerning, what am i missing here? > > --Ray > > On 2021-02-08 9:33 a.m., Dalai Felinto via Bf-committers wrote: > > Hi, > > The Monday (developers) and the Tuesday (modules) meetings are > currently on > > hold. The Monday one has very little quorum and is rarely useful. > > > > The Tuesday talks (module meetings) are quite a joy actually and I will > > miss talking to the modules owners 1:1. But they have always being more > > like a healthy check then a permanent solution. What we need instead > is to > > make sure the modules are properly structured and can operate > autonomously. > > But this is a separate topic. > > > > I have a new idea on how to do the weekly communication of the ongoing > > module and projects: > > > > * We keep the weekly online page in devtalk for the weekly notes [1]. > > * Developers keep adding their weekly reports there. > > * Everyone adds relevant announcements there > > * [new] Modules and projects then add their notes there as well, > > asynchronously. > > * [new] At the end of Mondays I do a final pass in the page and post it > > here. > > > > [1] - https://devtalk.blender.org/t/15-february-2021-upcoming/17475 > <https://devtalk.blender.org/t/15-february-2021-upcoming/17475>. > > > > Any feedback is welcome. > > > > Best regards, > > -Dalai- > > > > Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - > www.blender.org <http://www.blender.org> > > Blender Development Coordinator > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org <mailto:Bf-committers@blender.org> > > https://lists.blender.org/mailman/listinfo/bf-committers > <https://lists.blender.org/mailman/listinfo/bf-committers> > ___ > Bf-committers mailing list > Bf-committers@blender.org <mailto:Bf-committers@blender.org> > https://lists.blender.org/mailman/listinfo/bf-committers > <https://lists.blender.org/mailman/listinfo/bf-committers> > > > > -- > > -Dalai- > > Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - > www.blender.org <http://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] No Monday or Tuesday meetings for the time being
That seems somewhat strange and out of the blue (at least for me), the lack of reasoning for putting them on hold especially for the Tuesday ones you seem fond of is concerning, what am i missing here? --Ray On 2021-02-08 9:33 a.m., Dalai Felinto via Bf-committers wrote: > Hi, > The Monday (developers) and the Tuesday (modules) meetings are currently on > hold. The Monday one has very little quorum and is rarely useful. > > The Tuesday talks (module meetings) are quite a joy actually and I will > miss talking to the modules owners 1:1. But they have always being more > like a healthy check then a permanent solution. What we need instead is to > make sure the modules are properly structured and can operate autonomously. > But this is a separate topic. > > I have a new idea on how to do the weekly communication of the ongoing > module and projects: > > * We keep the weekly online page in devtalk for the weekly notes [1]. > * Developers keep adding their weekly reports there. > * Everyone adds relevant announcements there > * [new] Modules and projects then add their notes there as well, > asynchronously. > * [new] At the end of Mondays I do a final pass in the page and post it > here. > > [1] - https://devtalk.blender.org/t/15-february-2021-upcoming/17475. > > Any feedback is welcome. > > Best regards, > -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 ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] .git-blame-ignore-revs entries.
I'd prefer if we excluded small commits completely, but willing to settle on clarifying that the "smaller" commits still ought to be the result of automated tools, If there is no clear indication a cleanup was automated the commit should not be added. ie a commit "Cleanup: clang-tidy some-check" could still very much be a manual cleanup of the warns exposed by clang-tidy and suspect to unintentional functional changes. --Ray On 2020-12-28 5:01 p.m., Brecht Van Lommel via Bf-committers wrote: > Hi Ankit, > > Please go through code review for all commits, unless you are a module > owner or admin that is the policy. > > Note that there are guidelines in the file itself. We could document it in > the wiki too, but I'm not sure it's needed. Perhaps the wording can be > clarified? Suggestions are welcome. The text is as follows: > > # Changes that belong here: > # - Massive comment, doxy-sections, or spelling corrections. > # - Clang-format, PEP8 or other automated changes which are *strictly* "no > functional change". > # - Several smaller commits should be added to this list at once, because > adding > # one extra commit (to edit this file) after every small cleanup is noisy. > > Note that only massive or automated changes are mentioned as belonging > here, nothing else. And commits like these have functional changes: > > # Fix T82520: error building freestyle with Python3.8 > # Build-system: Force C linkage for all DNA type headers > # Cleanup: use preprocessor version check for PyTypeObject declaration > > So as far as I can tell this is just not following the documented > guidelines. > > Thanks, > Brecht. > > > > On Mon, Dec 28, 2020 at 8:48 PM Ankit via Bf-committers < > bf-committers@blender.org> wrote: > >> Hello >> I'm getting used to it. >> I'll remove several commits soon, now that I have received the >> feedback on the last commit, and will use stricter conditions in the >> future. >> >> My premise >> - for being lenient was that it saves other people from committing to >> the file which keeps the noise in git log low. >> - for renames was that a refactoring tool was used >> with as little human intervention as possible. >> - for clang-tidy being the auto-fixes feature that clang-tidy gives. >> >>> All, >> That's a new way of raising concerns on commits. >> >>> but I really >>> would still like to see smaller and clearly manual cleanups >>> in git blame. >> If I see "cleanup" in the title, the onus is on the committer to make >> sure that it really is a cleanup. If that promise is kept, I don't see >> why a cleanup commit interests you. >> >>> Changes in this file don't even seem to go through code review. >> I thought it keeps the overhead of keeping a utility file low. >> >> Ankit >> >> >>> On 29-Dec-2020, at 00:40, Ray Molenkamp via Bf-committers < >> bf-committers@blender.org> wrote: >>> All, >>> >>> What's going in with this file? there's 50+ commits in there >>> and I disagree with virtually every single hash I sampled >>> from it. >>> >>> If we want to hide large changes made by automated tools like >>> the big clang-format [1] change, yeah awesome, but I really >>> would still like to see smaller and clearly manual cleanups >>> in git blame. >>> >>> Changes in this file don't even seem to go through code review. >>> In the original review [2] both Brecht and Campbell mention >>> that it be "OK for larger changes" but that is not what appears to >>> be happening. >>> >>> This is not how this is supposed to work, is it? >>> >>> --Ray >>> >>> [1] >> https://developer.blender.org/rBe12c08e8d170b7ca40f204a5b0423c23a9fbc2c1 >>> [2] https://developer.blender.org/D9234 >>> ___ >>> 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 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
Re: [Bf-committers] .git-blame-ignore-revs entries.
On 2020-12-28 12:47 p.m., Ankit wrote: > Hello > I'm getting used to it. > I'll remove several commits soon, now that I have received the > feedback on the last commit, and will use stricter conditions in the future. I'd like to replace "stricter conditions" with "well defined/documented conditions" hence the prod to bf-c >> All, > That's a new way of raising concerns on commits. I don't have a concern with "a commit", I have a concern with "The process of how we manage this file", for which bf-committers is an appropriate place. > If I see "cleanup" in the title, the onus is on the committer to make > sure that it really is a cleanup. If that promise is kept. Developers make mistakes and changes can have unforeseen consequences sometimes, as much as we'd all like to write 100% bug free code, guaranteeing it is quite something else. Small changes in structure can sometimes trigger optimizer bugs in compilers, it can be very relevant knowing if even a relatively safe, 100% correct cleanup commit happened to a piece of code. > I don't see why a cleanup commit interests you. A cleanup commit is a commit like any other which can potentially introduce bugs and should be treated as such, hiding it from git blame is counter productive. Now having large quantity of all code blame to a single commit (like e12c08e8d170) yeah that's clearly annoying, and should be remedied but anything beyond that I do not see the benefits of hiding such changes. --Ray ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] .git-blame-ignore-revs entries.
All, What's going in with this file? there's 50+ commits in there and I disagree with virtually every single hash I sampled from it. If we want to hide large changes made by automated tools like the big clang-format [1] change, yeah awesome, but I really would still like to see smaller and clearly manual cleanups in git blame. Changes in this file don't even seem to go through code review. In the original review [2] both Brecht and Campbell mention that it be "OK for larger changes" but that is not what appears to be happening. This is not how this is supposed to work, is it? --Ray [1] https://developer.blender.org/rBe12c08e8d170b7ca40f204a5b0423c23a9fbc2c1 [2] https://developer.blender.org/D9234 ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format
Soo.. this thread has a good run, lots of good feedback, but it still seems decision-less, I'll happily do the work to make this happen, but who makes the final call here? --Ray On 2020-12-15 9:19 p.m., Campbell Barton via Bf-committers wrote: > To follow up on previous messages: > > - On my system the stripped library is ~830kb, > over half of the libraries file-size is binary data for fonts and > character encoding tables, > if we wanted we could remove these - bringing the size down to ~350kb. > > - This library is available on mainstream Linux distributions, > so even if this isn't maintained by the author, it's not exactly > abandon-ware either. > From checking suse [0] & debian's [1] repository, their patches > aren't likely to be useful to us > since they're only tweaks for building & header guards. > > - I ran some (admittedly basic) tests with valgrind & ASAN > which didn't show up any issues that would be cause for concern. > > So while I'm still not so keen to depend on unmaintained code. > +1 to include this as an optional library. > > [0] https://build.opensuse.org/package/show/openSUSE:Factory/libharu > [1] https://packages.debian.org/stable/source/libharu > > On Tue, Dec 15, 2020 at 1:17 AM Sybren A. Stüvel via Bf-committers > wrote: >> On Fri, 11 Dec 2020 at 18:55, Brecht Van Lommel via Bf-committers >> wrote: >>> Adding an abstraction layer so theoretically the library can be switched >>> out for another is probably not very helpful. If we were using this in many >>> places maybe, but in my experience, these kinds of abstraction layers get >>> in the way more than they help. >> I agree. IMO such an abstraction layer is generally only really worth >> it if you already have two different libraries to support, and you >> know enough about the differences in architecture that you can >> actually create the proper abstractions. >> >>> libharu seems like the most reasonable solution. >> I agree, although the "not maintained since 2013" is a bit scary. The >> fact that we won't be using the known-buggy parts of the code helps, >> but I do think this should then be documented properly somewhere. If >> the inclusion of the library is done under the assumption that no >> images will be read, and no PDF will be imported, because these are >> buggy code paths, this should be clear to future contributors as well. >> Without such warnings in place, people are bound to be looking at the >> library to create some PDF-to-GP importer. >> >> Sybren >> ___ >> 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
Re: [Bf-committers] Libraries source code
see inline replies On 2020-12-14 4:21 a.m., Dalai Felinto via Bf-committers wrote: > Hi Ray, > Thanks for your reply. > > The "it is scattered all over the place, and is fragile" is my personal > opinion, and what motivated me to write the email. > > The propose to self-host was indeed from Ton. But I didn't want to add the > weight of his opinion on something that could first use some clarification. Still feels like you had a political issue and came up with some bogus reason to justify it, but let the past be the past, perhaps we should have a new years resolution of calling a spade a spade for 2021. > > My proposal to move forward is for the Building module to write down in the > wiki the current rules for: > > * When is a library hosted in `//extern` I'm not aware of any hard rules, /extern existed before I joined, what I understood over the years it's a collection of libraries that fall in one or more of the following groups: 1) Are hard to find in the average linux package repo 2) we have significant patches on 3) We are maintaining since they have no other home (anymore?) Sergey may have a more accurate definition. personal opinion: I not a huge fan of /extern, it is code that seemingly seldom changes and some of it contributes to a fair chunk of the total blender build time (looking at you, libmv) however previous attempts to evict some libs from there were met with fierce resistance, so it is what is, not a hornets nest I'm particularly looking forward to kicking. > * When is a library maintained in `svn lib` logically following the last question: when it's not in /extern and we still need it to build blender > * When should the libraries be updated I'm not aware of any hard rules there either, however personal opinion : Ideal situation: Every lib is owned by one or more of the module teams, they ask for updates in bcon1, occasionally newer versions are required for platform support, this can be discussed with the module(s) that own the dependency. Actual situation: essentially no-one cares, i did a complete lib version bump a few versions ago, and i will literally never do it again, rarely have i seen that much indecisive apathy on something. The question wasn't even hard, "hey your module depends on lib X, would you like an update?" they didn't even have to do the work! > * The differences between `make deps` and `install_deps.sh` and why we > maintain both As per my last email, "make deps" is for the platform devs to maintain the SVN libs, target audience +- 3 people, it covers all platforms we support and only those. `install_deps.sh` is a linux only script that will get the libs from a distro's repo is possible and build from source other wise, this used to be the way the linux developers got the libs before we had SVN libs for that platform, we still maintain it since it has a passionate maintainer willing to do the work. > * The current reasoning to not self-host the svn libraries sources There has never been any reason to, In the last 5 yeas I maintained this script the "it's a bit fragile" has not once caused any issues, so I question the validity of that argument, I'm not sure we need to document the reasoning for not doing it any more than we need to document why not every developer on the animations team owns a cat named sparkles. They are just question that don't come up a whole lot. > > Having this clear would have also helped the recent "VFX Reference Platform" > discussion. I do not see how any of this discussion has any merit on "do we follow the VFX Reference Platform versions or not" given that once more is a political discussion, not a technical or organizational one. The choice to stay on python 3.7.x or update to 3.9.x is not depending on if the pyhon libs live in svn or /extern , why install_deps.sh exists or the reasoning why we don't keep the source of deps in svn, even who gets to ask for updates is irrelevant if we politically decide to stick with 3.7.x. This is not a discussion for the platform team, this is between the python team and whomever makes the political calls, we (the platform team) have no horse in this race, building python 3.7.x is about as much work as building python 3.9.x, it really doesn't matter from a platform perspective. > I can gladly help out with the writing if no else from the "Platforms, Builds > & Tests" module can pick that up. I don't think the lack of documentation is due to lack of people wanting to document it, but as you probably noticed by now getting a decisions out of people on these matters is like herding cats. --Ray > On 13-12-2020 18:49, Ray Molenkamp via Bf-committers wrote: >> Seems like the reason has moved from "it's scattered all >> over the place, that's a bit fragile" (technical r
Re: [Bf-committers] Libraries source code
Seems like the reason has moved from "it's scattered all over the place, that's a bit fragile" (technical reason, which I will happily share/defend my views on) to "because I want it for political reasons" (where not a single technical argument will change your mind) In the future it's probably best to be upfront where a desire comes from rather than having it masquerade as a technical issue and hope no-one calls you on it. --Ray On 2020-12-13 9:29 a.m., Ton Roosendaal via Bf-committers wrote: > Hi, > > The reason is to protect software freedom in general. I don't like it that > for building Blender you are forced to use commercial sites offering code. It > would be different if we use established GNU approved platforms. > > https://www.gnu.org/software/repo-criteria-evaluation.html > > https://www.gnu.org/software/repo-criteria.en.html > > I would find it really a positive statement if we copy all external bundles > to blender.org and build from there. > > Nothing urgent though, it's politics :) > > -Ton- > -- > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation, Director Blender Institute > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > On 10/12/2020 16:02, Ray Molenkamp via Bf-committers wrote: >> I'm unsure what this would achieve beyond making the lib update process more >> frustrating than it already is? >> >> The deps builder we have its singe purpose is to facilitate the building of >> our SVN libs nothing more nothing less, its target audience is essentially 3 >> people (the mac/linux/windows platform maintainers) we share the script with >> the world since that's the spirit of opensource, but we offer very little >> (if any) support on it. Developers are advised to use the SVN libs and most >> distro's have their own build infrastructure for dependencies already. If >> you want to build all deps using our script on your own, good on you, we >> certainly won't stop you, but the script is aimed at a very narrow build >> environment (ours) with a very narrow use-case (our svn libs) it *cannot* be >> and *will not* be the end all and be all build script for all possible >> environments and all possible distributions. >> >> Having the source to all deps on our server would bring very little >> (actually just an extra burden) to the party, keeping that context in mind, >> what is the problem you are trying to solve? >> >> --Ray >> On 2020-12-09 8:14 a.m., Dalai Felinto via Bf-committers wrote: >>> Hi, >>> >>> At the moment the source code to build the libraries required by Blender is >>> scattered everywhere: >>> >>> * github >>> * sourceforge >>> * own projects sites >>> * archived pages on the web (e.g., http.debian.net for the bzip) >>> >>> For the complete list see: >>> `build_files/build_environment/cmake/versions.cmake` >>> >>> >>> Is there a reason for Blender to not host a copy of the compressed source >>> files? Given that we depend on almost 40 different libraries, it seems a >>> bit fragile to count on them be online forever. >>> >>> >>> The zip/tar.gz, ... packages could be stored in: >>> https://svn.blender.org/svnroot/bf-blender/trunk/lib/source >>> >>> >>> Thanks, >>> >>> -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 >> ___ >> 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 mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format
Seems reasonable (and I agree) however playing devils advocate: if we're going to need cairo down the road anyhow we may as well rip that band-aid off now and deal with the pain of building it rather than building libharu now and cairo later. --Ray On 2020-12-11 10:47 a.m., Brecht Van Lommel via Bf-committers wrote: > So weighing the options, to me libharu seems like the most reasonable > solution. > > > > On Fri, Dec 11, 2020 at 1:51 AM Campbell Barton via Bf-committers < > bf-committers@blender.org> wrote: > >> By this logic we could blindly accept any patch that's had some production >> testing, without considering long term maintenance. >> >> It's possible alternative solutions that call out to existing well >> maintained >> converters would have been fine in production too. >> It's not that I'm pushing back against including this entirely, >> I'm just not a fan of this "it worked in a production test - so lets >> include it" -- attitude. >> >> Over the years I believe we've spent significant time investigating >> issues with 3rd party libraries (resource leaks, conflicting symbols, >> linking problems, platform specific errors etc). >> If there is a good chance we can avoid this entirely, it could be >> worth looking into. >> >> If we do include libharu, how would this be included? in extern/ or >> would we bundle it in SVN's lib? >> >> On 12/10/20 8:26 PM, Dalai Felinto wrote: >>> Hi, >>> >>> My suggestion would be the following: >>> >>> * Stick to libharu since it was proven that works for the intended use >>> case. >>> * Make sure libharu integration in the code goes via a layer of >>> abstraction. >>> >>> So instead of trying now to solve an non-existent problem, we use >>> development time to make sure the existing solution is robust enough to >>> be replaced if needs be. >>> >>> Regards, >>> Dalai >>> >>> On 09-12-2020 23:34, Campbell Barton via Bf-committers wrote: rsvg-convert (which uses cairo), is a utility that converts SVG to PDF, it can create multi-page PDF's from many SVG's too. If for some reason we need more control then a command line utility provides, there are Python multiple options regarding bindings for cairo & svg conversion. From what I can tell they can convert SVG to PDF quite easily. Regarding bundling the conversion tools, if this it's only a few studios with specific requirements, we don't _necessarily_ need to include the conversion utilities with Blender, although this is a decision we could easily change. I'm not pushing for this as the final solution, just checking if it might be a simpler option compared to taking on a PDF library that isn't maintained anymore. ___ 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 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
Re: [Bf-committers] Libraries source code
I'm unsure what this would achieve beyond making the lib update process more frustrating than it already is? The deps builder we have its singe purpose is to facilitate the building of our SVN libs nothing more nothing less, its target audience is essentially 3 people (the mac/linux/windows platform maintainers) we share the script with the world since that's the spirit of opensource, but we offer very little (if any) support on it. Developers are advised to use the SVN libs and most distro's have their own build infrastructure for dependencies already. If you want to build all deps using our script on your own, good on you, we certainly won't stop you, but the script is aimed at a very narrow build environment (ours) with a very narrow use-case (our svn libs) it *cannot* be and *will not* be the end all and be all build script for all possible environments and all possible distributions. Having the source to all deps on our server would bring very little (actually just an extra burden) to the party, keeping that context in mind, what is the problem you are trying to solve? --Ray On 2020-12-09 8:14 a.m., Dalai Felinto via Bf-committers wrote: > Hi, > > At the moment the source code to build the libraries required by Blender is > scattered everywhere: > > * github > * sourceforge > * own projects sites > * archived pages on the web (e.g., http.debian.net for the bzip) > > For the complete list see: > `build_files/build_environment/cmake/versions.cmake` > > > Is there a reason for Blender to not host a copy of the compressed source > files? Given that we depend on almost 40 different libraries, it seems a bit > fragile to count on them be online forever. > > > The zip/tar.gz, ... packages could be stored in: > https://svn.blender.org/svnroot/bf-blender/trunk/lib/source > > > Thanks, > > -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 ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format
I can't say I'm super thrilled to build cairo on windows, but if that's the direction we want to go, so be it. --Ray On 2020-12-09 11:19 a.m., Brecht Van Lommel via Bf-committers wrote: > I'm not sure there exists a simple utility to convert SVG to PDF that we > could include, if we want to go that way? > > Inkscape uses Cairo for PDF writing, that could be a more actively > maintained alternative. > https://www.cairographics.org/ > > It has also been proposed to be added to handle Wayland window decorations > in D7989, so it would let us solve both problems with one library. > > > On Wed, Dec 9, 2020 at 11:46 AM Antonio Vazquez via Bf-committers < > bf-committers@blender.org> wrote: > >> There are several reasons why I decided to use libharu. >> >> * The PDF format is very stable and does not change substantially, so we >> are not at great risk due to format changes. >> * I already know that this library is not maintained, but since the PDF >> format does not change, it does not require much maintenance. >> * This library is widely used in other software to generate PDF, so it is >> well proven. >> >> Regarding the bugs you comment, I have seen that several have a patch to >> solve them, but in any case, the use I make of the library does not include >> using images, only a very simple use. I do not expect, in the short or >> medium term, to use anything related to appending images, so these bugs do >> not affect us at all. Attaching images to a PDF does not make much sense in >> our case. >> >> Including a converter from SVG could work, but the problem is that in PDF >> we can generate a document with several pages and in SVG I have not seen >> that this is supported. Imagine that we want to generate a storyboard with >> 100 frames ... we would need to export 100 SVG and join them later ... now >> that is very simple. We would also have to assess the speed of the >> conversion, since now it is all C / C ++ and it is very fast. >> >> The other option I have been considering is to fork libharu and create a >> tiny version with the functions we need and remove any appended image >> support. >> >> Antonio >> >> El mié, 9 dic 2020 a las 0:46, Campbell Barton via Bf-committers (< >> bf-committers@blender.org>) escribió: >> >>> Hi Antonion, >>> >>> From what I can tell libharu hasn't been very active since 2013, their >>> site states they're looking for a new maintainer. >>> Would we become the defacto maintainers of this library? >>> >>> I checked their issue tracker, while many reports are support requests >>> and build issues, there are some more serious looking issues too, eg: >>> >>> https://github.com/libharu/libharu/issues/73 >>> https://github.com/libharu/libharu/issues/71 >>> https://github.com/libharu/libharu/issues/63 >>> >>> Is there a significant advantage in integrating a library compared >>> with bundling a utility that converts SVG to PDF? >>> In this case it could be an optional dependency, or we bundle the >>> conversion tool in official releases so PDF support is still >>> integrated from a user perspective. >>> >>> On Wed, Dec 9, 2020 at 6:31 AM Antonio Vazquez via Bf-committers >>> wrote: Hi All, As some of you may already know, for version 2.92 we want to focus on >> the Import and Export processes of Grease Pencil (T83190). Currently, the grease pencil is in some way an "island" in the studios pipeline and we need to add tools to integrate it. Part of these integration processes were the work we did to make image traces (2.91) >>> and shortly, video traces (2.92). During the contacts that the members of grease pencil team usually have with 2D studios, they have detected that some commercial software very important in the studios pipeline does not support the import of SVG, >> but of PDF. In addition, the PDF format allows working in many softwares >> and >>> is very useful for generating storyboards and work in comics. Past weeks, I have been working on a new I/O module for grease pencil >> in >>> C ++ and I already have the SVG Importer (T79875) and the SVG Exporter (T83191) and PDF Exporter (T83192) working. All work has been done on a private branch on my PC. You can see a PDF exporter video here: https://youtu.be/BMm0KeMJsI4 To export to PDF I have used an open source library (libharu http://libharu.org/) and would need to integrate that library into >>> Blender. This library is very simple (<1.6 MB on Windows) and allows export to >> PDF easily. Finally, exporting to PDF opens up a world of possibilities and >>> especially when the new LineArt module will be integrated into Blender. If we agree to integrate libharu, I can prepare the patch for review >> the I/O code I did. I would like to hear your opinions.
Re: [Bf-committers] Code Quality Day - 4/Dec
For the windows folks, I have enabled clang-tidy for windows so you can now join in on the fun, but there are some caveats that are important to be aware of. 1- It will only be configured if WITH_CLANG_TIDY is on in cmake. 2- Only supported in the IDE, no ninja or command line support at this moment in time. 3- Disabled on build by default, it is really slow running the compiler twice, and it emits still a fair number of errors on bad code inside windows specific ifdefs. For those reasons you have to manually run it from the analyze sub menu. If you run into issues using it feel free to prod me on chat have fun tomorrow! --Ray On 2020-12-03 8:38 a.m., Sergey Sharybin via Bf-committers wrote: > Hi, > > This Friday we have December's code quality day [1]. > > The full list of approved projects for the quality day is combined in a > dedicated task [2]. > > Last day we finished what one might consider essential Clang-Tidy > integration warnings. There are now modernize category warnings enabled, > which helps us bring code to 2020 standards [3]. > > From the last day there is still [4]. It was partially tackled, but there > are still some ideas which can end up in a nice quality improvement. > > There are again some ideas I have in mind of improving the build process. > Let's talk about it tomorrow! > > I would also encourage every module to come with ideas (and solutions ;) to > what they consider a quality/technical-depth improvement! > > Everyone is welcome to help! > > For feedback on what to do, code review, and everything else we should use > #blender-coders in blender.chat. > > [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day > [2] - https://developer.blender.org/T73586 > [3] - https://developer.blender.org/T78535 > [4] - https://developer.blender.org/P1756 > > Have fun tomorrow, > -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
Re: [Bf-committers] Support for 32-bit architectures
I've always understood our position to be - We do not plan to break or remove 32 bit support. - Given we don't CI on 32 bit anymore, breakage can sometimes happen without us knowing. - If external parties supply patches to fix such breakage and they pass code review, we merge them. Even if they are for platforms we ourselves do not ship. D2860 (haiku OS) is a nice example there. I'm not sure if that is the official position, but that's my current understanding of it. --Ray On 2020-11-16 8:36 a.m., Sybren A. Stüvel via Bf-committers wrote: > Hello list, > > Blender 2.80 was the last version of Blender for which 32-bit builds > were officially supported. This was announced by Brecht in [1]. > That announcement was a bit unclear to me, which I let pass because it > wasn't that relevant for my position back then. However, now that I'm > the Linux platform maintainer, I wouldn't mind if the situation was > clarified. > > In that announcement, Brecht writes: >> Blender 2.80 was the last release where we officially support 32 bit Windows >> and Linux builds. [...] >> We will continue to support it to the level that we do for example ARM. That >> is we keep the Blender code working independent of the processor >> architecture, particularly for Linux packages. But we don't actively test >> them or release our own builds. > This sounds like an impossibility to me: the promise that we keep > things working, but without building, or testing. Apparently there is > also a distinction between "official support" and "support to some > level". > > The Blender requirements page [2] does list 64-bit as a requirement. > But, there is no "last version that supported 32-bit" in the "Previous > Versions" section of that page. Also there is no mention of dropping > official support for 32-bit architectures in the 2.81 release notes > [3]. > > I found out about this unclear situation when looking at a patch that > ought to fix an issue on 32-bit platforms [4]. In the discussion on > that patch, Brecht writes: >> When writing or reviewing code, you ensure that there is always a processor >> architecture independent code path. And if you get a report and it turns out >> such a code path is missing or broken, you fix it. It's the same for x86, >> mips, sparc, etc. > This looks like a statement that these platforms are still supported. > > Personally I would summarize the above as: > - Blender Foundation does not provide buildbots for 32-bit platforms. > - Developers have to ensure these platforms keep working. > - Testing such fixes is unnecessary. > > I think I'm misunderstanding the situation here, and I wouldn't mind > if this was clarified. > > Sybren > > [1]: https://lists.blender.org/pipermail/bf-committers/2019-August/050124.html > [2]: https://www.blender.org/download/requirements/ > [3]: https://wiki.blender.org/wiki/Reference/Release_Notes/2.81 > [4]: https://developer.blender.org/D9577 > ___ > 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
Re: [Bf-committers] Policies about patches modifying third-parties libraries.
While i agree with "you should be able to build blender even with stock/system libraries" I however do not think that the bar for "oh we'll just add it to /extern" should be as low as it appears to be. I'd be very much in favor of *NOT* adding a behemoth like USD to `/extern` (~75 megs, twice the size `/extern` currently, more than all the code in `/source` combined!) and ballooning an already high blender build time just to support a single IO format. Surely this can be worked out with upstream USD? --Ray On 2020-08-25 1:05 p.m., Bastien Montagne via Bf-committers wrote: > Hi, > > Under build_files/build_environment/patches we have a bunch of small patches > for the libraries we build using make deps. Most of them are about fixing > builds for some platform or architecture, which is a bit annoying but > acceptable imho. > > However, today I discovered that Blender cannot be built with vanilla USD > library, at all. The patch used on this library adds some new function to its > API, which (hack over hack) is not even declared in its headers, but in > Blender code itself. > > I would very much like to propose to strictly forbid such dirty practices, > which violate completely the very idea of libraries, especially on OSs like > linux, where distributions try very hard to only use dynamically linked > shared libraries. > > Any library that would need that kind of modifications should be put in > extern/, and explicitly built as part of Blender itself. Or at the very > least, we should explicitly maintain our own 'fork' of it, with requests to > the main repo/maintainers to integrate our changes or otherwise propose a > solution to the problem. > > But I do hope there are ways to avoid such ugly changes anyway? > > 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
Re: [Bf-committers] Future Releases with VR?
UPBGE is a blender fork we do not maintain, so any questions you have on UPBGE you'll have to sort out with the people who work on it. Their community page [1] has several options of contacting them. Greetings, Ray [1] https://upbge.org/community.html On 2020-04-10 12:58 a.m., Armani Bless via Bf-committers wrote: > Hello I know UPBGE is fairly new but I want to start a new game with a > python game engine. Will UPBGE be looking forward in developing in VR? > Maybe sometime in the next few years? I will be creating a hybrid game of a > VR and a real-time war strategy game. First I will developed the war > strategy game(ETA 1-2 years) then implement the VR spectrum. > I will love to hear your thoughts of the future of the company? > > Also how can I donate ? I want to donate a little every month. > ___ > 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
