RFC: Community maintained libraries
Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers. Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global. GitHub gives us some additional tools; write permissions are given at the Team level, and a team can have permissions across multiple specific repositories. Strawman Proposal ------------------------- For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership. We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance. Comments? --Beman
On Wednesday 04 December 2013 09:47:52 Beman Dawes wrote:
Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers.
Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global.
GitHub gives us some additional tools; write permissions are given at the Team level, and a team can have permissions across multiple specific repositories.
Strawman Proposal -------------------------
For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership.
We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance.
Comments?
I like the idea. It allows to keep the unmaintained libraries in good shape. I'd like to be in the Community team. I'm not sure how much time I would be able to devote to accepting patches since I have a few libraries to maintain. But I'd like to be able to commit patches to the libraries I'm interested in (like Boost.DateTime, for example).
On 4 December 2013 14:47, Beman Dawes <bdawes@acm.org> wrote:
Strawman Proposal -------------------------
For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership.
We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance.
Comments?
Just a thought, since Boost lives at GitHub: - "Community" team would be boost (at) lists.boost.org - patches and contributions received as Pull Requests at GitHub - "Community" reviews a PR at GitHub and the mailing list - once reviewed, a PR is voted on the mailing list and either accepted or rejected -- if accepted, a volunteer receives task to merge PR into develop A kind of system of micro reviews. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
On Wed, Dec 4, 2013 at 8:11 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
Just a thought, since Boost lives at GitHub: - "Community" team would be boost (at) lists.boost.org - patches and contributions received as Pull Requests at GitHub - "Community" reviews a PR at GitHub and the mailing list - once reviewed, a PR is voted on the mailing list and either accepted or rejected -- if accepted, a volunteer receives task to merge PR into develop
A kind of system of micro reviews.
Doesn't github already have a review system with votes and comments for each PR?
On 4 December 2013 21:40, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
On Wed, Dec 4, 2013 at 8:11 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
Just a thought, since Boost lives at GitHub: - "Community" team would be boost (at) lists.boost.org - patches and contributions received as Pull Requests at GitHub - "Community" reviews a PR at GitHub and the mailing list - once reviewed, a PR is voted on the mailing list and either accepted or rejected -- if accepted, a volunteer receives task to merge PR into develop
A kind of system of micro reviews.
Doesn't github already have a review system with votes and comments for each PR?
Yes, it does. I just simplified/assumed the list is still the place where reviews happen. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
Beman Dawes <bdawes@acm.org> writes:
Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers.
Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global.
... snip This is something I've been thinking about recently, since all the hoohaa when Stephen Kelly tried to clean up multiple libraries: ===================================== The role of Boost library maintainers ===================================== Boost's approach is unusual for an open-source project in that it considered a maintainer to be a library's single point of contribution rather than a guide and mentor for multiple contributors. Even open-source projects with a clear BDFL do not expect every patch to pass through that that single person. Instead there are a select group of committers who are trusted to make sensible decisions. On occasion, the BDFL may object to a change that has been committed and argue for it to be rolled back, but there is no 'prior restraint' of the type practised by Boost. So why is this a problem? The cost of this approach is clear from this list alone. Patch submissions are ignored. Bug reports are not dealt with. Discussions about improvements come to nothing because the one person able to do anything about them, the maintainer, loses interest. None of this is the maintainer's fault. They are all busy people and naturally more motivated by their own use-cases than by those of others. However, this is also the reason why giving one person absolute control over each library is not in the project's best interests. Sure, in theory a library can be passed to a new maintainer if the previous one is considered to be absent, but this is very rare partly because of how we define a maintainer's status. ================= Maintainer status ================= The discussions on here treat this as a binary: a maintainer is active or absent. The trouble is, it doesn't work like that. Even active maintainers have very different levels of engagement. A maintainer who commits the occasional a bug fix is considered active, and yet their library is never going to be exploring new territory or pushing boundaries the way an enthusiastically maintained one is. Maintainers who have just enough involvement to act as a 'keepalive' are considered active and the library is left in their sole control. ======== Proposal ======== My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role: Rights of the library maintainer -------------------------------- - To make any changes to the library they see fit, unless overruled by a formal vote (see below). - To roll back any changes made to the library by others, unless overruled by a formal vote (see below). Responsibilities of the library maintainer ------------------------------------------ - To respond to bug reports for their library in a timely manner. - To incorporate or reject patches contributed by others in a timely manner. - To evolve the library to keep up with changes to the C++ language or emerging best-practice (e.g. current example: supporting move semantics). Then the 'community representatives team' have the following additional rights and responsibilities: Rights of the community representatives ---------------------------------------- - To make _any_ changes to _any_ library. - To override the wishes of the library maintainer where there is a formal vote in favour of such action. Responsibilities of the community representatives ------------------------------------------------- - To apply patches contributed by the wider community in a timely manner once there is consensus that it should be applied. ========= Rationale ========= There is general agreement that the library acceptance review process, which puts community consensus above all else, has been key to Boosts quality and success. And yet, once that review is over, complete control is handed from the community to the maintainer, never to return. This proposal aims for a better balance where the work can be spread between more people, where the community can force progress if necessary, and which doesn't ignore the importance of a having a single 'champion' to guide the library's course of ordinary development. The intent is that the following activities are part of everyday Boost development: - Community reps fixing bugs in library they don't maintain, without asking permission from the maintainer. - Community reps applying patches contributes by community, without asking permission from the maintainer. - Maintainers fixing bugs. - Maintainers making significant changes to their own library. And the following activities should be possible by rare: - Maintainers rolling-back changes made by community reps and explaining the decision on this list. - Community reps making significant changes to a library that were requested by the community but whose maintainer was unwilling/unable to implement them. The key to this change is trust. Firstly trust in the community to make reasonable decisions by consensus (we already trust it to do this for acceptance reviews). Secondly, trust in the selected band of 'community representatives' to make sensible changes to the code - this trust has so far been missing from Boost. Comments welcome. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
AMDG On 12/05/2013 09:36 AM, Alexander Lamaison wrote:
======== Proposal ========
My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role:
<snip>
This wouldn't help anything. Every effort to create a group that does general maintenance in the past has fizzled out when most of the participants lose interest. If we can't even manage this for a few libraries that have no active maintainer at all, it's completely hopeless to try to establish it for even more libraries. In Christ, Steven Watanabe
Steven Watanabe <watanabesj@gmail.com> writes:
AMDG
On 12/05/2013 09:36 AM, Alexander Lamaison wrote:
======== Proposal ========
My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role:
<snip>
This wouldn't help anything. Every effort to create a group that does general maintenance in the past has fizzled out when most of the participants lose interest. If we can't even manage this for a few libraries that have no active maintainer at all, it's completely hopeless to try to establish it for even more libraries.
And yet other large open-source projects manage it no problem. Perhaps people are scared of getting the same reception that Stephen Kelly got. If we refine my proposal to make it a right, rather than a responsibility of the community to apply patches to any library then we avoid the workload issue you anticipate. Without that responsibility, increasing the number of libraries the community team are allowed to change doesn't increase their workload as they can change as little or as much as they want. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
On 5 Dec 2013 at 10:06, Steven Watanabe wrote:
My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role:
<snip>
This wouldn't help anything. Every effort to create a group that does general maintenance in the past has fizzled out when most of the participants lose interest. If we can't even manage this for a few libraries that have no active maintainer at all, it's completely hopeless to try to establish it for even more libraries.
Agreed. Boost isn't like other open source libraries because it sprawls so much, so I can't think of anyone who uses every single library in Boost and therefore has a substantial interest in looking at Boost as a whole rather than as a pick-and-mix. I've always personally thought the only way you'll get holistic work done on an ongoing basis is to appoint a paid civil service corp of engineers i.e. effectively a paid engineer or two who are appointed benevolent dictators. As no one appears to be forthcoming with the requisite funding, that is a pipedream. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 5 Dec 2013 at 10:06, Steven Watanabe wrote:
My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role:
<snip>
This wouldn't help anything. Every effort to create a group that does general maintenance in the past has fizzled out when most of the participants lose interest. If we can't even manage this for a few libraries that have no active maintainer at all, it's completely hopeless to try to establish it for even more libraries.
Agreed. Boost isn't like other open source libraries because it sprawls so much, so I can't think of anyone who uses every single library in Boost and therefore has a substantial interest in looking at Boost as a whole rather than as a pick-and-mix.
I've not explained myself well enough. What I'm proposing should not make community reps feel they have to contribute to multiple libraries. Just that they shouldn't be _prevented_ from contributing to libraries, whether that be the one library they have an intereste in, or more than one. At the moment, no-one but the named maintainer is allowed to commit to a the library, except with case-by-case permission from the release managers when a critical patch is urgently needed in the imminent release. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
Alexander Lamaison wrote:
At the moment, no-one but the named maintainer is allowed to commit to a the library, except with case-by-case permission from the release managers when a critical patch is urgently needed in the imminent release.
That wasn't true in the old SVN world. Everyone with SVN access was able to commit wherever he likes, and for trivial fixes, many did.
On 5 Dec 2013 at 19:17, Alexander Lamaison wrote:
I've not explained myself well enough. What I'm proposing should not make community reps feel they have to contribute to multiple libraries. Just that they shouldn't be _prevented_ from contributing to libraries, whether that be the one library they have an intereste in, or more than one.
At the moment, no-one but the named maintainer is allowed to commit to a the library, except with case-by-case permission from the release managers when a critical patch is urgently needed in the imminent release.
Even if everyone had commit access to everything, I think you'd find there are powerful social pressures to not fiddle with "other people's code" except in the most minor ways. Even substantial patches are highly likely to be silently ignored by most maintainers, partially due to NIH, partially due to lack of interest in merging and supporting other people's use cases, and partially because in the end it's all about spare time here, and people will naturally choose their todo list over other's. The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost. I do agree that the steering committee should have admin and commit access to all approved Boost libraries, and possibly all those in the peer review queue as well. To my knowledge this is already planned and/or already implemented, so we're as good as we're at. (FYI I very much like the idea of an active pruning strategy for Boost so undermaintained libraries get actively purged. Less is more!) Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Thu, Dec 5, 2013 at 5:49 PM, Niall Douglas <s_sourceforge@nedprod.com>wrote: I do agree that the steering committee should have admin and commit
access to all approved Boost libraries, and possibly all those in the peer review queue as well. To my knowledge this is already planned and/or already implemented, so we're as good as we're at.
The steering committee does not have any access, as they deal with policy rather than operations. I think you meant to say the Release Managers. They do have admit access to all boostorg repos.
(FYI I very much like the idea of an active pruning strategy for Boost so undermaintained libraries get actively purged. Less is more!)
There is no current policy to purge "undermaintained" libraries. Usefulness to users is the metric Boost has traditionally used in deciding to remove a library. A library typically becomes much less useful to users if it is replaced by a much better library or a core language feature, and then only after enough time has passed that the library really doesn't have users anymore. --Beman
On 5 Dec 2013 at 21:23, Beman Dawes wrote:
The steering committee does not have any access, as they deal with policy rather than operations. I think you meant to say the Release Managers. They do have admit access to all boostorg repos.
Apologies for the error.
(FYI I very much like the idea of an active pruning strategy for Boost so undermaintained libraries get actively purged. Less is more!)
There is no current policy to purge "undermaintained" libraries. Usefulness to users is the metric Boost has traditionally used in deciding to remove a library. A library typically becomes much less useful to users if it is replaced by a much better library or a core language feature, and then only after enough time has passed that the library really doesn't have users anymore.
Well I won't revisit my previously stated arguments on this list. Suffice it to say that I draw the deprecation and pruning line a lot closer to the present size of Boost than most others do - in particular, I want to see incentives created for improved funding of work on those parts of Boost which need TLC but those companies which depend on such parts would rather they get the code for free with no associated responsibilites. i.e., to be clear, I would suggest an aggressive pruning and deprecation policy as a method of giving people a business case to take to their managements which they would process as an End Of Life support issue. Whether in practice a library *actually* gets deleted from the approved list of Boost libraries is entirely another matter, but the threat needs to be credible. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 6 December 2013 11:52, Niall Douglas <s_sourceforge@nedprod.com> wrote:
i.e., to be clear, I would suggest an aggressive pruning and deprecation policy as a method of giving people a business case to take to their managements which they would process as an End Of Life support issue. Whether in practice a library *actually* gets deleted from the approved list of Boost libraries is entirely another matter, but the threat needs to be credible.
-1. We should never deliberately have an adversarial relationship with companies that use Boost. It would not end well, because they are unlikely to respond to threats in the way you would like them to. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 6 Dec 2013 at 16:56, Nevin Liber wrote:
i.e., to be clear, I would suggest an aggressive pruning and deprecation policy as a method of giving people a business case to take to their managements which they would process as an End Of Life support issue. Whether in practice a library *actually* gets deleted from the approved list of Boost libraries is entirely another matter, but the threat needs to be credible.
-1. We should never deliberately have an adversarial relationship with companies that use Boost. It would not end well, because they are unlikely to respond to threats in the way you would like them to.
Who said anything about being adversarial or threatening anyone? Software becomes obsolete unless upgraded. Companies understand this, you just need to tell them using the language management uses for funding COTS upgrade cycles. You publish a long term roadmap with upgrade and migration options for deprecated items, and you stick to it. One thing is definitely for sure: you can't keep growing a set of general purpose C++ libraries indefinitely. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Dec 5, 2013, at 5:49 PM, "Niall Douglas" <s_sourceforge@nedprod.com> wrote:
On 5 Dec 2013 at 19:17, Alexander Lamaison wrote:
I've not explained myself well enough. What I'm proposing should not make community reps feel they have to contribute to multiple libraries. Just that they shouldn't be _prevented_ from contributing to libraries, whether that be the one library they have an intereste in, or more than one.
Perhaps the issue is that those relatively new to Boost don't understand what happens, over the years, that seems normal to longtime members of the community. Documentation would solve that.
At the moment, no-one but the named maintainer is allowed to commit to a the library, except with case-by-case permission from the release managers when a critical patch is urgently needed in the imminent release.
This is one such misunderstanding. Others can, and do, make changes. However, they seek permission from the maintainer as a courtesy.
Even if everyone had commit access to everything, I think you'd find there are powerful social pressures to not fiddle with "other people's code" except in the most minor ways.
That's always the case and it serves to squelch overreaching change.
Even substantial patches are highly likely to be silently ignored by most maintainers, partially due to NIH, partially due to lack of interest in merging and supporting other people's use cases, and partially because in the end it's all about spare time here, and people will naturally choose their todo list over other's.
The superlative, "highly," mischaracterizes the attitude of most Boost maintainers.
The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost.
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix. ___ Rob (Sent from my portable computation engine)
On 6 Dec 2013 at 5:26, Rob Stewart wrote:
I've not explained myself well enough. What I'm proposing should not make community reps feel they have to contribute to multiple libraries. Just that they shouldn't be _prevented_ from contributing to libraries, whether that be the one library they have an intereste in, or more than one.
Perhaps the issue is that those relatively new to Boost don't understand what happens, over the years, that seems normal to longtime members of the community. Documentation would solve that.
Personally speaking I've been here since 2002 or so, but you didn't see me on this specific list till recently. I was busy with other, non compsci related efforts. I think the OP was referring to lack of universal commit access for the git config, not the preceding SVN config.
Even if everyone had commit access to everything, I think you'd find there are powerful social pressures to not fiddle with "other people's code" except in the most minor ways.
That's always the case and it serves to squelch overreaching change.
Except that isn't the case in other open source, as the OP also pointed out. Boost is an outlier on the primacy it places on individual maintainers and their control of "their" code. Don't get me wrong, it has huge benefits, but it also comes with penalties, mainly the lack of a holistic design and vision across all of Boost and what happens when a maintainer becomes unavailable.
Even substantial patches are highly likely to be silently ignored by most maintainers, partially due to NIH, partially due to lack of interest in merging and supporting other people's use cases, and partially because in the end it's all about spare time here, and people will naturally choose their todo list over other's.
The superlative, "highly," mischaracterizes the attitude of most Boost maintainers.
I think you also mischaracterise my use of "substantial".
The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost.
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix.
That's evolution of a component, not forking which would involve multiple libraries being taken in a new direction together. Forking is where a challenging group substantially disagrees with the controlling group enough to expend significant resources to prove themselves correct. Forking only succeeds when the challenging group acquires enough resources and is more correct than wrong in their basis for forking. For a challenging fork to supplant the original, it also requires the controlling group to lose legitimacy. Boost code is hard to fork mainly because it's particularly hard to write and maintain, but more importantly a direct challenge to the purpose and goals of Boost by a forking group would be seen as a personal attack by most here (including me, by the way). We would almost certainly unite to see off the challenger, and that's a huge barrier to entry. This all may seem quite abstract, but there have been more than one Boost competitors over the years which sought to "do Boost better" whether implicitly or explicitly (with some alternatives coming from multinational corporations). Some have had a reasonable success, but none to my knowledge has ever really come close to displacing Boost. In that sense what has worked has worked very well - till now. We can't easily say yet if the present maintainer-led system will scale out. I personally think - and I'll put on my hat as a Complex Systems researcher now - that the tipping point where it stops working well is not long far out, especially now modularisation has been implemented which will speed up the complexification of the Boost ecosystem substantially. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 6 December 2013 12:17, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 6 Dec 2013 at 5:26, Rob Stewart wrote:
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix.
Boost code is hard to fork mainly because it's particularly hard to write and maintain, but more importantly a direct challenge to the purpose and goals of Boost by a forking group would be seen as a personal attack by most here (including me, by the way).
This sounds like a non-problem to me. I understand why people fork languages or a particular library, but a complete set of libraries? The only fork I can possibly imagine is, say, making a C++11 or C++1y specific version as a baseline. We would
almost certainly unite to see off the challenger, and that's a huge barrier to entry.
Would we? I can't imagine something like that being successful unless the Boost development community was so divided that a significant fraction move over to the forked project while the others stick with Boost, and that community division would be the problem we need to deal with.
This all may seem quite abstract, but there have been more than one Boost competitors over the years which sought to "do Boost better" whether implicitly or explicitly (with some alternatives coming from multinational corporations).
*shrug* Unless you are mentioning actual examples, it is still just abstract and only in your opinion. What exactly is a Boost competitor? Someone else who wants to contribute libraries to the C++ community or the C++ standard? Good for them!
Some have had a reasonable success, but none to my knowledge has ever really come close to displacing Boost.
Seriously? Who out there wants to put Boost out of business? Without specifics, this is just FUD.
In that sense what has worked has worked very well - till now. We can't easily say yet if the present maintainer-led system will scale out.
No one can say what the future holds. More FUD.
I personally think - and I'll put on my hat as a Complex Systems researcher now - that the tipping point where it stops working well is not long far out, especially now modularisation has been implemented which will speed up the complexification of the Boost ecosystem substantially.
What does "not long far out" mean? A year? Ten years? Before C++ collapses under its own weight (another oft-said prediction)? Heat death of the sun? Again, without specifics, this is just FUD and a non-problem. IMHO, of course, -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 6 Dec 2013 at 16:29, Nevin Liber wrote:
We would
almost certainly unite to see off the challenger, and that's a huge barrier to entry.
Would we? I can't imagine something like that being successful unless the Boost development community was so divided that a significant fraction move over to the forked project while the others stick with Boost, and that community division would be the problem we need to deal with.
I would liken it to how C++ reacted to the D language. D has tons of great ideas, some very well executed and some not. It bought in a reasonable sympathy from many C++ programmers, and if C++ simply ignored D then D would have continued to grow, perhaps eventually becoming a viable substitute. C++ did not ignore D however, and there has been a clear reaction to D in recent C++ evolution. That is killing off D as a viable substitute. I'm saying the same pattern would likely happen to Boost if faced with a realistic potential substitute i.e. unite and see off the challenge. You might note how recent additions to Boost replicate features in other C++ libraries such as POGO etc.
This all may seem quite abstract, but there have been more than one Boost competitors over the years which sought to "do Boost better" whether implicitly or explicitly (with some alternatives coming from multinational corporations).
*shrug* Unless you are mentioning actual examples, it is still just abstract and only in your opinion.
I never claimed anything I said wasn't just my opinion. Examples won't be a perfect fit, so people will complain they aren't a perfect fit and therefore I'm hand waving which someone already did ... etc ...
What exactly is a Boost competitor? Someone else who wants to contribute libraries to the C++ community or the C++ standard? Good for them!
Some have had a reasonable success, but none to my knowledge has ever really come close to displacing Boost.
Seriously? Who out there wants to put Boost out of business? Without specifics, this is just FUD.
Who said anything about anyone wanting to put Boost out of business? It's usually about doing things *differently* according to some ideological or philosophical beliefs, not about killing whole projects off. People fork because they believe that "their way" is better for some given problem set. And why FUD? This list likes to accuse dissenting voices of FUD almost automatically. To FUD implies having a motive. What do you think my motive is here? What do I gain by writing any of this, except sacrificing time better spent elsewhere?
In that sense what has worked has worked very well - till now. We can't easily say yet if the present maintainer-led system will scale out.
No one can say what the future holds. More FUD.
I personally think - and I'll put on my hat as a Complex Systems researcher now - that the tipping point where it stops working well is not long far out, especially now modularisation has been implemented which will speed up the complexification of the Boost ecosystem substantially.
What does "not long far out" mean? A year? Ten years? Before C++ collapses under its own weight (another oft-said prediction)? Heat death of the sun? Again, without specifics, this is just FUD and a non-problem.
If it's approved for presentation, I think you'll just *love* my C++ Now 2014 presentation and associated ten page academic paper. It's exclusively about future non-problems and FUD in C++. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Dec 6, 2013, at 1:17 PM, "Niall Douglas" <s_sourceforge@nedprod.com> wrote:
On 6 Dec 2013 at 5:26, Rob Stewart wrote:
Even substantial patches are highly likely to be silently ignored by most maintainers, partially due to NIH, partially due to lack of interest in merging and supporting other people's use cases, and partially because in the end it's all about spare time here, and people will naturally choose their todo list over other's.
The superlative, "highly," mischaracterizes the attitude of most Boost maintainers.
I think you also mischaracterise my use of "substantial".
Perhaps, but you haven't improved my understanding. So far, this seems like a lot of handwaving. I don't mean to suggest that you don't truly think the problem exists generally, but I haven't seen a pattern.
The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost.
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix.
That's evolution of a component, not forking which would involve multiple libraries being taken in a new direction together.
You previously used the phrase, "those interested enough fork a library", but when I challenge your point, you decide that forking requires many libraries taken elsewhere? ___ Rob (Sent from my portable computation engine)
On 6 Dec 2013 at 21:05, Rob Stewart wrote:
Perhaps, but you haven't improved my understanding. So far, this seems like a lot of handwaving. I don't mean to suggest that you don't truly think the problem exists generally, but I haven't seen a pattern.
I stated some opinions of mine without any supporting facts. So yes, hand waving. It might be useful to others or not.
The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost.
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix.
That's evolution of a component, not forking which would involve multiple libraries being taken in a new direction together.
You previously used the phrase, "those interested enough fork a library", but when I challenge your point, you decide that forking requires many libraries taken elsewhere?
I'll copy and paste from http://en.wikipedia.org/wiki/Fork_(software_development): "The term often implies not merely a development branch, but a split in the developer community, a form of schism" Forking isn't usually about software, it's about differences in the philosophy behind the software. For example, in the "Why POCO" description: "Yet, even ACE or Boost, although top-quality well-designed code, could not completely make me happy and convince me to fully commit. Somehow, something did not feel right. Enter Poco. It was one of those things you find and immediately know that´s it - you´ll be able to really use it, and use it with joy and enthusiasm. It was C++. It was well thought-out, well designed and really neat and tidy." So while POCO and Boost don't share code and therefore are not forks of /software/, they do share similar goals and purposes as general purpose platform abstraction libraries and POCO's authors thought that they could do better than ACE or Boost for their particular problem set. In POCO's case, they explicitly felt that POCO would be well thought out, well designed and really neat and tidy, and usable with joy and enthusiasm which implies that ACE and Boost as a whole is not those things in their opinion. Does this improve your understanding? Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Dec 7, 2013, at 2:59 PM, "Niall Douglas" <s_sourceforge@nedprod.com> wrote:
On 6 Dec 2013 at 21:05, Rob Stewart wrote:
The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost.
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix.
That's evolution of a component, not forking which would involve multiple libraries being taken in a new direction together.
You previously used the phrase, "those interested enough fork a library", but when I challenge your point, you decide that forking requires many libraries taken elsewhere?
I'll copy and paste from http://en.wikipedia.org/wiki/Fork_(software_development):
"The term often implies not merely a development branch, but a split in the developer community, a form of schism"
That fits my example just fine. A second person thought Signals would be better if modified. The original maintainer didn't want to change it. Thus, a fork of Signals was created and we now have Signals2 alongside (the now-deprecated, IIRC) Signals.
Forking isn't usually about software, it's about differences in the philosophy behind the software.
Yep [snip]
Does this improve your understanding?
Thanks for all of that, but my "understanding" comment was WRT your "significant patches" commentary. (It's probably not productive to revisit that anyway.) ___ Rob (Sent from my portable computation engine)
On 12/5/2013 2:03 PM, Niall Douglas wrote:
On 5 Dec 2013 at 10:06, Steven Watanabe wrote:
My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role:
<snip>
This wouldn't help anything. Every effort to create a group that does general maintenance in the past has fizzled out when most of the participants lose interest. If we can't even manage this for a few libraries that have no active maintainer at all, it's completely hopeless to try to establish it for even more libraries.
Agreed. Boost isn't like other open source libraries because it sprawls so much, so I can't think of anyone who uses every single library in Boost and therefore has a substantial interest in looking at Boost as a whole rather than as a pick-and-mix.
Boost consists of 120+ libraries. Some are interconnected, and many depend on a few core libraries, in particular MPL, but with that many different libraries it is really hard to think of Boost as a single open source "library".
I've always personally thought the only way you'll get holistic work done on an ongoing basis is to appoint a paid civil service corp of engineers i.e. effectively a paid engineer or two who are appointed benevolent dictators. As no one appears to be forthcoming with the requisite funding, that is a pipedream.
Or you can get good work done when a single person or small group of people pay attention to a particular library. Boost is way too big to worry about a group of people paying attention to 120+ different libraries. I think trusted people can be given access to key, core libraries of Boost as maintainers but it is foolish to think that any one person can absorb or pay detailed attention to more than a small subset of what is currently 120+ separate libraries and likely to grow to more.
On Thursday 05 December 2013 10:06:55 Steven Watanabe wrote:
AMDG
On 12/05/2013 09:36 AM, Alexander Lamaison wrote:
======== Proposal ========
My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role:
<snip>
This wouldn't help anything. Every effort to create a group that does general maintenance in the past has fizzled out when most of the participants lose interest. If we can't even manage this for a few libraries that have no active maintainer at all, it's completely hopeless to try to establish it for even more libraries.
While I can see why this idea may fail because of lack of interest, I sympathize Alexander's point that the community should play larger role in libraries development. There are examples when blanket changes needed to be applied to multiple libraries, like macro updates Stephen Kelly did. There are cases when trivial fixes needed to be made in someone else's library. Surely github adds pull requests to the available options, but pull requests still have to be processed by a single or a few maintainers, which become a bottleneck and a single authority about the library. I think Alexander is making a good point that the membership in the Community group should represent the right to apply changes and not an obligation to do active maintenance of every library in Boost. Such an obligation is unrealistic to fulfill, indeed. But for one, I'd like to be able to make changes to the libraries I don't develop or maintain. There is a slippery edge in this idea though. While I'd welcome people making fixes and relatively small improvements to the libraries I maintain, I'd feel unease if design decisions were made without my consent. It's not about the lack of trust for the community, but rather because such decisions could interfere with my vision of the library utility and future development. Of course, it is difficult to define which changes are small and which are considered architectural, and my vision of the library is obviously subjective. This makes a lot of grey area. Voting doesn't look like a viable solution, since there may be a simple lack of quorum. Remember that we have problems with the amount of reviews for libraries, and there's no reason to believe it'll be different with voting. I think there has to be an upper hand in controversial and design-defining cases, and right now I don't see a better candidate than the library maintainer. After all, he has arguably the best knowledge of the library.
Andrey Semashev <andrey.semashev@gmail.com> writes:
On Thursday 05 December 2013 10:06:55 Steven Watanabe wrote:
AMDG
On 12/05/2013 09:36 AM, Alexander Lamaison wrote:
======== Proposal ========
My proposal goes further than Beman's and gives "Community maintainership" to all but the most well-maintained libraries. Each library would still have a named maintainer and this would be their role:
<snip>
This wouldn't help anything. Every effort to create a group that does general maintenance in the past has fizzled out when most of the participants lose interest. If we can't even manage this for a few libraries that have no active maintainer at all, it's completely hopeless to try to establish it for even more libraries.
While I can see why this idea may fail because of lack of interest, I sympathize Alexander's point that the community should play larger role in libraries development. There are examples when blanket changes needed to be applied to multiple libraries, like macro updates Stephen Kelly did. There are cases when trivial fixes needed to be made in someone else's library. Surely github adds pull requests to the available options, but pull requests still have to be processed by a single or a few maintainers, which become a bottleneck and a single authority about the library.
I think Alexander is making a good point that the membership in the Community group should represent the right to apply changes and not an obligation to do active maintenance of every library in Boost. Such an obligation is unrealistic to fulfill, indeed. But for one, I'd like to be able to make changes to the libraries I don't develop or maintain.
There is a slippery edge in this idea though. While I'd welcome people making fixes and relatively small improvements to the libraries I maintain, I'd feel unease if design decisions were made without my consent.
I anticipate this only happening in two rare situations, one extremely rare. The more common case would be where a maintainer is uncontactable or unable to devote enough time to make the changes. The second, rare case would be where, after exhaustive debate on the list, the community is overwhelmingly in favour of a direction for the library but the maintainer simply refuses. It's hard to see any reason why the maintainer should be able to veto the whole community for all time.
It's not about the lack of trust for the community, but rather because such decisions could interfere with my vision of the library utility and future development.
Exactly. That's why the maintainer should remain in charge of the overall direction of the library. It's just that there should be a way to overrule them if it's clear to everyone but themselves that they are misguided. In a small project, the community would simply fork it, change its name, and get on with the changes. But with Boost that is plainly impractical. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
AMDG On 12/05/2013 12:59 PM, Alexander Lamaison wrote:
Andrey Semashev <andrey.semashev@gmail.com> writes:
I think Alexander is making a good point that the membership in the Community group should represent the right to apply changes and not an obligation to do active maintenance of every library in Boost. Such an obligation is unrealistic to fulfill, indeed. But for one, I'd like to be able to make changes to the libraries I don't develop or maintain.
There is a slippery edge in this idea though. While I'd welcome people making fixes and relatively small improvements to the libraries I maintain, I'd feel unease if design decisions were made without my consent.
I anticipate this only happening in two rare situations, one extremely rare. The more common case would be where a maintainer is uncontactable or unable to devote enough time to make the changes.
This has never been a real problem in the past for minor changes, provided that someone with commit access is motivated enough to: - Understand the library well enough to avoid accidentally breaking something - Write the fix - Write test cases for the fix - Take responsibility for any problems that appear - etc. The administrative overhead of asking for permission on the list is relatively minor. (My usual policy is Email 1: Okay to commit? Email 2: It's going in, unless someone objects immediately.) For major changes, there will be problems, so if the maintainer is missing, then whoever is doing the work needs to be willing to step up as the new maintainer.
The second, rare case would be where, after exhaustive debate on the list, the community is overwhelmingly in favour of a direction for the library but the maintainer simply refuses. It's hard to see any reason why the maintainer should be able to veto the whole community for all time.
I don't see any point in discussing this. I don't expect this situation to come up, ever. Not to mention that in such a situation, it's quite possible that the maintainer is right anyway, since he presumably knows the library better than anyone else. In Christ, Steven Watanabe
Steven Watanabe <watanabesj@gmail.com> writes:
AMDG
On 12/05/2013 12:59 PM, Alexander Lamaison wrote:
Andrey Semashev <andrey.semashev@gmail.com> writes:
I think Alexander is making a good point that the membership in the Community group should represent the right to apply changes and not an obligation to do active maintenance of every library in Boost. Such an obligation is unrealistic to fulfill, indeed. But for one, I'd like to be able to make changes to the libraries I don't develop or maintain.
There is a slippery edge in this idea though. While I'd welcome people making fixes and relatively small improvements to the libraries I maintain, I'd feel unease if design decisions were made without my consent.
I anticipate this only happening in two rare situations, one extremely rare. The more common case would be where a maintainer is uncontactable or unable to devote enough time to make the changes.
This has never been a real problem in the past for minor changes, provided that someone with commit access is motivated enough to: - Understand the library well enough to avoid accidentally breaking something - Write the fix - Write test cases for the fix - Take responsibility for any problems that appear - etc.
The administrative overhead of asking for permission on the list is relatively minor. (My usual policy is Email 1: Okay to commit? Email 2: It's going in, unless someone objects immediately.)
If that's the case, I don't think people realise that's a recognised route to contribute. When it happens it always seems like an emergency measure.
For major changes, there will be problems, so if the maintainer is missing, then whoever is doing the work needs to be willing to step up as the new maintainer.
Why? It rules out all but the most dedicated contributors making significant improvements. Sure, the code needs maintaining, but why this insistence that that only one person at a time can do that?
The second, rare case would be where, after exhaustive debate on the list, the community is overwhelmingly in favour of a direction for the library but the maintainer simply refuses. It's hard to see any reason why the maintainer should be able to veto the whole community for all time.
I don't see any point in discussing this. I don't expect this situation to come up, ever.
Agreed. It's not an important reason for making these changes. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
Daniel James <daniel@calamity.org.uk> writes:
On 5 December 2013 22:09, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
If that's the case, I don't think people realise that's a recognised route to contribute. When it happens it always seems like an emergency measure.
Do you notice when it goes well?
That depends what you mean. It happens rarely so it's not clear if it's going well or not. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
On 5 December 2013 22:47, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
Daniel James <daniel@calamity.org.uk> writes:
On 5 December 2013 22:09, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
If that's the case, I don't think people realise that's a recognised route to contribute. When it happens it always seems like an emergency measure.
Do you notice when it goes well?
That depends what you mean. It happens rarely so it's not clear if it's going well or not.
The point is the when things go well you don't notice. Since you mentioned Stephen Kelly as an example of when things go wrong; I checked in some of his changes, dealt with the release notes, replied to people who were worried about them etc. You noticed what went wrong, but you didn't notice what went well. Btw. the reason I'm a release manager is because I was already making changes to other people's libraries, not the other way round. I do it less nowadays because I'm busy with the other boost things I do.
Daniel James <daniel@calamity.org.uk> writes:
On 5 December 2013 22:47, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
Daniel James <daniel@calamity.org.uk> writes:
On 5 December 2013 22:09, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
If that's the case, I don't think people realise that's a recognised route to contribute. When it happens it always seems like an emergency measure.
Do you notice when it goes well?
That depends what you mean. It happens rarely so it's not clear if it's going well or not.
The point is the when things go well you don't notice. Since you mentioned Stephen Kelly as an example of when things go wrong; I checked in some of his changes, dealt with the release notes, replied to people who were worried about them etc. You noticed what went wrong, but you didn't notice what went well.
If that's the case then I must be missing those discussions. Where is that occurring? Not on this list, presumably. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
On Thu, Dec 5, 2013 at 8:20 PM, Alexander Lamaison <awl03@doc.ic.ac.uk>wrote:
Daniel James <daniel@calamity.org.uk> writes:
On 5 December 2013 22:47, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
Daniel James <daniel@calamity.org.uk> writes:
On 5 December 2013 22:09, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
If that's the case, I don't think people realise that's a recognised route to contribute. When it happens it always seems like an
emergency
measure.
Do you notice when it goes well?
That depends what you mean. It happens rarely so it's not clear if it's going well or not.
The point is the when things go well you don't notice. Since you mentioned Stephen Kelly as an example of when things go wrong; I checked in some of his changes, dealt with the release notes, replied to people who were worried about them etc. You noticed what went wrong, but you didn't notice what went well.
If that's the case then I must be missing those discussions. Where is that occurring? Not on this list, presumably.
Some of the OK to commit? messages I get for my libraries are private, but I wouldn't want to guess what percent. --Beman
AMDG On 12/05/2013 02:09 PM, Alexander Lamaison wrote:
Steven Watanabe <watanabesj@gmail.com> writes:
For major changes, there will be problems, so if the maintainer is missing, then whoever is doing the work needs to be willing to step up as the new maintainer.
Why? It rules out all but the most dedicated contributors making significant improvements.
Without this kind of dedication, any major changes will likely cause more problems than they solve.
Sure, the code needs maintaining, but why this insistence that that only one person at a time can do that?
I think there's a misunderstanding somewhere. I don't have any problem with multiple people maintaining a library. Several libraries do, in fact, have more than one maintainer. In Christ, Steven Watanabe
On Dec 5, 2013, at 4:39 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
On 12/05/2013 12:59 PM, Alexander Lamaison wrote:
Andrey Semashev <andrey.semashev@gmail.com> writes:
I think Alexander is making a good point that the membership in the Community group should represent the right to apply changes and not an obligation to do active maintenance of every library in Boost. Such an obligation is unrealistic to fulfill, indeed. But for one, I'd like to be able to make changes to the libraries I don't develop or maintain.
There is a slippery edge in this idea though. While I'd welcome people making fixes and relatively small improvements to the libraries I maintain, I'd feel unease if design decisions were made without my consent.
I anticipate this only happening in two rare situations, one extremely rare. The more common case would be where a maintainer is uncontactable or unable to devote enough time to make the changes. [snip] The second, rare case would be where, after exhaustive debate on the list, the community is overwhelmingly in favour of a direction for the library but the maintainer simply refuses. It's hard to see any reason why the maintainer should be able to veto the whole community for all time.
I don't see any point in discussing this. I don't expect this situation to come up, ever. Not to mention that in such a situation, it's quite possible that the maintainer is right anyway, since he presumably knows the library better than anyone else.
More importantly, if the community imposes its will on the maintainer, how likely is that maintainer to support the library thereafter? A more likely course is for those inclined toward a major change unacceptable to the maintainer, is to create and submit a new library. If the library is accepted, and the old falls out of favor, then the old will become a candidate for pruning at some point. ___ Rob (Sent from my portable computation engine)
On Thu, Dec 5, 2013 at 12:36 PM, Alexander Lamaison <awl03@doc.ic.ac.uk>wrote: Extensive discussion of =====================================
The role of Boost library maintainers =====================================
and
================= Maintainer status =================
and
======== Proposal ========
and
========= Rationale =========
What you are proposing is much more extensive and all encompassing than anything I had in mind. While many of your points are well taken, I see the vast diversity of the Boost libraries and their maintainers as a great strength, and to me that demands diversity in how we handle maintenance. Furthermore, we are convulsed at the moment with one major transition, so I personally don't think it is the right time to totally rework how we do maintenance. The Community maintained libraries would start out as a very small piece of Boost. It would affect only a few boosters, and those that were affected would mostly be different from the set of release managers and library maintainers who are tied up in the move to git and modular boost. We can try it out to see if it works before speculating as to what portion of Boost libraries might eventually end up community maintained. In the meantime, you could approach the steering committee to see if they have any interest in more sweeping changes. Thanks for your interest, --Beman
Beman Dawes <bdawes@acm.org> writes:
On Thu, Dec 5, 2013 at 12:36 PM, Alexander Lamaison <awl03@doc.ic.ac.uk>wrote:
Extensive discussion of
=====================================
The role of Boost library maintainers =====================================
What you are proposing is much more extensive and all encompassing than anything I had in mind.
...snip
The Community maintained libraries would start out as a very small piece of Boost. It would affect only a few boosters, and those that were affected would mostly be different from the set of release managers and library maintainers who are tied up in the move to git and modular boost. We can try it out to see if it works before speculating as to what portion of Boost libraries might eventually end up community maintained.
I'd be happy see your proposal implemented. I just wanted to put mine out there to get people thinking about what else might be possible. Anything is better than the status quo. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
On Wed, Dec 4, 2013 at 7:47 AM, Beman Dawes <bdawes@acm.org> wrote:
Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers.
Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global.
GitHub gives us some additional tools; write permissions are given at the Team level, and a team can have permissions across multiple specific repositories.
Strawman Proposal -------------------------
For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership.
We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance.
Comments?
Now, a comment from the dark-side of software development... Caveat: I'm new to the Boost development culture and open source development, in general, so take the below with a grain of salt. I'm playing a little devil's advocate, here, since no one mentioned this alternative... Every development team has limited resources and has to triage their work. In this case, I'm talking triage in the most severe sense: not just what order to do something, but if it should be done at all. Some libraries may have to be dropped from Boost due to lack of user interest or unlikeliness of ever being accepted into the C++ standard. Dead wood has to be cut from the tree so the rest of the tree can thrive. In the open source world is very market-driven. The strong (useful/popular) survive, the weak (limited usefulness/popularity) perish. For example, in GCC if a machine architecture loses it's maintainer, the architecture is deprecated and then dropped in a future release. What's Boost's deprecation policies? Doing a search for "library deprecation deprecate" of the boost.org web-site, the only thing I could find was Guidelines/MaintenanceGuidelines – Boost C++ Libraries<https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines> which really doesn't have the tone of a policy or address deprecation of entire libraries. Also, the search revealed only one library (Compose) that has been deprecated. Is this the only one? Maybe it's time Boost needs to get into a pruning mode and remove any deadwood? Some comments and open questions in regards to the membership of the Community team concept for a maintainer-less library (MLL) and how it operates: - Users of an MLL can be categorized into two groups: external users and Boost library maintainers whose library is dependent on that MLL. Yes, whether you like it or not, all library maintainers of a library that is dependent on an MLL is, in reality, a member of the Community team for that library. - Maybe there needs to be multiple Community teams, one for each MLL? The size of an MLL's Community team will be a good indicator of the library's usefulness. At least it would provide a candidate list for possible library maintainers. - With the above understanding, the library maintainers have a choice of maintaining the dependent MLL or removing their dependence on that MLL. With this choice, either the dependent MLL will be maintained by the group of users of the MLL or the library will become irrelevant. If a MLL is not being used, it should be removed from Boost. - In modularized boost, removing a library that is no longer being used is as easy as removing it from the .gitmodules file and prepending a note to the README.md file stating such. The MLL's repository can remain in boostorg and added back if a maintainer can be found. This puts pressure on the external users to maintain the libraries they use. - If a majority of the Community team members feel the maintenance of the MLL is too burdensome, the library can be deprecated and will be removed in the next release. Variations of this could be to - Limit this decision to just the boost library maintainers (since they will probably bear most of the burden). - Something more or less than a majority of the Community team. - More than a one release deprecation period (or don't commit to a specific release so that any future release could be a candidate for removal). - The value of a Community team member's vote should be proportional to the amount of work they've contributed to the maintenance of the MLL. Yes, I know this is hard to quantify. Michael
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Date: Wed, 4 Dec 2013 09:47:52 -0500 From: bdawes@acm.org To: boost@lists.boost.org Subject: [boost] RFC: Community maintained libraries
Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers.
Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global.
GitHub gives us some additional tools; write permissions are given at the Team level, and a team can have permissions across multiple specific repositories.
Strawman Proposal -------------------------
For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership.
We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance.
Comments?
I support this idea. I think the biggest issue with boost getting people involved is perception, as the rest of this thread seems to attest to and having an official policy like this would definitely be a step toward changing that perception.
On Tue, Dec 10, 2013 at 5:28 AM, Ahmed Charles <acharles@outlook.com> wrote:
Date: Wed, 4 Dec 2013 09:47:52 -0500 From: bdawes@acm.org To: boost@lists.boost.org Subject: [boost] RFC: Community maintained libraries
Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers.
Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global.
GitHub gives us some additional tools; write permissions are given at the Team level, and a team can have permissions across multiple specific repositories.
Strawman Proposal -------------------------
For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership.
We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance.
Comments?
I support this idea. I think the biggest issue with boost getting people involved is perception, as the rest of this thread seems to attest to and having an official policy like this would definitely be a step toward changing that perception.
I've now made a formal proposal to the steering committee, incorporating ideas from this discussion. Thanks to everyone who participated! --Beman
participants (14)
-
Ahmed Charles -
Alexander Lamaison -
Andrey Semashev -
Beman Dawes -
Cox, Michael -
Daniel James -
Edward Diener -
Klaim - Joël Lamotte -
Mateusz Loskot -
Nevin Liber -
Niall Douglas -
Peter Dimov -
Rob Stewart -
Steven Watanabe