Boost, Decoupled and Accelerated
Hi All, I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a full-time job. For me, this situation has taken a lot of the fun out of participating. It's time to make Boost development fun again. To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session **Tuesday night at BoostCon** to formally unveil this system and demonstrate it in action, and I intend to propose that Boost make the move immediately thereafter. I believe this project has the potential to change the face not only of Boost, but of open-source software in general. By the time of BoostCon, ryppl will be live, and we'll be able to use it to work on Boost. I encourage anyone who is interested in these developments to register for BoostCon immediately. If you're interested in working on development of this system, *please* send me an email; we can really use your help. Be forewarned, though: this may not operate like many other open-source projects. Given the short period of time remaining before the conference, we have little time for design discussion and debate, and we need to be maximally effective: there's simply no time to waste. You can expect me to take a “Benevolent Dictator” role, if not “For Life,” (BDFL) then at least “For the Time Being” (BDFTB). Cheers, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Hi All,
I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a full-time job. For me, this situation has taken a lot of the fun out of participating. It's time to make Boost development fun again.
To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session
**Tuesday night at BoostCon**
Count me in. This is rather required. If I can help at least with testing that as a potential user, feel free. Question: Is Ryppl boost-centric or can it be used as a stand-alone system for otehr OS project ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
At Tue, 16 Mar 2010 17:27:59 +0100, joel falcou wrote:
Count me in. This is rather required. If I can help at least with testing that as a potential user, feel free.
Thanks! When I'm ready to solicit testers, I'll make an announcement.
Question: Is Ryppl boost-centric or can it be used as a stand-alone system for otehr OS project ?
The latter. Boost, and each of its libraries, will each be just one among many ryppl projects. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Thanks! When I'm ready to solicit testers, I'll make an announcement.
Sorry to not be able knowledgable enough to help before :(
The latter. Boost, and each of its libraries, will each be just one among many ryppl projects.
Great. I may have need for such a system for our own project that may end up quite large and require "componentability". -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
David Abrahams <dave <at> boostpro.com> writes:
To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session
Does it mean we'll have independent versioning for each boost library? If yes, i am both hands up for it. I was advocating this last time boost development procedures were updated. Gennadiy
Gennadiy Rozental wrote:
Does it mean we'll have independent versioning for each boost library? If yes, i am both hands up for it. I was advocating this last time boost development procedures were updated.
Never tought of that. It makes a lot of sense. Count my both hands too -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
At Tue, 16 Mar 2010 18:12:40 +0000 (UTC), Gennadiy Rozental wrote:
David Abrahams <dave <at> boostpro.com> writes:
To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session
Does it mean we'll have independent versioning for each boost library?
Absolutely.
If yes, i am both hands up for it. I was advocating this last time boost development procedures were updated.
Yeah, well it takes some of us a little longer to catch on… :-) -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries.
Did you forget the link to the website, or did you purposely miss it out to build up the suspense ;)?
At Tue, 16 Mar 2010 18:12:59 +0000, Mathias Gaunard wrote:
David Abrahams wrote:
Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries.
Did you forget the link to the website, or did you purposely miss it out to build up the suspense ;)?
The latter ;-) I'll probably announce the website soon. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
On Tue, 2010-03-16 at 23:08 -0400, David Abrahams wrote:
At Tue, 16 Mar 2010 18:12:59 +0000, Mathias Gaunard wrote:
David Abrahams wrote:
Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. Did you forget the link to the website, or did you purposely miss it out to build up the suspense ;)? The latter ;-) I'll probably announce the website soon.
You'd better hope that nobody did what I did when you first mentioned ryppl and type the name into google... Looks interesting (and I take the obvious caveats that it is still a work in progress). pihl -- Phil Richards, <news@derived-software.ltd.uk>
Hi,
I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a (from a long-time Boost user's perspective)
If this means we can ... * more easily cherry-pick parts of Boost * get updates quicker I'm all for it :) As long as building Boost remains simple, this will make it much easier to promote Boost to new users. Is http://www.ryppl.org/ the correct (read: lastest and greatest) website for this? Cheers, Anteru
David Abrahams wrote:
Hi All,
I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a full-time job. For me, this situation has taken a lot of the fun out of participating. It's time to make Boost development fun again.
Not sure how much time I can offer, but I'd like to contribute to testing on Linux. At my company, we have some hundred modules (mostly libraries and plugins) with a nice amount of dependencies. Our current build system is based on CMake. I'd be interested in seeing how the two systems compare, and (maybe) offering one or two suggestions, too... A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-) How could decentralization influence the overflowing bug tracker? Regards, Roland
At Tue, 16 Mar 2010 21:46:35 +0100, Roland Bock wrote:
Not sure how much time I can offer, but I'd like to contribute to testing on Linux. At my company, we have some hundred modules (mostly libraries and plugins) with a nice amount of dependencies. Our current build system is based on CMake.
Then you should feel right at home :-)
I'd be interested in seeing how the two systems compare, and (maybe) offering one or two suggestions, too...
I'll be putting out a call for testers as soon as we have something ready. Your suggestions will be welcome.
A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-)
How could decentralization influence the overflowing bug tracker?
A very good question. The most obvious thing is that projects could all choose their own issue tracking systems, so nobody needs to be bogged down by the slowness of a single Trac instance or tied to the current stagnation of the Trac development effort. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
AMDG David Abrahams wrote:
A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-)
How could decentralization influence the overflowing bug tracker?
A very good question. The most obvious thing is that projects could all choose their own issue tracking systems, so nobody needs to be bogged down by the slowness of a single Trac instance or tied to the current stagnation of the Trac development effort.
I currently monitor all incoming tickets for all libraries. I won't appreciate having 50 places to look instead of 1. In Christ, Steven Watanabe
At Thu, 18 Mar 2010 07:46:03 -0700, Steven Watanabe wrote:
AMDG
David Abrahams wrote:
A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-)
How could decentralization influence the overflowing bug tracker?
A very good question. The most obvious thing is that projects could all choose their own issue tracking systems, so nobody needs to be bogged down by the slowness of a single Trac instance or tied to the current stagnation of the Trac development effort.
I currently monitor all incoming tickets for all libraries. I won't appreciate having 50 places to look instead of 1.
Understood. Not everyone will be as interested as you are in all of Boost, though. But if there's a need for something like this, we can make it a requirement for Boost libraries that they have a publicly-subscribable mailing list hooked up to their issue tracker, and we can even make it a service of Boost to aggregate those lists into one boost-issues list to which you can subscribe. Or we could decide that Boost policy keeps all project's trackers in one place. Options are wide open. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
At Tue, 16 Mar 2010 21:46:35 +0100, Roland Bock wrote:
A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-)
How could decentralization influence the overflowing bug tracker?
A very good question. The most obvious thing is that projects could all choose their own issue tracking systems, so nobody needs to be bogged down by the slowness of a single Trac instance or tied to the current stagnation of the Trac development effort.
David, Could you give a few more details on how it would be organized at boost.org? Does it mean each library will organize hosting, domain, etc. on its own. Or, all libraries will still be hosted under at boost.org and accessible through subdomain, test.boost.org, asio.boost.org, etc. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
At Thu, 18 Mar 2010 15:03:31 +0000, Mateusz Loskot wrote:
David Abrahams wrote:
At Tue, 16 Mar 2010 21:46:35 +0100, Roland Bock wrote:
A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-)
How could decentralization influence the overflowing bug tracker?
A very good question. The most obvious thing is that projects could all choose their own issue tracking systems, so nobody needs to be bogged down by the slowness of a single Trac instance or tied to the current stagnation of the Trac development effort.
David,
Could you give a few more details on how it would be organized at boost.org?
Exactly how Boost would be mapped onto ryppl is an open question, though I have some specific ideas.
Does it mean each library will organize hosting, domain, etc. on its own. Or, all libraries will still be hosted under at boost.org and accessible through subdomain, test.boost.org, asio.boost.org, etc.
I think that's up to us. Ryppl will allow either system, or something else. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
At Tue, 16 Mar 2010 21:46:35 +0100, Roland Bock wrote:
Not sure how much time I can offer, but I'd like to contribute to testing on Linux. At my company, we have some hundred modules (mostly libraries and plugins) with a nice amount of dependencies. Our current build system is based on CMake.
Then you should feel right at home :-)
I'd be interested in seeing how the two systems compare, and (maybe) offering one or two suggestions, too...
I'll be putting out a call for testers as soon as we have something ready. Your suggestions will be welcome.
A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-)
How could decentralization influence the overflowing bug tracker?
A very good question. The most obvious thing is that projects could all choose their own issue tracking systems, so nobody needs to be bogged down by the slowness of a single Trac instance or tied to the current stagnation of the Trac development effort.
Hmm. At this point, what sounded cool earlier, now becomes a bit frightening. Where do you intend the decentralization to stop? If we are going to follow that path, the next logical step would be that each project could have its own mailing list (which some of them have anyway). I must admit, I wouldn't be much of a fan of that. I am on far too many mailing lists already. And the central mailing list is nice because so many stimulating ideas are passing through. Also, sometimes I wonder: is there a boost library that could help me with problem XY? I send a question to the central list and usually get an answer, soon. Without a central list, where would I send such a question? Will anything remain centralized? For instance review management?
Roland Bock wrote:
David Abrahams wrote:
At Tue, 16 Mar 2010 21:46:35 +0100, Roland Bock wrote:
A question from a user and occasional contributor to the overflowing bug tracker, hoping that you can provide an answer without compromising the dramatics for BoostCon :-)
How could decentralization influence the overflowing bug tracker?
A very good question. The most obvious thing is that projects could all choose their own issue tracking systems, so nobody needs to be bogged down by the slowness of a single Trac instance or tied to the current stagnation of the Trac development effort.
Hmm. At this point, what sounded cool earlier, now becomes a bit frightening. Where do you intend the decentralization to stop?
If we are going to follow that path, the next logical step would be that each project could have its own mailing list (which some of them have anyway).
I must admit, I wouldn't be much of a fan of that. I am on far too many mailing lists already. And the central mailing list is nice because so many stimulating ideas are passing through. Also, sometimes I wonder: is there a boost library that could help me with problem XY? I send a question to the central list and usually get an answer, soon. Without a central list, where would I send such a question?
As an example, at OSGeo Foundation (http://osgeo.org), there number of project and quite a number of mailing lists (http://lists.osgeo.org). There is also one general list called OSGeo Discuss and people post there question "What lib/tool can solve problem X?". I'd say, it works and having project-specific lists works well as they are kept focused on particular problem. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
At Thu, 18 Mar 2010 16:10:22 +0100, Roland Bock wrote:
Hmm. At this point, what sounded cool earlier, now becomes a bit frightening. Where do you intend the decentralization to stop?
Wherever we decide.
If we are going to follow that path, the next logical step would be that each project could have its own mailing list (which some of them have anyway).
That's a possibility. Or not. Or we could go with the status quo (some libraries have their own lists).
I must admit, I wouldn't be much of a fan of that. I am on far too many mailing lists already. And the central mailing list is nice because so many stimulating ideas are passing through. Also, sometimes I wonder: is there a boost library that could help me with problem XY? I send a question to the central list and usually get an answer, soon. Without a central list, where would I send such a question?
Will anything remain centralized? For instance review management?
As far as I can tell, Boost would at *least* have to continue to act as a certifying authority for libraries, so reviews would have to be handled here. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote: [...]
Roland Bock wrote:
Will anything remain centralized? For instance review management?
As far as I can tell, Boost would at *least* have to continue to act as a certifying authority for libraries, so reviews would have to be handled here.
OK, cool :-) Looking forward to upcoming discussions...
On 16 March 2010 16:04, David Abrahams <dave@boostpro.com> wrote:
To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session
This sounds looks to me a lot like nix (see http://nixos.org/nix/ and http://nixos.org/hydra/). Daniel
On 03/16/2010 10:04 AM, David Abrahams wrote:
To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries.
How will Ryppl interact with native package management systems?
2010/3/17 David Abrahams <dave@boostpro.com>
Hi All,
I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a full-time job. For me, this situation has taken a lot of the fun out of participating. It's time to make Boost development fun again.
To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session
Dave, Why Ryppl limited by git (and not by mercurial for instance)? Why it's not SCM agnostic? -- Best Regards, Sergey Nikulov
participants (12)
-
Anteru -
Daniel James -
David Abrahams -
Gennadiy Rozental -
joel falcou -
Mateusz Loskot -
Mathias Gaunard -
Phil Richards -
Rob Riggs -
Roland Bock -
Sergey Nikulov -
Steven Watanabe