[foreach][polygon][xpressive][bimap][ptr_container][gil][assign][typeof][msm] PRs for removing executable attribute for files
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.
Edward Diener wrote:
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
Are any of these candidates for community management?
On 11/3/2017 5:56 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
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
Are any of these candidates for community management?
No. I already took care of any CMT libraries that had such files. Thanks for taking care of the above libraries.
On 11/04/17 01:06, Edward Diener via Boost wrote:
On 11/3/2017 5:56 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
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
Are any of these candidates for community management?
No. I already took care of any CMT libraries that had such files. Thanks for taking care of the above libraries.
I think CMT should have push access to all libraries, even those with active maintainers. There are times when maintainers are not able to work on their libraries and someone has to do at least basic maintenance instead. Some of the mentioned libraries, though, don't have an active maintainer. I'd say, assign, foreach, ptr_container, typeof, xpressive are possible candidates for community maintenance.
msm
This one has significant unmerged differences between master and develop. Is Christophe active?
The situation is similar in 'ptr_container': many significant differences between master in develop. In addition, the tests fail, in a manner that does not immediately evoke a fix. The tests for 'assign' fail too. 'assign' and 'ptr_container' seem candidates for community maintenance.
On 11/4/2017 11:23 AM, Peter Dimov via Boost wrote:
msm
This one has significant unmerged differences between master and develop. Is Christophe active?
The situation is similar in 'ptr_container': many significant differences between master in develop. In addition, the tests fail, in a manner that does not immediately evoke a fix.
The tests for 'assign' fail too.
'assign' and 'ptr_container' seem candidates for community maintenance.
It is a real problem to find people to take over maintenance of a library when the author or current maintainer can no longer do so. I am surprised that Eric Niebler ( foreach, xpressive in the title ) no longer maintains his libraries because they are usually so solid they need little maintaining, but everyone eventually moves on to other things. I do wish that the Boost Steering Committee would be more proactive in encouraging C++ programmers who might be good enough to maintain a Boost library to do so, when they post on the list about having an interest in Boost. More libraries placed in CMT is not a viable long-term solution because of the limited numbers of developers in the CMT group.
Edward Diener wrote:
I do wish that the Boost Steering Committee would be more proactive in encouraging C++ programmers who might be good enough to maintain a Boost library to do so, when they post on the list about having an interest in Boost. More libraries placed in CMT is not a viable long-term solution because of the limited numbers of developers in the CMT group.
On the contrary. A library should always be placed in CMT first before being given to a new maintainer. Once a person emerges whose pull requests to the library demonstrate ability and long-term willingness to maintain it, the library may be handed over to him. Not before. The CMT's primary task should be to merge pull requests. Not that much manpower is required.
On 11/4/2017 11:54 AM, Peter Dimov via Boost wrote:
Edward Diener wrote:
I do wish that the Boost Steering Committee would be more proactive in encouraging C++ programmers who might be good enough to maintain a Boost library to do so, when they post on the list about having an interest in Boost. More libraries placed in CMT is not a viable long-term solution because of the limited numbers of developers in the CMT group.
On the contrary. A library should always be placed in CMT first before being given to a new maintainer. Once a person emerges whose pull requests to the library demonstrate ability and long-term willingness to maintain it, the library may be handed over to him. Not before.
The CMT's primary task should be to merge pull requests. Not that much manpower is required.
The manpower involves having a member of the CMT group understand code in nn different libraries in order to decide if a merge request is valid or not. It is very easy to say "just merge code" but the reality is much different.
Edward Diener wrote:
On the contrary. A library should always be placed in CMT first before being given to a new maintainer. Once a person emerges whose pull requests to the library demonstrate ability and long-term willingness to maintain it, the library may be handed over to him. Not before.
The CMT's primary task should be to merge pull requests. Not that much manpower is required.
The manpower involves having a member of the CMT group understand code in nn different libraries in order to decide if a merge request is valid or not. It is very easy to say "just merge code" but the reality is much different.
I know what it involves. None of that invalidates any of what I said.
'assign' and 'ptr_container' seem candidates for community maintenance.
In fact, nobody currently has write access to boostorg/assign and boostorg/ptr_container, which seems a good indication for them being already de-facto "community-maintained", admittedly by a highly select community. So I'm giving the CMT write access to them.
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 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG On 11/05/2017 03:18 AM, Mike Gresens via Boost wrote:
I would suggest that any boost project should have MORE THAN ONE project owner.
This seems like a futile suggestion (unless you are volunteering).
- 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
In Christ, Steven Watanabe
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.
participants (5)
-
Andrey Semashev -
Edward Diener -
Mike Gresens -
Peter Dimov -
Steven Watanabe