Boost.Experimental Re: [variant] Maintainer
On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com> wrote:
On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote:
Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit :
On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote:
I would accept Eggs.Variant without even a review (or with a minimal review) as an experimental library as part of Boost.Variant after some minimal adaptation to fit in Boost of course.
First of, as I have already said before, Eggs.Variant is an experiment. As such it is highly unstable, and I reserve the right to change things in any way I see fit, with no regards for backwards compatibility, maintenance, or support. I have made these kinds of changes in the past, and I have more planned for the near future. I think it would be unwise to make it a part of Boost, even as an experimental library, until the design has fully hatched ("Eggs", get it?).
Agustin, this is exactly the kind of constraints of an experimental library. When the design is fully hatched then it moves to non experimental.
I fail to see the point in including an experimental library that changes its interface every month into Boost, which is released every 3 months or so. By the time you get your hands in a release, the interface of the library has already changed. And the library as such would only exist for a single release.
Who would benefit from Boost packaging old snapshots of experimental libraries?
Perhaps you'd wish to bring back the Sandbox (http://www.boost.org/community/sandbox.html), which has been superseded by standalone repositories since the move to Git.
I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something. There are (at least) 2 needs that Boost tackles: 1. great libraries that solve problems for developers 2. great libraries that can turn into std:: libraries I think we are doing better on 1 than 2. I think 2 requires more experimentation (whereas 1 requires more stability). Yes I know 2 looks successful - just look at how much of boost is in C++11. But when each Boost library is brought to the committee, we have 2 choices: - make design changes before going into std - take as is Making design choices in a committee (and without experimenting) is not always a good idea. We are, in theory at least, suppose to standardize existing behaviour. Taking as is means we are accepting whatever was good enough to pass Boost review as *best*. Boost review is a high bar, but the std:: should be higher. It is common for the committee to hear/say "boost users have been using it this way for years". That is usually a good strong argument - we want/need implementation and usage experience. But saying "this works" doesn't mean something else could work better. Implementation/usage experience is most accurate when it says "this does NOT work", because then you have ruled out an option. When you say "this works", it doesn't rule out options that might work _better_. We are increasingly going with option 3: - put into std::experimental which delays the desired outcome of getting great libraries into the standard. I'd like some kind of experimental area that would help find the best possible libraries. What I'd _really_ like is more experimentation in _current_ Boost libraries, breaking users left and right - I'd rather break boost users than std:: users. (We have and will make breaking changes in the standard library). But I understand that current users wouldn't be too happy about breaking changes _just for experimentation's sake_. And if we lost the boost user base, boost would no longer be helpful to the standard at all. (As a reasonable example of not being afraid of breaking changes: Sean Parent's Adobe Standard Library would boldly break whenever he thought something could be made better. It didn't break just for experimenting, but he wasn't afraid to make breaking changes for the better.)
On 7/2/15 7:44 AM, Gottlob Frege wrote:
On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com> wrote:
Perhaps you'd wish to bring back the Sandbox (http://www.boost.org/community/sandbox.html), which has been superseded by standalone repositories since the move to Git.
I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something.
I'd like some kind of experimental area that would help find the best possible libraries.
Why isn't the boost library incubator considered ideal here? In combination with github it already provides everything necessary - and significantly more already. And it's ridiculously easy to use.
What I'd _really_ like is more experimentation in _current_ Boost libraries, breaking users left and right
This is extremely simple - just fork the library you want to experiment with and create a new page in the incubator names - Serialization - Experimental and you're in business. Another possibility would be for the library maintainer to create a new branch in the Git repo named "experimental" or "constexpr_version" or whatever and encourage people to use that. Again, for a way to find this, just create a new page in the incubator. The main problem with "experimental" libraries is that authors of such libraries submit packages which are not really ready for users to experiment with. They are just (half-baked) ideas. So my take on this is: a) we already have everything we need implemented. There is no lack of opportunity to create/maintain and promote experimental libraries. b) there is no value in complicating boost organization and infrastructure to re-do what we already have. In fact, we should continue to exploit our new modularization scheme to reduce our workload so we can concentrate more on increasing quality through better reviews. The real obstacle to creating more libraries and more experimental variations of boost libraries is that it's a lot of work to do and very few people have the motivation, experience, skills, and/or free time to actually make something which looks like a boost quality library. Our clunky tools certainly don't help either. Robert Ramey
On Thu, Jul 2, 2015 at 10:33 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 7/2/15 7:44 AM, Gottlob Frege wrote:
On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com> wrote:
Perhaps you'd wish to bring back the Sandbox
(http://www.boost.org/community/sandbox.html), which has been superseded by standalone repositories since the move to Git.
I think we need *something* for experimental libraries. Even if it is
just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something.
I'd like some kind of experimental area that would help find the best
possible libraries.
Why isn't the boost library incubator considered ideal here? In combination with github it already provides everything necessary - and significantly more already. And it's ridiculously easy to use.
I second that sentiment. (i.e. +1) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Thu, Jul 2, 2015 at 11:33 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 7/2/15 7:44 AM, Gottlob Frege wrote:
On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com> wrote:
Perhaps you'd wish to bring back the Sandbox (http://www.boost.org/community/sandbox.html), which has been superseded by standalone repositories since the move to Git.
I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something.
I'd like some kind of experimental area that would help find the best possible libraries.
Why isn't the boost library incubator considered ideal here? In combination with github it already provides everything necessary - and significantly more already. And it's ridiculously easy to use.
Yes, of course; sorry. I wanted to mention blincubator in here somewhere. Maybe that is the right answer; I don't know enough to know. I think the other problem, or the real problem, that none of this solves, is getting wide adoption of experimental features. A constexpr branch is something bleeding edge users might use, and can maybe be done without much breakage - it is hopefully mostly addition. Changing something like boost::optional to have conversion to tribool instead of bool, or removing operator*() and forcing users to use get(), etc. Those are big breaks. I have no idea how to get users to actually be guinea pigs for those experiments. Should we have 3 different optionals to choose from? (Should we randomly select which optional you get in your boost distribution so as to get good A/B testing :-)
On 7/2/15 10:47 AM, Gottlob Frege wrote:
I think the other problem, or the real problem, that none of this solves, is getting wide adoption of experimental features.
I don't think that's a huge problem. The problem is that most "experimental" libraries aren't really useable. Of course the authors would disagree, but they are really wrong. If I want to experiment with something, I have to know within about an hour what it does, how it works, and why it's worth doing. I have to be able to build it if necessary, and try it out on my system and in my project - which motivates me to find it in the first place. I scour the net looking for libraries which I ask the authors to add to the incubator. probable 99/100 or 999/1000 don't meet the above minimal criteria. I do keep statistics on hits/visits to each library in the incubator. I haven't been able to gather downloads. I do have contact information on those who've downloaded the library, but haven't an implemented a way to follow up and ask for feedback. I'd love to be able to get this implemented to promote experimental libraries and get feedback on them.
A constexpr branch is something bleeding edge users might use, and can maybe be done without much breakage - it is hopefully mostly addition.
My recent experience with this leads me to believe a) this would be a huge benefit for some libraries b) that (surprize!) actually making this conversion would be more effort than it would first apear.
Changing something like boost::optional to have conversion to tribool instead of bool, or removing operator*() and forcing users to use get(), etc. Those are big breaks.
This would really be a new library - optional2. But someone could start with a fork of current optional, update it, and add the new "experimental" version to the incubator. These days its really easy to do. Much easier than it was during the "sandbox" days. In general, I think that Boost is behind the curve in the usage of modern technology to promote its mission. I have no idea how to get users to actually be guinea pigs for those experiments. LOL - if you give them something worth experimenting with, they'll appear. If they don't appear, then there's probably no need for it. Still, we need better visibility and promotion for Boost (website, sponsorship/volunteers at CPPCon, outreach at other conferences, e.g. Embedded system conference, More experimental libraries presented at CPPCon, etc). Robert Ramey
On 2 Jul 2015 at 13:47, Gottlob Frege wrote:
Changing something like boost::optional to have conversion to tribool instead of bool, or removing operator*() and forcing users to use get(), etc. Those are big breaks.
I'm getting the sense that the biggest head wreck for people here is the idea that optional and future are the same thing. As in, literally the same implementation code with the same API.
I have no idea how to get users to actually be guinea pigs for those experiments. Should we have 3 different optionals to choose from? (Should we randomly select which optional you get in your boost distribution so as to get good A/B testing :-)
I've tried to not deviate from source compatibility unless there was a good reason. Either from optional, or expected. My hope is that with a bit of template aliasing the implementations could be swapped. Regarding your comments that WG21 is a lousy place to design libraries, I agree in the strongest possible terms. Boost once was the place to playpen exciting new C++ libraries - if you read this mailing list back in 1999-2001, there was a palpable excitement here as people tried new things and showed one other what could be possible. Rather like in the Rust mailing list nowadays.
From 2008-2009 onwards things haven't been as good here, and especially since Dave left. It doesn't help when members of the steering committee conspicuously fail to perform their duties, and specifically disavow taking any leadership position except to intentionally prevent and inhibit change.
I strongly support your earlier comments Tony, and your rationale, and it's long overdue for an Boost.Experimental library distro. If Boost can't and won't do it, someone else should. (For the record, it won't be me, I'm likely going to be unemployed next week and my plate this year is too full. But I'll support anyone who does best I can). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On July 2, 2015 10:16:57 PM EDT, Niall Douglas <s_sourceforge@nedprod.com> wrote:
Boost once was the place to playpen exciting new C++ libraries - if you read this mailing list back in 1999-2001, there was a palpable excitement here as people tried new things and showed one other what could be possible. Rather like in the Rust mailing list nowadays.
From 2008-2009 onwards things haven't been as good here, and especially since Dave left.
You've made this sort of remark before. Dave didn't do anything particularly special except to be highly active and contribute a great deal. (Yes, he provided leadership, but he wasn't alone and others who did so are still part of the community.)
It doesn't help when members of the steering committee conspicuously fail to perform their duties, and specifically disavow taking any leadership position except to intentionally prevent and inhibit change.
I have no idea to what you're referring, but I highly doubt that this is a fair characterization of any member of the committee and certainly not of the committee itself. The Steering Committee, admittedly not ideally named, was formed for two key purposes: to be able to commit Boost money, when required, and to make a decision for the community when there isn't a clear consensus, not unlike how a Review Manager considers reviews for a decision but doesn't just count the votes. Any perceived reticence to make a decision on something may be due to unseen activity or to the misapprehension of what the committee should do. If you have specific concerns, don't malign the committee in this fashion on the developer's list but raise them on the committee list. Others can follow that list, so the discussion won't be hidden. ___ Rob (Sent from my portable computation engine)
On 3 Jul 2015 at 9:05, Rob Stewart wrote:
Boost once was the place to playpen exciting new C++ libraries - if you read this mailing list back in 1999-2001, there was a palpable excitement here as people tried new things and showed one other what could be possible. Rather like in the Rust mailing list nowadays.
From 2008-2009 onwards things haven't been as good here, and especially since Dave left.
You've made this sort of remark before. Dave didn't do anything particularly special except to be highly active and contribute a great deal. (Yes, he provided leadership, but he wasn't alone and others who did so are still part of the community.)
He did a lot more than that Rob. For a lot of people, including myself, Dave *was* Boost for most of its lifespan. It probably didn't seem that way from inside Boost, but as an outsider if Dave decided you had a contribution to make he acted as the nexus point to make that happen. He managed the internal people required to achieve outcomes. Since his departure there hasn't been a dependable, reliable source of support for those outside Boost who wanted something fixed at a holistic level. Or indeed much support for anyone inside Boost. Trying to change or upgrade infrastructure is a Kafka-esque soul draining affair - even getting the Boost SSL cert replaced, which *still* hasn't happened, has proven that. Nobody knows who to go talk to about something half the time because the lists of names responsible for infrastructure are so out of date. It shouldn't be as hard as it is to contribute to Boost outside the libraries you maintain. It shouldn't be hard to upgrade infrastructure at all. It should be *easy*. It definitely shouldn't be the case that Boost infrastructure is rotting away, and nobody is doing anything about it and any attempts to get the steering committee to move on this go nowhere, despite repeated attempts by myself and others.
It doesn't help when members of the steering committee conspicuously fail to perform their duties, and specifically disavow taking any leadership position except to intentionally prevent and inhibit change.
I have no idea to what you're referring, but I highly doubt that this is a fair characterization of any member of the committee and certainly not of the committee itself.
The Steering Committee, admittedly not ideally named, was formed for two key purposes: to be able to commit Boost money, when required, and to make a decision for the community when there isn't a clear consensus, not unlike how a Review Manager considers reviews for a decision but doesn't just count the votes.
Any perceived reticence to make a decision on something may be due to unseen activity or to the misapprehension of what the committee should do.
If you have specific concerns, don't malign the committee in this fashion on the developer's list but raise them on the committee list. Others can follow that list, so the discussion won't be hidden.
You can thank Jon Kalb that I did not respond to this section in detail. What he has encouraged me to do instead is to try once again at getting you to act, so here we go: https://groups.google.com/forum/#!topic/boost-steering/VNYtWFnZuug Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 07/06/2015 04:01 AM, Niall Douglas wrote:
Trying to change or upgrade infrastructure is a Kafka-esque soul draining affair - even getting the Boost SSL cert replaced, which *still* hasn't happened, has proven that. Nobody knows who to go talk to about something half the time because the lists of names responsible for infrastructure are so out of date.
This is has been too true for the SSL. I've been working as the middle man to try and get the cert updated for several weeks now. Not as a member of the steering committee... just as an annoyed member of the community. I finally have all the right players involved but still no personal control to make it happen. It is crazy frustrating!
It shouldn't be as hard as it is to contribute to Boost outside the libraries you maintain. It shouldn't be hard to upgrade infrastructure at all. It should be*easy*.
Agreed! Were you able to find a list of who-is-responsible for infrastructure? Perhaps we can come up with a list of items and who in the community has permissions or control. If you found a list we could use that as a starting point. Otherwise, I suspect you and I have a list of things we have been trying to do that require knowing a responsible party. I'd be happy to try and keep such a thing up-to-date.
It definitely shouldn't be the case that Boost infrastructure is rotting away, and nobody is doing anything about it and any attempts to get the steering committee to move on this go nowhere, despite repeated attempts by myself and others.
Well, I don't think this is a completely accurate characterization. You have been trying to do something. I am trying to do something. I have several infrastructure test servers running evaluations of things my team is trying to pull together for Boost. It sounds like Rene is working on some things. Maybe we should have a location that our non-library ventures and efforts are described/updated so people can know what is going on and get involved if they are interested? michael -- Michael Caisse ciere consulting ciere.com
On 6 Jul 2015 at 7:57, Michael Caisse wrote:
On 07/06/2015 04:01 AM, Niall Douglas wrote:
Trying to change or upgrade infrastructure is a Kafka-esque soul draining affair - even getting the Boost SSL cert replaced, which *still* hasn't happened, has proven that. Nobody knows who to go talk to about something half the time because the lists of names responsible for infrastructure are so out of date.
This is has been too true for the SSL. I've been working as the middle man to try and get the cert updated for several weeks now. Not as a member of the steering committee... just as an annoyed member of the community. I finally have all the right players involved but still no personal control to make it happen. It is crazy frustrating!
We ought to have systems and processes in place such that the loss of control of vital infrastructure never happens again.
It shouldn't be as hard as it is to contribute to Boost outside the libraries you maintain. It shouldn't be hard to upgrade infrastructure at all. It should be*easy*.
Agreed! Were you able to find a list of who-is-responsible for infrastructure?
I gave up. I have a Boost library to get ready for review, and job interviews to do as I'll be unemployed from the 17th onwards. Indeed I just did one there before this email with Google Dublin.
Perhaps we can come up with a list of items and who in the community has permissions or control. If you found a list we could use that as a starting point. Otherwise, I suspect you and I have a list of things we have been trying to do that require knowing a responsible party. I'd be happy to try and keep such a thing up-to-date.
This is exactly where we don't agree. You, and most on the SC, believe that it's just a matter of business as usual - community members carve out some time to do boring stuff like keep lists fresh. I've been saying that isn't working because it hasn't been working. If you put processes and systems in place where it is automatically the case that these lists are kept fresh as part of those processes occurring, nobody needs to carve out time any more. One way, as I proposed, was an annual election of a Strategic Planning Committee. The newly elected members, as part of deciding how to spend their monies, would have to unavoidably maintain lists of people responsible for infrastructure. That's what I mean about instituting systems and processes which makes this stuff automatic.
It definitely shouldn't be the case that Boost infrastructure is rotting away, and nobody is doing anything about it and any attempts to get the steering committee to move on this go nowhere, despite repeated attempts by myself and others.
Well, I don't think this is a completely accurate characterization. You have been trying to do something. I am trying to do something. I have several infrastructure test servers running evaluations of things my team is trying to pull together for Boost. It sounds like Rene is working on some things. Maybe we should have a location that our non-library ventures and efforts are described/updated so people can know what is going on and get involved if they are interested?
Nothing poisons and embitters someone who volunteers and invests their family time into endeavours as quickly as their efforts being undervalued by the community to which they were contributed. There is a ton of that happening here, indeed I myself on more than one occasion have undervalued or not been aware of substantial efforts made by others into infrastructure. The consistent theme that I have been repeating since Dave left is support, support, support (not the financial kind, the emotional kind). Boost needs to emotionally support its community members far, far better than historically, and because we are all busy with uncertain schedules, instituting systems and processes which support those who volunteer makes that support automatic, same as keeping lists fresh. All the proposals I've sent to boost-steering have all been designed to make support better, and automatic, for anyone contributing outside the libraries they maintain i.e. at a holistic level. Hence the idea of a Strategic Planning Committee with ring fenced funding, you are really establishing an elected support group for anybody making changes to ten or more Boost libraries in some area or matter. The ring fenced funding makes people take them seriously as a group, plus forces them as a group to make decisions annually on how to spend which is far more important than spending the money itself. The money value itself is actually unimportant, it is the behaviours in people it generates. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On July 6, 2015 7:01:07 AM EDT, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 3 Jul 2015 at 9:05, Rob Stewart wrote:
Boost once was the place to playpen exciting new C++ libraries - if you read this
mailing list back in 1999-2001, there was a palpable excitement here as people tried new things and showed one other what could be possible. Rather like in the Rust mailing list nowadays.
From 2008-2009 onwards things haven't been as good here, and especially since Dave left.
You've made this sort of remark before. Dave didn't do anything particularly special except to be highly active and contribute a great deal. (Yes, he provided leadership, but he wasn't alone and others who did so are still part of the community.)
He did a lot more than that Rob. For a lot of people, including myself, Dave *was* Boost for most of its lifespan. It probably didn't seem that way from inside Boost, but as an outsider if Dave decided you had a contribution to make he acted as the nexus point to make that happen. He managed the internal people required to achieve outcomes.
Okay, but that's still someone being highly active in the community. He had a lot of influence, but he didn't dictate things.
Since his departure there hasn't been a dependable, reliable source of support for those outside Boost who wanted something fixed at a holistic level. Or indeed much support for anyone inside Boost. Trying to change or upgrade infrastructure is a Kafka-esque soul draining affair - even getting the Boost SSL cert replaced, which *still* hasn't happened, has proven that. Nobody knows who to go talk to about something half the time because the lists of names responsible for infrastructure are so out of date.
Several times, people who didn't know what was necessary tried to help, but many times folks were talking past one another with each party thinking the other would do something that didn't happen. Indeed, I thought things were moving on that front.
It shouldn't be as hard as it is to contribute to Boost outside the libraries you maintain. It shouldn't be hard to upgrade infrastructure at all. It should be *easy*.
When infrastructure grows organically and a small number of people do most of the work, it can be hard to effect changes. That's life. Add to that during goals and ideas of what should be done and it's easy to understand why things move slowly.
It definitely shouldn't be the case that Boost infrastructure is rotting away, and nobody is doing anything about it and any attempts to get the steering committee to move on this go nowhere, despite repeated attempts by myself and others.
You continue to expect more of the Steering Committee than is in its charter.
It doesn't help when members of the steering committee conspicuously fail to perform their duties, and specifically disavow taking any leadership position except to intentionally prevent and inhibit change.
I have no idea to what you're referring, but I highly doubt that this is a fair characterization of any member of the committee and certainly not of the committee itself.
The Steering Committee, admittedly not ideally named, was formed for two key purposes: to be able to commit Boost money, when required, and to make a decision for the community when there isn't a clear consensus, not unlike how a Review Manager considers reviews for a decision but doesn't just count the votes.
Any perceived reticence to make a decision on something may be due to unseen activity or to the misapprehension of what the committee should do.
If you have specific concerns, don't malign the committee in this fashion on the developer's list but raise them on the committee list. Others can follow that list, so the discussion won't be hidden.
You can thank Jon Kalb that I did not respond to this section in detail.
What he has encouraged me to do instead is to try once again at getting you to act, so here we go:
https://groups.google.com/forum/#!topic/boost-steering/VNYtWFnZuug
That proposal is not all that different from one you proposed earlier. The Committee is awaiting some legal feedback to the best of my recollection, but is not averse to trying something like what you've proposed. I appreciate your zeal and effort on behalf of Boost. I also appreciate your attempt to be positive despite your ongoing sense of frustration. ___ Rob (Sent from my portable computation engine)
On 6 Jul 2015 at 18:29, Rob Stewart wrote:
Since his departure there hasn't been a dependable, reliable source of support for those outside Boost who wanted something fixed at a holistic level. Or indeed much support for anyone inside Boost. Trying to change or upgrade infrastructure is a Kafka-esque soul draining affair - even getting the Boost SSL cert replaced, which *still* hasn't happened, has proven that. Nobody knows who to go talk to about something half the time because the lists of names responsible for infrastructure are so out of date.
Several times, people who didn't know what was necessary tried to help, but many times folks were talking past one another with each party thinking the other would do something that didn't happen. Indeed, I thought things were moving on that front.
The traditional solution to that is to attach specific names to responsibilities, and to ping them every six months to ensure they are still willing to hold that responsibility. Somebody has to regularly do the pinging of course. c.f. my previous email to Michael about making keeping lists fresh automatic.
It shouldn't be as hard as it is to contribute to Boost outside the libraries you maintain. It shouldn't be hard to upgrade infrastructure at all. It should be *easy*.
When infrastructure grows organically and a small number of people do most of the work, it can be hard to effect changes. That's life. Add to that during goals and ideas of what should be done and it's easy to understand why things move slowly.
I disagree profoundly with this statement. Things happen here at a snail's pace, if at all, because of the very low quality management processes in place. It should never occur that people talk past one another or parties think the other side is going to take action first. It should never occur that a small number of people, in which there has been remarkably little churn over the years, do almost all the work. Other open source orgs, and ones much larger than Boost, don't have these scalability problems. They also quite literally teach this bread and butter management stuff in first and second year Management. It's very well understood.
It definitely shouldn't be the case that Boost infrastructure is rotting away, and nobody is doing anything about it and any attempts to get the steering committee to move on this go nowhere, despite repeated attempts by myself and others.
You continue to expect more of the Steering Committee than is in its charter.
You misunderstand my criticism. The Boost Steering Committee has the legal power to set any role for itself it chooses. The fact you don't is *your* choice not to do so. That is the source of my criticism. You have the power to do a lot more than you do, and you actively choose to not do so, or appoint subcommittees who would do so.
What he has encouraged me to do instead is to try once again at getting you to act, so here we go:
https://groups.google.com/forum/#!topic/boost-steering/VNYtWFnZuug
That proposal is not all that different from one you proposed earlier. The Committee is awaiting some legal feedback to the best of my recollection, but is not averse to trying something like what you've proposed.
That's because I first sent proposals to boost-steering a year ago, and nothing has changed. Now I am repeating myself.
I appreciate your zeal and effort on behalf of Boost. I also appreciate your attempt to be positive despite your ongoing sense of frustration.
You have an enormous asset in the form of Jon Kalb. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (6)
-
Gottlob Frege -
Michael Caisse -
Niall Douglas -
Rene Rivera -
Rob Stewart -
Robert Ramey