All --- I tried, I really did, to resolve the trunk and release branches of my libraries for the upcoming release. But the truth is that I'm finding Boost's current interdependent structure and the sluggishness of SVN on a project of our size just makes everything too hard to do. I'm now just declaring openly what has effectively been true for the past couple of months: I'm not maintaining my libraries until I complete the transition to Git that goes along with using Ryppln (http://ryppl.org). I'm sorry, I know it's not good or right, but I know it's going to be for the best in the long run. That should all happen fairly quickly now, anyway. -- David Abrahams BoostPro Computing http://boostpro.com
I tried, I really did, to resolve the trunk and release branches of my libraries for the upcoming release. But the truth is that I'm finding Boost's current interdependent structure and the sluggishness of SVN on a project of our size just makes everything too hard to do. I'm now just declaring openly what has effectively been true for the past couple of months: I'm not maintaining my libraries until I complete the transition to Git that goes along with using Ryppln (http://ryppl.org). I'm sorry, I know it's not good or right, but I know it's going to be for the best in the long run. That should all happen fairly quickly now, anyway.
Do you have somebody replacing you while in suspension? I can't say agree with your decision, even while I feel your pain. We all have to live with the current setup but nevertheless we can't and do not just throw the towel. It's a comparably minor exercise in patience to do the merge (btw, I just spend 3 days merging Spirit to the release branch, so believe me, I know what you're talking about). It's minor if compared to the effort which is still required to make Ryppl a commonplace tool. And, it will take another release cycle or two to have the move completed. So, I would like to ask you to rethink this decision once more. If everybody did as you plan to do, we would blow this release. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
On Jul 7, 2010, at 4:12 PM, Hartmut Kaiser wrote:
Do you have somebody replacing you while in suspension?
Not formally. I have co-maintainers on most of my libraries, and Boost.Python maintenance has mostly been done by others (especially Ralf Grosse-Kunstleve) for well over a year now.
I can't say agree with your decision, even while I feel your pain. We all have to live with the current setup but nevertheless we can't and do not just throw the towel.
I'm not throwing in the towel; I'm taking a break.
It's a comparably minor exercise in patience to do the merge (btw, I just spend 3 days merging Spirit to the release branch, so believe me, I know what you're talking about). It's minor if compared to the effort which is still required to make Ryppl a commonplace tool. And, it will take another release cycle or two to have the move completed.
So, I would like to ask you to rethink this decision once more. If everybody did as you plan to do, we would blow this release.
My libraries are mostly fairly mature. While there are things that should be improved, there's no reason that not making changes should cause the release to be blown. -- David Abrahams BoostPro Computing http://boostpro.com
Do you have somebody replacing you while in suspension?
Not formally. I have co-maintainers on most of my libraries, and Boost.Python maintenance has mostly been done by others (especially Ralf Grosse-Kunstleve) for well over a year now.
Boost has a clear policy of what has to happen if a maintainer wants to give up (or to take a break as you say below). One of the points is that it has to be ensured maintenance is taken over by somebody else, see: http://lists.boost.org/Archives/boost/2010/03/163884.php. What will happen to the libraries you don't have a co-maintainer for?
I can't say agree with your decision, even while I feel your pain. We all have to live with the current setup but nevertheless we can't and do not just throw the towel.
I'm not throwing in the towel; I'm taking a break.
Nice try. But using a different term doesn't change anything. If somebody else were to write such an email you would be the first to complain.
It's a comparably minor exercise in patience to do the merge (btw, I just spend 3 days merging Spirit to the release branch, so believe me, I know what you're talking about). It's minor if compared to the effort which is still required to make Ryppl a commonplace tool. And, it will take another release cycle or two to have the move completed.
So, I would like to ask you to rethink this decision once more. If everybody did as you plan to do, we would blow this release.
My libraries are mostly fairly mature. While there are things that should be improved, there's no reason that not making changes should cause the release to be blown.
This seems to be illogical to me. If your libraries were stable and mature, then not suspending maintenance wouldn't add any work to your schedule. But I shut up on this as it seems I'm the only one feeling to be cheated on. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
Hartmut Kaiser wrote:
Do you have somebody replacing you while in suspension?
I can't say agree with your decision, even while I feel your pain. We all have to live with the current setup but nevertheless we can't and do not just throw the towel.
So, I would like to ask you to rethink this decision once more. If everybody did as you plan to do, we would blow this release.
I think you (Hartmut) should think about this a little bit more. The current system a) has a "release" every 3 months or so. b) almost guarentees that every release is better than the previous one c) is intended to "de-couple" the efforts of an increasing number of developers. Looking at the release test matrix, I only see a few failures for python and none for dave's other libraries. This suggests to me that issues in these libraries are not urgent and could wait another three months or so without hurting anything. In fact this situation happens all the time in that a developer/maintainer works in "spurts". It's nothing new that things won't make the anticipated date. What is new is an explicit announcement thereof - must of us prefer to lie low in such circumstances. On the other hand, if this is about changing to git from SVN then it would be an entirely different subject. Robert Ramey
Do you have somebody replacing you while in suspension?
I can't say agree with your decision, even while I feel your pain. We all have to live with the current setup but nevertheless we can't and do not just throw the towel.
So, I would like to ask you to rethink this decision once more. If everybody did as you plan to do, we would blow this release.
I think you (Hartmut) should think about this a little bit more.
The current system
a) has a "release" every 3 months or so. b) almost guarentees that every release is better than the previous one c) is intended to "de-couple" the efforts of an increasing number of developers.
Looking at the release test matrix, I only see a few failures for python and none for dave's other libraries. This suggests to me that issues in these libraries are not urgent and could wait another three months or so without hurting anything.
But why suspend maintenance then?
In fact this situation happens all the time in that a developer/maintainer works in "spurts". It's nothing new that things won't make the anticipated date. What is new is an explicit announcement thereof - must of us prefer to lie low in such circumstances.
I definitely appreciate Dave's openness, even if I have the impression he's not entirely honest (mainly with himself, I guess). But who am I to judge?
On the other hand, if this is about changing to git from SVN then it would be an entirely different subject.
Indeed. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
On Jul 7, 2010, at 6:17 PM, Hartmut Kaiser wrote:
Looking at the release test matrix, I only see a few failures for python and none for dave's other libraries. This suggests to me that issues in these libraries are not urgent and could wait another three months or so without hurting anything.
But why suspend maintenance then?
Reason already given. I won't let this last much longer, but if I take the time to work on my libraries in the current structure I won't get Ryppl finished, and frankly, the current structure is unsustainable for me. My ability to keep the libraries healthy actually depends on getting out of this unsustainable cycle.
In fact this situation happens all the time in that a developer/maintainer works in "spurts". It's nothing new that things won't make the anticipated date. What is new is an explicit announcement thereof - must of us prefer to lie low in such circumstances.
I definitely appreciate Dave's openness, even if I have the impression he's not entirely honest (mainly with himself, I guess).
I don't think we should step lightly into the territory of questioning one another's honesty. I don't know what you imagine I'm lying to myself about. This announcement corrects what has become an integrity problem for me: many patches and feature requests for my libraries languish in Trac because the overhead of dealing with them has gotten to be too high, but until now I hadn't made any announcement of my intentions. IMO that is an unacceptable situation.
But who am I to judge?
wasn't-going-to-mention-that-ly y'rs, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
All ---
I tried, I really did, to resolve the trunk and release branches of my libraries for the upcoming release. But the truth is that I'm finding Boost's current interdependent structure and the sluggishness of SVN on a project of our size just makes everything too hard to do. I'm now just declaring openly what has effectively been true for the past couple of months: I'm not maintaining my libraries until I complete the transition to Git that goes along with using Ryppln (http://ryppl.org). I'm sorry, I know it's not good or right, but I know it's going to be for the best in the long run. That should all happen fairly quickly now, anyway.
-- David Abrahams BoostPro Computing http://boostpro.com
I assume this means ryppl is no longer a proposal to the 50-ish Boost authors but now the direction selected by the moderators? -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Jul 8, 2010, at 1:23 AM, Michael Caisse wrote:
I assume this means ryppl is no longer a proposal to the 50-ish Boost authors but now the direction selected by the moderators?
Actually, I don't think there's been any formal selection. If it fails to be adopted, obviously, I'll have to regroup and figure out what to do. -- David Abrahams BoostPro Computing http://boostpro.com
David Abrahams wrote:
All ---
I tried, I really did, to resolve the trunk and release branches of my libraries for the upcoming release. But the truth is that I'm finding Boost's current interdependent structure and the sluggishness of SVN on a project of our size just makes everything too hard to do.
Maybe, you could describe your SVN workflow? While SVN certainly could be a bit faster, I find that since server upgrade to 1.6 and first merge with 1.6, subsequent merges take less time that I need to deal with a cup of tea. And it's once per release cycle. - Volodya
I tried, I really did, to resolve the trunk and release branches of my libraries for the upcoming release. But the truth is that I'm finding Boost's current interdependent structure and the sluggishness of SVN on a project of our size just makes everything too hard to do.
Maybe, you could describe your SVN workflow? While SVN certainly could be a bit faster, I find that since server upgrade to 1.6 and first merge with 1.6, subsequent merges take less time that I need to deal with a cup of tea. And it's once per release cycle.
Hmmm, I'm still finding merges very slow for large trees - Boost.Math takes a good hour or more to merge for example - I would expect Boost.Python to be the same. That said, I only merge when I've accumulated enough changes to make a "release" for that library worthwhile, and it's not like I have to hold it's hand or anything while the merge is going on. So it's basically 5 minutes and then get on with something else, then when the merge is complete I visually inspect the diff and run the tests on the release branch - again the latter can take quite a while, but again it's just a case of fire off the command and then leave it to it. So the amount of my time spent on merging is very minimal, provided of course you're not in a hurry and don't desperately need the machine cycles for something else. This also assuming you're doing a "bring the release branch into synch with Trunk" kind of merge - I haven't tried merging specific patches or revisions - I assume that would take rather more figuring out. John.
David Abrahams wrote:
I'm not maintaining my libraries until I complete the transition to Git that goes along with using Ryppln (http://ryppl.org).
Hi David, Thank you for posting that URL. I have been waiting for some more info about this since your enigmatic "teaser" post back in March (http://thread.gmane.org/gmane.comp.lib.boost.devel/200952), saying that we would have to come to BoostCon to learn more. If there is anyone else who presented something at BoostCon and has material online that could be of interest to those of us who didn't go, do please post a link (preferably in a message with a subject line that will attract attention). Thanks. Phil.
On 9 July 2010 16:32, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
David Abrahams wrote:
I'm not maintaining my libraries until I complete the transition to Git that goes along with using Ryppln (http://ryppl.org).
Hi David,
Thank you for posting that URL. I have been waiting for some more info about this since your enigmatic "teaser" post back in March (http://thread.gmane.org/gmane.comp.lib.boost.devel/200952), saying that we would have to come to BoostCon to learn more.
If there is anyone else who presented something at BoostCon and has material online that could be of interest to those of us who didn't go, do please post a link (preferably in a message with a subject line that will attract attention). Thanks.
Phil.
You can find the BoostCon presentation materials here: http://www.boostcon.com/community/wiki/show/private/2010/. Jeroen
Jeroen Habraken wrote:
On 9 July 2010 16:32, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
If there is anyone else who presented something at BoostCon and has material online that could be of interest to those of us who didn't go, do please post a link (preferably in a message with a subject line that will attract attention). ?Thanks.
You can find the BoostCon presentation materials here: http://www.boostcon.com/community/wiki/show/private/2010/.
Thanks Jeroen. Lots of interesting stuff there I'm sure. (Was this announced previously? Is there any significance to the "private" in the URL?) Phil.
participants (8)
-
David Abrahams -
Hartmut Kaiser -
Jeroen Habraken -
John Maddock -
Michael Caisse -
Phil Endecott -
Robert Ramey -
Vladimir Prus