Re: [boost] Maintenance suspended
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
Dave, having a single library to maintain I probably cannot fully appreciate your situation. However, I would like to attract your attention to the very special position you have in this community, especially among newcomers I count myself with. Seeing dave (I mean THE dave! ;-) ) not maintaining his libraries creates a precedent and sends a wrong signal, which deals a blow to boost's credibility. Companies could wonder, waow, if the community cannot even help dave maintain his libraries, in which state must be others? Also considering that ryppl is so far not a reality yet and not even agreed on, we need a solution for the time being. Why not simply request help from the community to which you brought so much? I'm sure that many would be happy to help you on this. So, concretely, what is the problem? Do you have no time handling the feature requests or is svn the problem? If it is just about merging and doing some mechanical svn-related tasks, this is a very workable solution and I gladly offer my help. If it is about feature requests, this is a more complicated one (but seemingly unrelated to svn) and you could also ask for support on this list. Surely, someone competent will step forward and free you from much work. You could simply review patches before commit. It would also help the community by having more than one person familiar with your libraries. Christophe PS: Thinking about it more, it would be a good idea if every boost author would mentor one or several "young" members who could take over when the author's situation changes. In any company, we usually try to avoid having only one person knowing a subject. Maybe a boostcon would be a good place where authors would explain the inside of their library?
On Jul 8, 2010, at 8:28 AM, Christophe Henry wrote:
I would like to attract your attention to the very special position you have in this community, especially among newcomers I count myself with. Seeing dave (I mean THE dave! ;-) ) not maintaining his libraries creates a precedent and sends a wrong signal, which deals a blow to boost's credibility. Companies could wonder, waow, if the community cannot even help dave maintain his libraries, in which state must be others?
Also considering that ryppl is so far not a reality yet and not even agreed on, we need a solution for the time being. Why not simply request help from the community to which you brought so much? I'm sure that many would be happy to help you on this.
Heh, leave it to the Boost community to teach me that there's a Boost community! Thank you, Christophe, you're very right. I hereby apologize to the community for my earlier announcement and request that you accept a retraction :-)
So, concretely, what is the problem? Do you have no time handling the feature requests or is svn the problem?
I'll prepare a proper response to these questions in a separate message, but I wanted to head off any damage immediately. Regards, -- David Abrahams BoostPro Computing http://boostpro.com
On Jul 8, 2010, at 8:28 AM, Christophe Henry wrote:
I would like to attract your attention to the very special position you have in this community, especially among newcomers I count myself with. Seeing dave (I mean THE dave! ;-) ) not maintaining his libraries creates a precedent and sends a wrong signal, which deals a blow to boost's credibility. Companies could wonder, waow, if the community cannot even help dave maintain his libraries, in which state must be others?
Also considering that ryppl is so far not a reality yet and not even agreed on, we need a solution for the time being. Why not simply request help from the community to which you brought so much? I'm sure that many would be happy to help you on this.
Heh, leave it to the Boost community to teach me that there's a Boost community! Thank you, Christophe, you're very right.
I hereby apologize to the community for my earlier announcement and request that you accept a retraction :-)
So, concretely, what is the problem? Do you have no time handling the feature requests or is svn the problem?
I'll prepare a proper response to these questions in a separate message, but I wanted to head off any damage immediately.
Thank you for reconsidering! Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
On 7/8/10 8:28 PM, Christophe Henry wrote:
PS: Thinking about it more, it would be a good idea if every boost author would mentor one or several "young" members who could take over when the author's situation changes. In any company, we usually try to avoid having only one person knowing a subject. Maybe a boostcon would be a good place where authors would explain the inside of their library?
This is exactly what happened to Fusion and now happening to Phoenix with the past and present GSOC projects. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Jul 8, 2010, at 8:39 PM, Joel de Guzman wrote:
On 7/8/10 8:28 PM, Christophe Henry wrote:
PS: Thinking about it more, it would be a good idea if every boost author would mentor one or several "young" members who could take over when the author's situation changes. In any company, we usually try to avoid having only one person knowing a subject. Maybe a boostcon would be a good place where authors would explain the inside of their library?
This is exactly what happened to Fusion and now happening to Phoenix with the past and present GSOC projects.
Hey, that's a great idea. To actually institute such a program requires someone to come up with "young" members who are ready and willing to be mentored. Christophe, would you like to take that project on? -- David Abrahams BoostPro Computing http://boostpro.com
On Jul 8, 2010, at 8:28 AM, Christophe Henry wrote:
So, concretely, what is the problem? Do you have no time handling the feature requests or is svn the problem?
All of it. I've lost track of the differences between trunk and release. I have a pile of local changes that look like they were for something important, but need to be evaluated. SVN operations are slow for me. The presence of all the other libraries in the repo is a distraction. The inability to do anything to a single library in SVN because of the directory structure is maddening. All of these things are probably minor by themselves, but they add up.
If it is just about merging and doing some mechanical svn-related tasks, this is a very workable solution and I gladly offer my help. If it is about feature requests, this is a more complicated one (but seemingly unrelated to svn) and you could also ask for support on this list. Surely, someone competent will step forward and free you from much work. You could simply review patches before commit. It would also help the community by having more than one person familiar with your libraries.
My libraries, other than Boost.Python, are formally collaborations. So in theory there should be other people to pick up the slack. However, some of my co-authors have not been very active recently. -- David Abrahams BoostPro Computing http://boostpro.com
On Fri, Jul 9, 2010 at 7:48 AM, David Abrahams <dave@boostpro.com> wrote:
On Jul 8, 2010, at 8:28 AM, Christophe Henry wrote:
So, concretely, what is the problem? Do you have no time handling the feature requests or is svn the problem?
All of it. I've lost track of the differences between trunk and release. I have a pile of local changes that look like they were for something important, but need to be evaluated. SVN operations are slow for me. The presence of all the other libraries in the repo is a distraction. The inability to do anything to a single library in SVN because of the directory structure is maddening. All of these things are probably minor by themselves, but they add up.
If it is just about merging and doing some mechanical svn-related tasks, this is a very workable solution and I gladly offer my help. If it is about feature requests, this is a more complicated one (but seemingly unrelated to svn) and you could also ask for support on this list. Surely, someone competent will step forward and free you from much work. You could simply review patches before commit. It would also help the community by having more than one person familiar with your libraries.
My libraries, other than Boost.Python, are formally collaborations. So in theory there should be other people to pick up the slack. However, some of my co-authors have not been very active recently.
Maybe there should be two types of maintainers: there could be the usual, actively maintained libraries and a new type of "passively" maintained library. A passively maintained library could be modified without the maintainers direct evolvement. But of course, the maintainer would hold a veto prerogative over any change. So, when someone submits a patch for a bug or feature request for a passively maintained library, 1) if people on the list are interested and agree, then the patch can be applied; 2) if there is a dispute, it can be brought to the attention of the passive maintainer for resolution; 3) the passive maintainer can always veto. This would only work when users/boosters take the initiative to learn the code and submit a patch, but that's not unusual. Giving library authors an opportunity to declare their intent to become passive maintainers could be a good thing. For one, this would allow authors of mature libraries to transition openly to other projects rather than simply disappearing. Not everyone has the courage to recognize when their circumstance are changing, as you did Dave. Thanks for taking the lead on this! Daniel Walker P.S. And also thanks for retracting your suspension! Personally, I have learned so much from your work with boost over the years. The more active you are, the better off all the rest of us are!
[sent from tiny mobile device] On Jul 9, 2010, at 9:26 AM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
Maybe there should be two types of maintainers: there could be the usual, actively maintained libraries and a new type of "passively" maintained library. A passively maintained library could be modified without the maintainers direct evolvement.
Technically speaking we can already do that, but it isn't neighborly.
But of course, the maintainer would hold a veto prerogative over any change. So, when someone submits a patch for a bug or feature request for a passively maintained library,
1) if people on the list are interested and agree, then the patch can be applied; 2) if there is a dispute, it can be brought to the attention of the passive maintainer for resolution; 3) the passive maintainer can always veto.
This would only work when users/boosters take the initiative to learn the code and submit a patch, but that's not unusual. Giving library authors an opportunity to declare their intent to become passive maintainers could be a good thing.
I love it. +1 from me
For one, this would allow authors of mature libraries to transition openly to other projects rather than simply disappearing. Not everyone has the courage to recognize when their circumstance are changing, as you did Dave. Thanks for taking the lead on this!
Daniel Walker
P.S. And also thanks for retracting your suspension! Personally, I have learned so much from your work with boost over the years. The more active you are, the better off all the rest of us are! _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
Christophe Henry -
Daniel Walker -
David Abrahams -
Hartmut Kaiser -
Joel de Guzman