According to the tracker, it looks like the last ticket with activity is https://svn.boost.org/trac/boost/ticket/5257 which is 16 months ago. Also, according to the mailing list I see a lot of discussion/patches dieing out of inactivity ("[boost] [date_time] warning removal", "[boost] [Date Time] bug in documentation example (Localization Demonstration)"). I'm not here to point fingers, we all have busy times where we just cannot handle open-source responsabilities anymore, but maybe this lib should be switched to "no active maintainers" to avoid any confusion? Also, and probably I should have begin with this, is there a page that lists who is the maintainer of what lib beside the Trac? I couldn't find any, but I didn't look very hard either. Philippe
I was surprised too, almost a year ago, that there have been no reaction - not even a reply - to a date_time bug I reported on this mailing list ( https://svn.boost.org/trac/boost/ticket/5753). Joel Lamotte
On Fri, Jun 29, 2012 at 12:02 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I was surprised too, almost a year ago, that there have been no reaction - not even a reply - to a date_time bug I reported on this mailing list ( https://svn.boost.org/trac/boost/ticket/5753).
Boost does not appear to have a policy for maintainers that go missing in action. I think someone (maybe steering committe) should come up with some policy. -- Olaf
Olaf van der Spek wrote:
On Fri, Jun 29, 2012 at 12:02 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I was surprised too, almost a year ago, that there have been no reaction - not even a reply - to a date_time bug I reported on this mailing list ( https://svn.boost.org/trac/boost/ticket/5753).
Boost does not appear to have a policy for maintainers that go missing in action. I think someone (maybe steering committe) should come up with some policy.
well, I'm not on any steering commitee - as far as I know - but here's an idea. let's take date/time as a good example. a) Some smart guy with an interest/need for a version of the library with all or most of the fixes applied does the work. b) He adds his name to the copyright notice c) Posts on his website and offers it to anyone who want's to pay $X for a "supported/updated" version of the date/time library. Payment is via paypal or some simple system. d) the boost version remains as it is, but now there's an alternative for those who need an updated/maintained/supported version. e) someday - date/time INTERFACE becomes part of the C++ standard. This means that compiler vendors who want to be "conforming" should supply an implementation. They now have a few choices: i) roll their own ii) roll in the boost version with minimal changes iii) acquire rights to the supported/updated version f) someday - the boost version falls into disuse as all/most compiler vendors include a maintained/supported version with their products. The boost version can now be dropped from the boost distribution. Note that there is alternative date/time implementation - with a different interface available from - I believe Rogue Wave. So this isn't a totally off the wall idea. Everyone wins: a) hackers like us can use the free version until it comes included with the compilers we acquire. b) companies which don't want to waste time/money fixing the package have a cost/effective alternative. c) someone gets paid to the the hard work. d) C++ eventually gets a new standard library - compiler vendors have a number of options from including an implementation along with their product. Any takers? Robert Ramey
To: boost@lists.boost.org From: ramey@rrsd.com
Olaf van der Spek wrote:
On Fri, Jun 29, 2012 at 12:02 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I was surprised too, almost a year ago, that there have been no reaction - not even a reply - to a date_time bug I reported on this mailing list ( https://svn.boost.org/trac/boost/ticket/5753).
Boost does not appear to have a policy for maintainers that go missing in action. I think someone (maybe steering committe) should come up with some policy.
well, I'm not on any steering commitee - as far as I know - but here's an idea.
let's take date/time as a good example.
a) Some smart guy with an interest/need for a version of the library with all or most of the fixes applied does the work.
b) He adds his name to the copyright notice
c) Posts on his website and offers it to anyone who want's to pay $X for a "supported/updated" version of the date/time library. Payment is via paypal or some simple system.
d) the boost version remains as it is, but now there's an alternative for those who need an updated/maintained/supported version.
e) someday - date/time INTERFACE becomes part of the C++ standard. This means that compiler vendors who want to be "conforming" should supply an implementation. They now have a few choices:
i) roll their own ii) roll in the boost version with minimal changes iii) acquire rights to the supported/updated version
Are you assuming that the supported/updated version will not contain changes to the interface? If not, which interface would be chosen for the standard? Regards, Nate
Nathan Ridge wrote:
Are you assuming that the supported/updated version will not contain changes to the interface?
I'm assuming nothing. The person who actually does the work makes the decision. This would be a business decision on his part. If I were doing it, I would not change the interface and strive to make a drop in replacement in every way - except for bug fixes and possibly ehancements.
If not, which interface would be chosen for the standard?
That is up to the standards commitee as always. Robert Ramey
Regards, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Olaf van der Spek wrote:
On Fri, Jun 29, 2012 at 12:02 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I was surprised too, almost a year ago, that there have been no reaction - not even a reply - to a date_time bug I reported on this mailing list (https://svn.boost.org/trac/boost/ticket/5753).
I've been in contact with Jeff and he acknowledges that he needs to do something about this.
Boost does not appear to have a policy for maintainers that go missing in action.
We have this policy, which is half of the equation: http://www.boost.org/development/submissions.html#Lifecycle
I think someone (maybe steering committe) should come up with some policy.
This sounded awfully familiar, so I checked. I'm supposed to write up something like the following and post it to the web site: "When a Boost library maintainer becomes unresponsive, the following process provides a means to take over maintenance: "1. Identify the maintainer of the code that is languishing. "2. Appeal to the maintainer, by name, in a properly targeted message to the developer's list (with the right '[library]' tag in the subject line). "3. Bump the message a time or two over the course of a month or so. "4. Try contacting the maintainer directly yourself or through others on the developer's list. "5. Declare the library to have no maintainer on the developer's list and volunteer to be the new maintainer. "6. Assume maintenance of the library if there are no objections raised on the developer's list within two weeks." This is certainly a good start and I welcome any input you may have before I post it. At any rate, step 4 has worked, though Jeff has not yet responded on-list. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Sun, Jul 8, 2012 at 1:46 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Boost does not appear to have a policy for maintainers that go missing in action.
We have this policy, which is half of the equation:
http://www.boost.org/development/submissions.html#Lifecycle
I think someone (maybe steering committe) should come up with some policy.
This sounded awfully familiar, so I checked. I'm supposed to write up something like the following and post it to the web site:
"When a Boost library maintainer becomes unresponsive, the following process provides a means to take over maintenance:
"1. Identify the maintainer of the code that is languishing. "2. Appeal to the maintainer, by name, in a properly targeted message to the developer's list (with the right '[library]' tag in the subject line). "3. Bump the message a time or two over the course of a month or so. "4. Try contacting the maintainer directly yourself or through others on the developer's list. "5. Declare the library to have no maintainer on the developer's list and volunteer to be the new maintainer. "6. Assume maintenance of the library if there are no objections raised on the developer's list within two weeks."
This is certainly a good start and I welcome any input you may have before I post it. At any rate, step 4 has worked, though Jeff has not yet responded on-list.
Shouldn't we try to move to team maintenance for most if not all libs? Having only one (or two) people responsible for widely used libraries doesn't seem ideal. I think a lot of people would be willing to help out. -- Olaf
Shouldn't we try to move to team maintenance for most if not all libs? Having only one (or two) people responsible for widely used libraries doesn't seem ideal. I think a lot of people would be willing to help out.
I think this is a great idea. We need to make it easier for user patches to be applied. Philippe
Philippe Vaucher wrote:
Shouldn't we try to move to team maintenance for most if not all libs?
-1
Having only one (or two) people responsible for widely used libraries doesn't seem ideal.
one person is plenty if he keeps the work up to date.
I think a lot of people would be willing to help out.
I think lots of people would be happy to apply their own patches. But they solve their own problems and don't think of the situation as a whole. I get patches all the time. about half of them are mistakes - that is would break something else. half of them are patches to address some misunderstanding in how hte library works. half of them are OK, but end up being tweaked after testing. half of them break some feature of the library - like not requiring RTTI half of them fail to include work arounds for non-conforming compiles * none of the submiters re-run the test suite to verify that there are no side-effects. I guess this is becuase it's so "obvious" that the patch can't break anything that it's not necessary. This job is left to me. So just letting every patch through would create a lot more work than it would save.
I think this is a great idea. We need to make it easier for user patches to be applied.
maybe the best in this case would be to get date.time accepted into the standard - then we can just let the vendors deal with it. Robert Ramey
Philippe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2012-07-19 07:20, Robert Ramey wrote:
Philippe Vaucher wrote:
Having only one (or two) people responsible for widely used libraries doesn't seem ideal. one person is plenty if he keeps the work up to date. In my experience (includes being a non-boost library maintainer for many years):
Two or more persons would allow for - reviews by team mates - one person to step down without the library being orphaned (I found someone to take over, but it was tough after several years of one-man-show) - one person to come on board who is expressing ability and interest (easier to add a person to a small team than to a single developer) - helping a less experienced programmer to build up experience and confidence due to the support of his team mates One person on the other hand: - will make stupid mistakes every now and then no matter how good he or she is - is more likely to get lost by losing interest, insufficient time, new priorities, accident, death... Not everybody is capable of working well in a team though.
I think a lot of people would be willing to help out. I think lots of people would be happy to apply their own patches. <snip>
Between the options of one maintainer and total chaos there are other nuances possible, e.g. a small team. But in the end, IMHO, the maintainers themselves should choose whether prefer to work in a team or not. Just my 2c. Roland
I think having more than one people in the maintenance of a project is good. However, I agree that allowing all patches or most patches is really not a good idea. How do you even make sure the new maintainer, that takes the liberty because no other one wants to, do really understand the library? Maybe just letting people try and then having other people looking at the work would help solve this problem. In other words, it looks like only code reviews from some voluntary people that are not forced to be in the team would help here. (By the way, there were discussions to get a code review software, did it go somewhere?) My 2 cents. Joel Lamotte
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Klaim - Joël Lamotte Sent: Thursday, July 19, 2012 9:39 AM To: boost@lists.boost.org Subject: Re: [boost] [date_time] Who is in charge?
I think having more than one people in the maintenance of a project is good. However, I agree that allowing all patches or most patches is really not a good idea.
How do you even make sure the new maintainer, that takes the liberty because no other one wants to, do really understand the library?
Well it is *his/their* responsibility to consult and to check up on test run results and user feedback. And I feel that having someone to blame is always nice ;-) At present is it nobody's job (or everyone's job?) and the result is not really good enough. So if someone (or two) is willing to take on the task, and we have reasonable confidence in them, we should 'appoint' them (and 'sack' them if it goes badly). At least we can revert to some previous known-ok-ish state. My 2 pence. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
AMDG On 07/19/2012 02:06 AM, Paul A. Bristow wrote:
At present is it nobody's job (or everyone's job?) and the result is not really good enough.
So if someone (or two) is willing to take on the task, and we have reasonable confidence in them, we should 'appoint' them (and 'sack' them if it goes badly). At least we can revert to some previous known-ok-ish state.
Who is "we?" Someone still has to take responsibility for making these decisions, which brings us back to the original problem. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
On 07/19/2012 02:06 AM, Paul A. Bristow wrote:
At present is it nobody's job (or everyone's job?) and the result is not really good enough.
So if someone (or two) is willing to take on the task, and we have reasonable confidence in them, we should 'appoint' them (and 'sack' them if it goes badly). At least we can revert to some previous known-ok-ish state.
Who is "we?" Someone still has to take responsibility for making these decisions, which brings us back to the original problem.
lol - that's absolutly correct. The title of the thread is "who's in charge". The current problem is that no one is in charge. The solution is to find someone who want's to be responsable for the maintainence. I'm sure that if someone want's to step forward and ask for the job, there's a good chance he'll get it. Note that this in no way precludes contributions of effort by many others - that's what the trac system is for and it works very well in my opinion. But this requires a "gatekeeper" which is missing now. In short - the system is fine - just find a new "gatekeeper" Let's try an experiment. Nominations are now open for new gatekeeper for for the date-time library. Rules: a) you can only nominate yourself. b) nominations will close in two weeks. c) after two weeks if there is more than one credible nomination, somehow it will be decided who get's this plum job. Robert Ramey
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/19/2012 12:26 PM, Robert Ramey wrote:
Steven Watanabe wrote:
AMDG
On 07/19/2012 02:06 AM, Paul A. Bristow wrote:
At present is it nobody's job (or everyone's job?) and the result is not really good enough.
So if someone (or two) is willing to take on the task, and we have reasonable confidence in them, we should 'appoint' them (and 'sack' them if it goes badly). At least we can revert to some previous known-ok-ish state.
Who is "we?" Someone still has to take responsibility for making these decisions, which brings us back to the original problem. ... The current problem is that no one is in charge. The solution is to find someone who want's to be responsable for the maintainence. ...
Note that this in no way precludes contributions of effort by many others - that's what the trac system is for and it works very well in my opinion. But this requires a "gatekeeper" which is missing now.
In short - the system is fine - just find a new "gatekeeper"
This is the Boost.Guild concept <http://jc-bell.com/contributions/boost-guild> "Boost.Guild's showstopper is in finding maintainers..."
On Fri, Jul 20, 2012 at 3:53 PM, Jim Bell <Jim@jc-bell.com> wrote:
This is the Boost.Guild concept <http://jc-bell.com/contributions/boost-guild>
"Boost.Guild's showstopper is in finding maintainers..."
So basically in 2 years no progress was made? -- Olaf
On Thu, Jul 19, 2012 at 7:20 AM, Robert Ramey <ramey@rrsd.com> wrote:
one person is plenty if he keeps the work up to date.
That's a big if. And that one person certainly won't maintain the lib forever.
I think a lot of people would be willing to help out.
I think lots of people would be happy to apply their own patches. But they solve their own problems and don't think of the situation as a whole.
It's not about giving commit access to the world.
I think this is a great idea. We need to make it easier for user patches to be applied.
maybe the best in this case would be to get date.time accepted into the standard - then we can just let the vendors deal with it.
It's not (just) about date time. -- Olaf
on Sat Jun 30 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Fri, Jun 29, 2012 at 12:02 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I was surprised too, almost a year ago, that there have been no reaction - not even a reply - to a date_time bug I reported on this mailing list ( https://svn.boost.org/trac/boost/ticket/5753).
Boost does not appear to have a policy for maintainers that go missing in action. I think someone (maybe steering committe) should come up with some policy.
Please send a policy proposal to boost-steering@googlegroups.com and the committee will consider it. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
participants (11)
-
Dave Abrahams -
Jim Bell -
Klaim - Joël Lamotte -
Nathan Ridge -
Olaf van der Spek -
Paul A. Bristow -
Philippe Vaucher -
Robert Ramey -
Roland Bock -
Steven Watanabe -
Stewart, Robert