Should have gotten invite for new meeting series, in 2 weeks, should be from meetings@lfx.linuxfoundation.org, reach out to me if you haven’t received it
Will drop a link in the chat to register for meeting
Joshua: should all the projects / wgs use this? John: will work with projects to move over, some work needed in backend management. Have been working with a couple of projects, will be done by end of year. Joshua: DPEL has transitioned, there were a couple of wrinkles, want to figure out a smooth way to do this. Does the new system require everyone to have some kind of LF account? John: it requires a LFX account, but if you’ve registered for any event in last two years, you would have an event. Joshua: will need to explain to everyone attending meeting, that’s a bit of additional friction.
Kimball: we should make sure most meetings have an open / public Zoom, don’t want to discourage people from contributing / attending. TSC / WG meetings should also have open Zoom links.
John: for all these there is a open link, there’s a small step to register for the meeting, and you can use GitHub / Google / … as an IDP.
Matthew: will the ASWF calendar have updated links as well? That’s useful. John: yes, we will update calendar as we move projects over.
Eric: what’s the advantage? John: makes it easier for projects to manage who is attending, avoid zoom bombing, making sure that meetings have a degree of security / management, also able to see the degree of engagement, who is attending and how often. A good way for maintainers to gain engagement. Also integration with LFX suite of tools, https://openprofile.dev has your profile with all my meetings, can also get to recordings from there. Helps to centralize engagement across multiple projects.
Eric: for DPEL we write the attendance in the minutes and prefer minutes to the recordings. John: yes, you can continue to do this. Projects can still opt in / out of recordings. The Individual Dashboard hopefully will help with calendering issues in the past. Eric: that part looks great. If we are posting a public zoom link, then it’s a public meeting. John: zoom bombing doesn’t happen often, but it can be embarrassing.
Cary: we should keep the bar as low as possible for participation in TSC meetings, have never had a zoom bombing issue. Attendance is pretty easy to take in the notes.
Carol: on the user facing side, will we still have separate calendars for projects vs ASWF in general? Currently it’s hard to create and edit events, if we get a better experience, have people be able to sync events to their calendars, that seems like enough of a win to switch over. John: the experience is better, you get a personal invite every time, makes it straightforward. Experience of getting on and off calendars is a lot easier. Aim is that a general calendar will be easier, can pick the ones you want to sign up for. https://openprofile.dev has a My Calendar function, should show everything that should be on my calendar, so have a lot of ways to track what meetings you need to attend. Carol: will need to try it, for the folks who aren’t regular attendees, doesn’t seem to make experience easier? Larry: can be very confusing to find the right login link over all the channels. John: the idea is that even if you are registered for a meeting, you can still hit the public link. It should help, as well as the calendar you can verify in your profile, as well as a secondary calendar for public meetings in general. The public calendar is how we do it today, it’s a bit of a kludgy way to solve the problem. We don’t make a ton of overwhelming difference, but should have a place to get the right link. Still good for leads to announce ahead of a link, makes it as easy as possible to join.
Carol: for now I just use the overall ASWF calendar feed and link that to Google Calendar. John: that should still work. It’s been working well with the Board for that last few months, and lots of other projects are using it successfully.
Want to promote and ask for help. Started to mock up spreadsheet, input so far has exceeded expectations. Want to encourage people from projects / vendors / studios to fill out parts that aren’t filled out yet. This is something you want to periodically revisit as your project progresses, also new rows and columns are being added that might not have existed initially.
Lots of interesting data, 2 specific points:
For any column which is a dependency, interesting to see across all projects who is using which set of versions. In at least one case, this is inspiring me to move minimal versions forward in my projects
Also interesting to see the dependencies of various projects
Feel free to circulate this around and contribute, had to turn off anonymous editing since had to revert a mistake. So use a suggestion / comment to suggest a change, or just request edit privileges and I will give you access.
Any questions? Anything else would be useful?
Kimball: not sure where it’s going to go, but a very interesting exercise. Maybe help us guide how we maintain our projects. Not sure how to capture this, but we run into problems with a specific version of a DCC that will use a specific version of PNG, which isn’t on the VFX Platform list, so can run into conflicts. Larry: a good example of where I rely on people as to what should be tracked. If libpng is important to you, you can go ahead and use it. It’s a living document, and it should grow as people feel it’s useful.
Kimball: hopefully helps people who are providing software.
JF: could help identify problematic candidates for VFX Platform inclusion?
Eric: are Rocky / Alma / future Linux platforms on there? Larry: they are supposed to be bug for bug compatible with RHEL8, so that should cover those? That’s the theory, we’ll see if the practice matches. May be worth adding an annotation, which of the many distributions listed here is the one people will coalesce on. We all know that our projects are not just used in the VFX Platform environment, so that’s not the boundary of our concerns of what we have to maintain for and what our users expect.
Kimball: we are also capturing versions installed on base systems. Thank you for putting this together!
Cary: looks for old numbers of OpenEXR, looking for projects that need help moving forward. You can get this information this here, but a lot of the entries are things like Maya 2019, a dependency that’s not going to change. How can the information be presented to separate:
I’m a project maintainer, how can I help move everyone forward
I’m a developer, how do I manage the web of dependencies
Gordon: could be interesting to track targeted VFX Platform versions and see where projects deviate
Carol: have we shown this to anyone specifically? Larry: posted link to VFX Platform mailing list, got a lot of updates directly after that, so people involved would know about this. Carol: this is a great, maybe the VFX Platform should maintain this? Larry: they have resisted this, try to have a narrow focus, the platform is supposed to focus on problematic packages, also they publish a list for each year. As a package maintainer / studio representative, there’s a lot more info, and this spreadsheet may help to surface it. Carol: should be made aware at VFX Platform level, make sure it’s known how useful it is.
Kimball: we’ll keep capturing the data, and will likely have VFX Platform coming to join a TAC meeting soon?
Chat: Scott: I sort of want to take this and throw it in a db. Kimball: but that would involve making a web page to browse and edit. Eric: Who’s going to set up autogenerated dependency graph?
CIWG -> IWG: fate of utility projects? (Larry)
Origin is Tom Cowland communicating about the idea of a file abstraction layer, such a class exists in OpenImageIO, maybe we should cleave this off and make it a tiny dependency that other projects can use. I’m supporting this, but where should such things live? In one of the existing projects seems like the wrong place if it’s going to be shared. So it could be a ASWF project, but that has too much overhead, so maybe the solution is just a small repo, shudder at the idea of putting that under ASWF needing more calendars, TSCs, CLAs, meetings… That seems crazy. But at some point we may have 10-20 small projects that shouldn’t be “full” projects. Since these are common pieces of infrastructure, maybe the CI WG could be the right home for this? The CI WG is mostly no longer about CI per se, the idea I want to float is that the CI WG can morph into the “Common Infrastructure” group and can be the home for common pieces of infrastructure. It also feels like the right people around the table, what do we want for the future of the CI WG? Does it make sense to grow into that direction? Is it still a WG if it’s doing this? This has been swirling around, and wanted to get this discussion in the open.
Kimball: I’ve been trawling through our pile of code, over the years I’ve found 10 or 12 different takes of using a logging system, they all have different features and strengths, have been collating this into an abstraction. There’s an example with iMath getting split off from OpenEXR, without having the full weight of a project.
Chris: we are talking about IOProxy? Larry: yes, but it’s just an example. Chris: if there’s something that all projects want to share and is clearly defined, that’s good. But something like IOProxy may be a small, well defined thing, but as it gets used, it will get added to, and changing something at the root of the dependency graph may be problematic and create more “versionitis”. So we want to be careful with this. The way IOProxy is done in OIIO is good, it’s tied to what OIIO, but if it gets extended, could become a maintenance problem. Just because it’s a small library, the decisions still need to be taken carefully.
Larry: noted, we have discussed that, how do we prevent scope creep from making this an impossible project. Kimball: having common error reporting from projects could be an interesting thing. Chris: lots of possibilities we could use, but it becomes a dependency you have to add to every project. Most projects decide to roll their own, “info/warning/error”, next thing you know, every library you integrate has their own.
Chris: we may want to wait until we have more than one project?
JF: Aswf-docker is an example of an existing, common dependency.
Kimball: does the CI WG want to change its charter? Larry: it does imply that the WG is an ongoing concern and that it owns code. It wasn’t in the initial conception of what a WG is. Kimball: we have example of D&I WG as a long running WG. Larry: on the day we created CI WG, we would be done when we figured out a CI pipeline.
Kimball: not doing review until next year, maybe if we want to keep moving forward we could move this up? Larry: not a deadline associated with this, just the conversations were happening.
Kimball: we are going through an internal process to collect various small “bits” and refactor them.
Thanks to input, Emily submitted a proposal for a 60m presentation at GDC for USD in games, we should hear back from them end of November, if we get accepted, do we want to use this to do marketing for other AWSF projects, it would be an ASWF presentation. Also do socializing around the event.
DCC API archive considerations [Michael Min]
Looking at software for asset archiving. Is there a common repo from DCC providers for APIs. We are dealing with almost every permutation of software, someone was asking if there’s a consideration to archive APIs for future reference, in case you need to rebuild assets around these DCCs. Not aware of any.
Eric: would this be a document? An executable? Michael: from his perspective, the API referencing a particular build of Nuke for instance. More of a general question. Kimball: that’s sort of why the Academy did the ACES specific to have an ACES EXR subset for archival requirements. Git history provides a record, but this is something different? Michael: this is products who may or may not have published.