[RFC] Delegate module maintainership

[xclaesse]

I would like to start by thanking the enormous work @jpakkane is doing with the Meson project. Being a maintainer is hard and ungrateful work, I'm really pleased by the time and effort he has always put in the project. If meson is so successful today it's thanks to him first.

I've personally been involved in the Meson project for about 2 years now, and while the project gets a continuous stream of contribution from everyone, I feel we are underpowered regarding maintainership and reviewing of patches. It is often a frustrating bottleneck.

I would like to suggest the idea of delegating maintainership of meson modules to individuals, who will be in charge of reviewing/approving patches touching their module. This means they would be responsible to approve or reject new methods and features in their module. That way @jpakkane can focus on the core of Meson.

The side effect of this proposal is to allow more flexibility to experimental modules that would not always match the same stability standards than the rest of Meson, as long as it has a clear maintainer and popular use-cases. Yes I'm thinking about a "cargo" module.

Why modules?

• They have self-contained code base, it's easy to know who is responsible for each PR.
• They have dedicated doc page, where we can make it clear when it's unstable/experimental/deprecated/etc.
• Easy to just drop/deprecate the code altogether if it turns out the experiment is a failure, or has been replaced by better alternatives.
• Easy to document who is in charge for each module, so contributers know who to talk to.
• In most projects this would be achieved by external plugins, but I personally don't like spreading the code base, and that would require to design stable public API which is not really the biggest strength of python.

Examples:

• I hereby offer becoming maintainer of pkgconfig module. :-P
• @nirbheek has offered to maintain a future cargo module.
• @mensinda is already maintaining cmake module.
• I'm sure people will step-in for other modules, comment below ;-)

Of course this won't solve everything, but could be a good start. What do you think?

[marc-h38]

BTW: https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners

CODEOWNERS are automatically requested for review when someone opens a pull request that modifies code that they own."

Yes I'm thinking about a "cargo" module.

Cargo integration in Meson via an "unstable-cargo" module (try 2) #2617

[xclaesse]

BTW: https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners

CODEOWNERS are automatically requested for review when someone opens a pull request that modifies code that they own."

Yep, we should use that.

Yes I'm thinking about a "cargo" module.

Cargo integration in Meson via an "unstable-cargo" module (try 2) #2617

Yep, I would like to get it merged, after a proper review of course.

[jpakkane]

Conceptually this is good. Maintainers do then get the burden of keeping the usage "feel" similar to other parts of Meson.

[xclaesse]

Conceptually this is good. Maintainers do then get the burden of keeping the usage "feel" similar to other parts of Meson.

@jpakkane I get this is a green light for resubmitting the cargo module proposed in #2617? Thanks.

[jpakkane]

Well everyone is free to submit anything they want. Whether they get accepted or not is a different matter. :)

[xclaesse]

Well everyone is free to submit anything they want. Whether they get accepted or not is a different matter. :)

That's not a reply. We are not going to put effort again in that cargo plugin if you're going to block it again like you did, and wasted @nirbheek 's time. The question here is: if @nirbheek and myself submit a cargo module and we offer to maintain it, would you accept it even if you don't agree with the idea? That's the whole point of this issue here: delegate modules to dedicated people and give them the final word even if you don't like it.

[marc-h38]

Related question: for temporary prototyping purposes, is it possible to implement a meson module outside the main git repo? I mean without making changes to the main git repo. If not then what is the minimum number of lines / "hooks" required in the main repo? Just a rough order of magnitude.

Same question for shadowing an existing module (with a different "branch" of it).

I bet these questions can be answered quickly by examining existing modules, however I don't know anything about meson's module system.

[xclaesse]

@marc-h38 I would say, use your own branch of Meson in that case. You could for example create a build script in your project that git clone your branch of meson, and invoke it instead of system meson.

[dreamer-coding]

Will @marc-h38 it actually has been done. At this repo you would find that the answer to your question is yes, there can be third-party Meson modules.