On Wed, Dec 4, 2013 at 8:11 PM, Mateusz Loskot 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?

Steven Watanabe 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)

"Niall Douglas" 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)

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 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 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 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 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 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 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.

Andrey Semashev 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)

Steven Watanabe writes:

AMDG

On 12/05/2013 12:59 PM, Alexander Lamaison wrote:

...

Andrey Semashev 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 writes:

On 5 December 2013 22:09, Alexander Lamaison 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 wrote:

Daniel James writes:

...

On 5 December 2013 22:09, Alexander Lamaison 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.

On Thu, Dec 5, 2013 at 8:20 PM, Alexander Lamaison wrote:

Daniel James writes:

...

On 5 December 2013 22:47, Alexander Lamaison wrote:

...

Daniel James writes:

...

On 5 December 2013 22:09, Alexander Lamaison 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

On Dec 5, 2013, at 4:39 PM, Steven Watanabe wrote:

On 12/05/2013 12:59 PM, Alexander Lamaison wrote:

...

Andrey Semashev 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)

Beman Dawes writes:

On Thu, Dec 5, 2013 at 12:36 PM, Alexander Lamaison 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)