Libraries update took too long #80830

New Issue

Dalai Felinto · 2020-09-16T11:13:48+02:00

Dalai Felinto commented

2020-09-16 11:13:48 +02:00

This got on the way of grease pencil patches review/submission, getting too close to bcon2. The bcon2 is today and we still don't have all the libraries, leave alone the patches to be reviewed with Grease Pencil features.

Dalai Felinto commented

2020-09-16 11:13:48 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Dalai Felinto commented

2020-09-16 11:13:48 +02:00

Added subscriber: @dfelinto

Ray molenkamp commented

2020-09-18 22:01:38 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2020-09-18 22:01:38 +02:00

Code review (D8662) kind of dragged out on that one, which was weird, since it was a pretty straight forward lib with no crazy things in it, the patch was posted nearly a month before the bcon2 date and was mentioned in both the 2020-08-24 and 2020-08-31 meeting notes, complexity wise it was no different than D8384 (GMP) which sailed through in about a week.

Code review ([D8662](https://archive.blender.org/developer/D8662)) kind of dragged out on that one, which was weird, since it was a pretty straight forward lib with no crazy things in it, the patch was posted nearly a month before the bcon2 date and was mentioned in both the 2020-08-24 and 2020-08-31 meeting notes, complexity wise it was no different than [D8384](https://archive.blender.org/developer/D8384) (GMP) which sailed through in about a week.

Sergey Sharybin commented

2020-09-22 15:33:06 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2020-09-22 15:33:06 +02:00

From my understanding part of the problem was lack of fully set up build environment for macOS. Think Sebastian and me figured this out now. There are few improvements still possible and we will make those.

Another part of the problem comes from process organization (again, from my vision, or, rather, point of view). When new library is added, we always had a brief go-nogo moment with other developers to see whether we even want the dependency. This is something format answer from Brecht in the PugiXML patch helped a lot.

For the rest, I would really propose the following: get the make deps part to the master branch as quickly as possible. It makes it way easier for the Linux to make required fixes directly in Git rather than re-iterating over the patch.

So the process as I see it should be:

Core team / The Chieftain approves the inclusion of the library.
The platform maintainer who first implemented the preliminary support, puts it to master.
The same platform maintainer creates a task to track of the rest of the platform (example: #80818) and lets everyone to know.
All the platform maintainers starts to build the library, making needed changes to Git as/if needed.

From my understanding part of the problem was lack of fully set up build environment for macOS. Think Sebastian and me figured this out now. There are few improvements still possible and we will make those. Another part of the problem comes from process organization (again, from my vision, or, rather, point of view). When new library is added, we always had a brief go-nogo moment with other developers to see whether we even want the dependency. This is something format answer from Brecht in the PugiXML patch helped a lot. For the rest, I would really propose the following: get the `make deps` part to the master branch as quickly as possible. It makes it way easier for the Linux to make required fixes directly in Git rather than re-iterating over the patch. So the process as I see it should be: * Core team / The Chieftain approves the inclusion of the library. * The platform maintainer who first implemented the preliminary support, puts it to master. * The same platform maintainer creates a task to track of the rest of the platform (example: #80818) and lets everyone to know. * All the platform maintainers starts to build the library, making needed changes to Git as/if needed.

Sebastián Barschkis commented

2020-09-22 16:54:55 +02:00

Added subscriber: @sebbas

Sebastián Barschkis commented

2020-09-22 17:02:19 +02:00

The platform maintainer who first implemented the preliminary support, puts it to master.>

@Sergey I assume "preliminary support" will be treated like new features, i.e. must go in in bcon1?

> * The platform maintainer who first implemented the preliminary support, puts it to master.> @Sergey I assume "preliminary support" will be treated like new features, i.e. must go in in bcon1?

Sergey Sharybin commented

2020-09-22 17:11:46 +02:00

I assume "preliminary support" will be treated like new features, i.e. must go in in bcon1?

Preliminary support as in: MaintainerOne made it to work for PlatformOne. Without worrying about other platforms, without waiting for other maintainers to test the patch before it gets committed.

I don't think bcon1 requirement is applicable in general. For the new dependencies yes, it should be bcon1. But I don't see a problem of updating existing libraries at bcon2 and even bcon3 if this is required to have some bug fixed.

> I assume "preliminary support" will be treated like new features, i.e. must go in in bcon1? Preliminary support as in: MaintainerOne made it to work for PlatformOne. Without worrying about other platforms, without waiting for other maintainers to test the patch before it gets committed. I don't think bcon1 requirement is applicable in general. For the new dependencies yes, it should be bcon1. But I don't see a problem of updating existing libraries at bcon2 and even bcon3 if this is required to have some bug fixed.

Ray molenkamp commented

2020-09-22 17:33:50 +02:00

In #80830#1021100, @sebbas wrote:

The platform maintainer who first implemented the preliminary support, puts it to master.>

@Sergey I assume "preliminary support" will be treated like new features, i.e. must go in in bcon1?

I try to get all work in in bcon1, so the other platform guys have part of bcon1/2 to do their work, it's essential to get it done before bcon3, once a release branches libs become an absolute hassle to deal with, we did that once, and i'll literally will work nights and weekends in bcon1/2 if required it that means no lib updates in bcon3

> In #80830#1021100, @sebbas wrote: >> * The platform maintainer who first implemented the preliminary support, puts it to master.> > > @Sergey I assume "preliminary support" will be treated like new features, i.e. must go in in bcon1? I try to get all work in in bcon1, so the other platform guys have part of bcon1/2 to do their work, it's essential to get it done before bcon3, once a release branches libs become an absolute hassle to deal with, we did that once, and i'll literally will work nights and weekends in bcon1/2 if required it that means no lib updates in bcon3

Thomas Dinges added this to the 2.91 milestone 2023-02-08 16:19:12 +01:00

Brecht Van Lommel closed this issue

2023-03-23 18:18:15 +01:00

Blender Bot added

and removed

labels 2023-03-23 18:18:16 +01:00

Sign in to join this conversation.