Meta: add more repository maintainers
aminya opened this issue · comments
I am opening this issue specifically because it seems that @lefticus is not able to review and merge all the pull requests, and so many of them are left open. One way to fix this is to add more maintainers to the repository.
27 PRs are open at the moment
https://github.com/lefticus/cpp_starter_project/pulls
Agreed. It's a lot of work to maintain a popular repository like this, and @lefticus should not feel bad about not having enough time to do it. I think there are lots of people here that would be willing to help.
The last commits were merged more than 7 months ago. It's easy to get the impression that this project was abandoned, and I don't think that's the intention here.
That's a fair point. For this project it's really more a matter of forgetting to check and see that I have open PR's, and less about available time! I'll dig through this all shortly and come back to this issue.
The two of you are the most active on here, and the obvious candidates for helping out with PRs.
You generally seem to agree with the same things I do, as well. My only comment is that I am opposed to the external conan configuration file, and want to keep things internal as conan_cmake integration.
What are your thoughts about this?
I would be happy to be able to help!
You generally seem to agree with the same things I do, as well. My only comment is that I am opposed to the external conan configuration file, and want to keep things internal as conan_cmake integration.
If by an external Conan file you mean #126, I have to say that currently the dependencies are scattered all around the CMake files. Having a central place to manage all of those is much easier than remembering where a dependency is stored.
However, I am also more biased over a simple conan.txt file like #65. Since it is a simple list of the dependencies and versions.
@aminya My observation in real-world open source (but commercially funded) projects is that if the user has to run conan as a separate tool (that you can forget to run, or can get out of date accidentally), then that is a non-starter.
So I want full cmake integration, so that builds are
<configure>
<build>
and there is no intermediate
<configure>
<run other tools (aka conan)
<build>
From the projects I've worked on, this is more important than you'd think, so I want to keep C++ Starter Project as simple to configure and build as possible, and leave the option of an external conanfile.py up to the user after forking/templating this project, but not a requirement to getting started.
This is why I've avoided merging any of the previous conanfile PR's.
The two of you are the most active on here, and the obvious candidates for helping out with PRs.
I am happy to help too, but I am given to bad decisions, so I would rather not be given too much power. Maybe we could have an "at least 2 approvals required to merge" sort of system, and assign 3+ people to be approved reviewers?
My only comment is that I am opposed to the external conan configuration file, and want to keep things internal as conan_cmake integration.
What are your thoughts about this?
In #65, @aminya mentioned that with an external Conan config file, you can use external utilities to automatically bump dependency requirements. I think that 's a useful feature. Unfortunately, my google-fu is failing me, and I can't find any such utilities online. I bet anybody could write one though, and it would be easier to do so with an external file.
I think the guiding principle here should be "What makes the best example for new users?" The Conan docs describes the Conanfile.py as the way to specifying conditional dependencies, and I think the developers expect you to do this way. In an example project like this, you want to follow the documented procedures as much as possible, and in our case I think that means using a Conanfile.py. #126 may not be the best example of a Conanfile.py (the way that I passed variables from CMake to Python is super awkward), but I think it's easy enough for someone who's never used Python before to understand.
However, I am also more biased over a simple conan.txt file like #65. Since it is a simple list of the dependencies and versions.
I like the simple list too, but the last time I tried using #65 with CPP_STARTER_USE_IMGUI turned on, Conan never tried to install imgui: #65 (comment)
Edit: just tried #65 again, and it didn't install imgui.
OK, I see you've both agreed that #126 looks good. And just for the record, as I've gone through PRs the last could of days, if at least one of you approved it, then I pretty much just immediately approved it too.
@ddalcino, if you don't want too much power, I'll try to at least give you power to close issues 😄
@ddalcino, if you don't want too much power, I'll try to at least give you power to close issues 😄
Ok cool. There are a couple of stale issues that should probably be closed now, and I'm happy to do that. I'll try to review more PRs when they come in as well.
I think I have to create an org to give fine-grained control, but I'll sort it out.
Ok. I think you just gave me permissions to push, but I will act as if I don't have them until you get the org sorted out.
I did, but then I made two other decisions:
- I made moved from "master" to "main" for the default branch, to be more consistent with modern naming of these things
- I added a branch protection that requires at least 2 code reviews before a pull
So if I go missing again you and @aminya can collaborate on a PR before it goes through
Are we good closing this issue now?
Are we good closing this issue now?
Yes!
Yes, I will close it. Thank you, everyone!