Page MenuHome

Libraries update took too long
Confirmed, NormalPublicTO DO

Description

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.

Event Timeline

Dalai Felinto (dfelinto) changed the task status from Needs Triage to Confirmed.Sep 16 2020, 11:13 AM
Dalai Felinto (dfelinto) created this task.

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.

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: T80818) and lets everyone to know.
  • All the platform maintainers starts to build the library, making needed changes to Git as/if needed.
  • The platform maintainer who first implemented the preliminary support, puts it to master.>

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

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.

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

@Sergey Sharybin (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