-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Delegate module maintainership #6485
Comments
BTW: https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
|
Yep, we should use that.
Yep, I would like to get it merged, after a proper review of course. |
Conceptually this is good. Maintainers do then get the burden of keeping the usage "feel" similar to other parts of Meson. |
Following proposal in mesonbuild#6485 we would like to delegate maitainership of parts of the Meson project (modules) to selected volunteers.
Following proposal in mesonbuild#6485 we would like to delegate maitainership of parts of the Meson project (modules) to selected volunteers. Fixes: mesonbuild#6485.
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. |
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. |
@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. |
Note that meson does not guarantee APIs so it could fail any time, but in practice I guess it shouldn't be too bad if you don't start using too many internal methods. |
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?
Examples:
Of course this won't solve everything, but could be a good start. What do you think?
The text was updated successfully, but these errors were encountered: