Assigning "sub maintainers" for Windows and cmake!
Date: Mon, 21 May 2018 17:41:19 +0200 (CEST)
I do a lot of stuff in this project. I merge something like 80% of all commits
and I (currently) author around 60% of all commits. I do this because I think
it's fun and I enjoy doing it. And I feel that know the technologies involved.
There are however two specific areas that are *definately* not my areas of
expertise and I sense that our project suffers a bit because I don't easily
merge patches done within those areas and there's an unclear situation on how
to go about and get things done there.
I'm talking about cmake and Windows.
I've tried to urge people to speak up with +1's or -1's on PRs and issues to
use as a guide for me to know how to act on them, but I think this approach
hasn't worked out very good. Possibly because in several situations I've
gotten a bunch of arguments both for and against things and then I don't know
what to do and nobody else feels empowered to step up and make an executive
If at all possible, I would like to try to assign two individuals as
designated maintainers of code that is cmake specific and Windows specific.
Those two persons would be allowed to and have the responsibility to merge
code for those areas without my blessing or me even having to look at the
patches. (Because my looking at such patches are really not very helpful.)
Requirements for these maintainers would be that they know the area, they're
familar with the curl project and the way we do things and that they have time
and energy to devote to this.
If you would consider taking on this task or if you want to nominate someone
else for one of these roles, please let me know. It's fine to contact me
privately about this if you rather not want to take it here at once.
cmake, 9 currently open issues:
Windows, 7 currently open issues:
-- / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2018-05-21