On 11/5/2017 5:18 AM, Mike Gresens via Boost wrote:
I would suggest that any boost project should have MORE THAN ONE project owner.
- So we would have more developers with write access to the projects - Pull requests with features/bugfixes could be merged - No stagnation in projects (or less projects than now) - No need for so many projects to become CMT. There would be "fallback" project owners.
- There would be need for code reviews. Yes, for the code of project owners too! They should make regular merge requests to the other project owners. - In formal code reviews: not one developer against all others, but a team represents the project
"Project owner" means little as opposed to someone who actively wishes to have the responsibility of making code changes to a Boost library. Many people might say that they desire this, as you have said, but getting knowledgeable programmers to actually accept that responsibility and spend some time fixing bugs and merging PRs is another story. Boost needs programmers willing to do the latter but so often Boost will get people say that they are interested but once they realize the time they might need to spend as an active maintainer very few are willing to do so. So I do not think it is a problem of having more than one project owner as much as it is a problem of finding people who are knowledgeable and willing to contribute if they were given write access to a Boost library repository. Do you care to offer your service or time regarding some Boost library ? There are still Boost libraries for which no one is actively doing maintenance in a timely manner. When someone posts a message about why such-and-such PR is being ignored it is almost always because the so-called maintainer(s) for that library have been paying no attention for a long period of time, or anymore at all, to that library.
Mike...
Am 02.11.2017 um 17:37 schrieb Edward Diener via Boost:
The following libraries still have PRs, which I have previously submitted, for removing the executable attribute for one or more files:
foreach polygon xpressive bimap ptr_container gil assign typeof msm
None of these PRs affect anything other than the file attribute, so no testing is needed AFAICS since no code changes. If the maintainers of the above libraries, or someone else with write access to these libraries, can merge the appropriate PR to 'develop', and then merge 'develop' to 'master', we can get rid of having any files with their executable attribute set in the next release.