Dave asked for a policy proposal for how Boost library maintenance rights may be transferred. Edward Diener declined, so I'll offer one and go a little further while I'm at it. Consider the following as a replacement for the text at <http://www.boost.org/community/reviews.html#Maintainer>. _____________________________ Library Author's Responsibilities By submitting a library to Boost, you agree to put the library and its documentation under a Boost-compatible license, if it is accepted. If your library is accepted, you are free to change it any way you wish. Indeed, we encourage you to make constant improvements. However, because peer review is an important part of the Boost process, please consider getting Boost community feedback before making substantial changes to the interface of your library. Furthermore, if your library is accepted, you agree to be the library maintainer or to find a qualified volunteer to serve in your stead. You may, of course, assemble a qualified group to act as maintainers of your library, regardless of whether you continue to be a maintainer. Library Maintainer's Rights and Responsibilities As a library maintainer, you agree to provide timely support to users of the library, and to fix bugs and release those fixes in a timely fashion. You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for approval and is not rejected by anyone within a reasonable time. If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement. If for some reason you fail to fulfill your responsibilities as maintainer of a library, as judged by the Boost community, whether through willful neglect or otherwise, you agree to allow the Boost community to provide a suitable replacement. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
Thanks for dealing with this. A couple of comments below. On 25 March 2010 12:14, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Consider the following as a replacement for the text at <http://www.boost.org/community/reviews.html#Maintainer>.
I think we should move it, since this is important after the library is accepted. I'd put it in: http://www.boost.org/development/requirements.html Which is going to be moved to: https://svn.boost.org/trac/boost/wiki/Guidelines/Requirements
Indeed, we encourage you to make constant improvements.
I'm not sure about this. I think some parts of boost should try to reach a stable state. Daniel
Daniel James wrote:
On 25 March 2010 12:14, Stewart, Robert
Indeed, we encourage you to make constant improvements.
I'm not sure about this. I think some parts of boost should try to reach a stable state.
That's a good point. How about this: "Indeed, we encourage you to make improvements, at least until the library reaches a proven level of maturity. At that point, changes may be less helpful to the user community and might be better put into a new library that would coexist with the original, if accepted." _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
Hi Rob, thanks for going on this subject. Rob Stewart wrote:
Dave asked for a policy proposal for how Boost library maintenance rights may be transferred. Edward Diener declined, so I'll offer one and go a little further while I'm at it. Consider the following as a replacement for the text at <http://www.boost.org/community/reviews.html#Maintainer>.
_____________________________
Library Author's Responsibilities
By submitting a library to Boost, you agree to put the library and its documentation under a Boost-compatible license, if it is accepted.
If your library is accepted, you are free to change it any way you wish. Indeed, we encourage you to make constant improvements. However, because peer review is an important part of the Boost process, please consider getting Boost community feedback before making substantial changes to the interface of your library.
Furthermore, if your library is accepted, you agree to be the library maintainer or to find a qualified volunteer to serve in your stead. You may, of course, assemble a qualified group to act as maintainers of your library, regardless of whether you continue to be a maintainer.
Library Maintainer's Rights and Responsibilities
As a library maintainer, you agree to provide timely support to users of the library, and to fix bugs and release those fixes in a timely fashion.
What about been less subjective? what do you think about constraining the maintainer to take care of a bug before 6 months? Rob Stewart wrote:
You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for approval and is not rejected by anyone within a reasonable time.
What about been less subjective? what do you think about limiting this time to 1 month? Rob Stewart wrote:
If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement. If for some reason you fail to fulfill your responsibilities as maintainer of a library, as judged by the Boost community, whether through willful neglect or otherwise, you agree to allow the Boost community to provide a suitable replacement.
I would add that if the library has too many BUGS, the library maintainer should make a request for a qualified group to help to maintain the library. IMO a library with more than 40 BUGS should reinforce the maintenance team. Best, Vicente -- View this message in context: http://old.nabble.com/Transfer-of-Maintenance-Rights-tp28028010p28029857.htm... Sent from the Boost - Dev mailing list archive at Nabble.com.
Library Maintainer's Rights and Responsibilities
As a library maintainer, you agree to provide timely support to users of the library, and to fix bugs and release those fixes in a timely fashion.
What about been less subjective? what do you think about constraining the maintainer to take care of a bug before 6 months?
I agree with some sort of deadline, but what if a maintainer fixes some bugs but not all of them? Also, does this only apply to actual bugs, or feature requests? There are also some bugs in BGL that apply to interfaces (such as the one to LEDA) that are no longer maintained. Does the maintainer have discretion on what bugs to consider important (if they do reply and say something is a low priority)? One other thing I would like to see as part of "timely support" is checking the regression test results and fixing issues found there. BGL has several tests that fail because of build problems in other libraries; I know that these should be reported but checking the regression test pages would also be good as a requirement. I know many of these tests fail due to compiler deficiencies and issues in the test systems' configurations, however.
Rob Stewart wrote:
You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for approval and is not rejected by anyone within a reasonable time.
What about been less subjective? what do you think about limiting this time to 1 month?
I agree with this. I think submitting a patch to a bug report or feature request should count as well. -- Jeremiah Willcock
Jeremiah Willcock wrote:
Rob Stewart wrote:
I agree with some sort of deadline, but what if a maintainer fixes some bugs but not all of them? Also, does this only apply to actual bugs, or feature requests? There are also some bugs in BGL that apply to interfaces (such as the one to LEDA) that are no longer maintained. Does the maintainer have discretion on what bugs to consider important (if they do reply and say something is a low priority)?
See if my recent reply to Vicente addresses your concern.
One other thing I would like to see as part of "timely support" is checking the regression test results and fixing issues found there. BGL has several tests that fail because of build problems in other libraries; I know that these should be reported but checking the regression test pages would also be good as a requirement. I know many of these tests fail due to compiler deficiencies and issues in the test systems' configurations, however.
Ditto.
Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for approval and is not rejected by anyone within a reasonable time.
What about been less subjective? what do you think about limiting this time to 1 month?
I agree with this. I think submitting a patch to a bug report or feature request should count as well.
I included a two week minimum in my rewrite. See if you like the result. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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 Thu, 25 Mar 2010, Stewart, Robert wrote:
Jeremiah Willcock wrote:
Rob Stewart wrote:
I agree with some sort of deadline, but what if a maintainer fixes some bugs but not all of them? Also, does this only apply to actual bugs, or feature requests? There are also some bugs in BGL that apply to interfaces (such as the one to LEDA) that are no longer maintained. Does the maintainer have discretion on what bugs to consider important (if they do reply and say something is a low priority)?
See if my recent reply to Vicente addresses your concern.
It does somewhat -- there are BGL bugs that are kept open (because they are legitimate problems) that have too low of a priority to work on actively. If a user submits a patch for them and can test it they will be fixed. On the later things in your reply to me, I do like the new rewrite. -- Jeremiah Willcock
Jeremiah Willcock wrote:
On Thu, 25 Mar 2010, Stewart, Robert wrote:
See if my recent reply to Vicente addresses your concern.
It does somewhat -- there are BGL bugs that are kept open (because they are legitimate problems) that have too low of a priority to work on actively. If a user submits a patch for them and can test it they will be fixed. On the later things in your reply to me, I do like the new rewrite.
Is there a "deferred" state for bugs? We could explicitly ignore those in the minimum time to handle statement. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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 Thu, 25 Mar 2010, Stewart, Robert wrote:
Jeremiah Willcock wrote:
On Thu, 25 Mar 2010, Stewart, Robert wrote:
See if my recent reply to Vicente addresses your concern.
It does somewhat -- there are BGL bugs that are kept open (because they are legitimate problems) that have too low of a priority to work on actively. If a user submits a patch for them and can test it they will be fixed. On the later things in your reply to me, I do like the new rewrite.
Is there a "deferred" state for bugs? We could explicitly ignore those in the minimum time to handle statement.
I do not see one, but I believe the administrator can add it as a resolution. There is a setting of "To Be Determined" as a milestone, while is somewhat like "deferred", though. -- Jeremiah Willcock
Jeremiah Willcock wrote:
On Thu, 25 Mar 2010, Stewart, Robert wrote:
Jeremiah Willcock wrote:
there are BGL bugs that are kept open (because they are legitimate problems) that have too low of a priority to work on actively. If a user submits a patch for them and can test it they will be fixed. On the later things in your reply to me, I do like the new rewrite.
Is there a "deferred" state for bugs? We could explicitly ignore those in the minimum time to handle statement.
I do not see one, but I believe the administrator can add it as a resolution. There is a setting of "To Be Determined" as a milestone, while is somewhat like "deferred", though.
Hmmm, how about the phrase, "active bugs," like the following? _____________________________________ As a library maintainer, you agree to provide timely support to users of the library, to note and fix regression test failures, to fix bugs and release those fixes in a timely fashion, and not allow any active bugs to languish for longer than a year. You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for verification for at least two weeks and is not rejected by anyone. That gives the maintainer and interested users a reasonable chance to notice and reject the patch. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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 Thu, 25 Mar 2010, Stewart, Robert wrote:
Jeremiah Willcock wrote:
On Thu, 25 Mar 2010, Stewart, Robert wrote:
Jeremiah Willcock wrote:
there are BGL bugs that are kept open (because they are legitimate problems) that have too low of a priority to work on actively. If a user submits a patch for them and can test it they will be fixed. On the later things in your reply to me, I do like the new rewrite.
Is there a "deferred" state for bugs? We could explicitly ignore those in the minimum time to handle statement.
I do not see one, but I believe the administrator can add it as a resolution. There is a setting of "To Be Determined" as a milestone, while is somewhat like "deferred", though.
Hmmm, how about the phrase, "active bugs," like the following?
That term is fine; do you want any sort of explicit definition of what bugs count as active? -- Jeremiah Willcock
----- Original Message ----- From: "Jeremiah Willcock" <jewillco@osl.iu.edu> To: <boost@lists.boost.org> Sent: Thursday, March 25, 2010 6:11 PM Subject: Re: [boost] Transfer of Maintenance Rights
On Thu, 25 Mar 2010, Stewart, Robert wrote:
Hmmm, how about the phrase, "active bugs," like the following?
That term is fine; do you want any sort of explicit definition of what bugs count as active?
Sometime ago I proposed to change the tickets states so it is clear if the ticket is on the hands of the maintainer or on the hands of the requester. I could try to find it if someone is interested. I think that the tickets we are interested are the tickets that are on the hands of the maintainer. We could accept a different delay depending on the ticket severity, on whether it is a feature request, ... Best, Vicente
vicente.botet wrote:
From: "Jeremiah Willcock" <jewillco@osl.iu.edu>
On Thu, 25 Mar 2010, Stewart, Robert wrote:
Hmmm, how about the phrase, "active bugs," like the following?
That term is fine; do you want any sort of explicit definition of what bugs count as active?
I think that the tickets we are interested are the tickets that are on the hands of the maintainer. We could accept a different delay depending on the ticket severity, on whether it is a feature request, ...
I don't quite agree. If a maintainer doesn't even examine new tickets, then that's a problem, so the tickets just issued or being updated by requesters are also important. As to whether there should be a different delay allowed based upon severity, feature request, etc., I certainly didn't want to get into that level of detail. Instead, I was looking to keep the phrasing sufficiently vague to leave wiggle room based upon community perception and maintainer response when the community complains. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, March 26, 2010 12:33 PM Subject: Re: [boost] Transfer of Maintenance Rights
vicente.botet wrote:
From: "Jeremiah Willcock" <jewillco@osl.iu.edu>
On Thu, 25 Mar 2010, Stewart, Robert wrote:
Hmmm, how about the phrase, "active bugs," like the following?
That term is fine; do you want any sort of explicit definition of what bugs count as active?
I think that the tickets we are interested are the tickets that are on the hands of the maintainer. We could accept a different delay depending on the ticket severity, on whether it is a feature request, ...
I don't quite agree. If a maintainer doesn't even examine new tickets, then that's a problem, so the tickets just issued or being updated by requesters are also important.
Just consider tha th new tickets associated to a component/library are on the hands of the library maintainer.
As to whether there should be a different delay allowed based upon severity, feature request, etc., I certainly didn't want to get into that level of detail.
I understand why you want to avoid the detail. But without this level detail we are unable to state when a library is unmaintained. Or, are we?
Instead, I was looking to keep the phrasing sufficiently vague to leave wiggle room based upon community perception and maintainer response when the community complains.
I see, but I think that we need however to set some high limits. Best, Vicente
Interesting thread. On Sun, 28 Mar 2010, vicente.botet wrote:
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com>
Instead, I was looking to keep the phrasing sufficiently vague to leave wiggle room based upon community perception and maintainer response when the community complains.
I see, but I think that we need however to set some high limits.
It is common for "parlimentary" bodies to have clauses that can be used to trigger debate. Such a technique might be good for boost. Pick lower bounds that seem reasonable for bugs, patches, etc. Maybe one month for patch resolution or bug triage, and six months for a "will do" bugfix. When a time limit is exceeded, interested users can call for new maintainership; the community can respond by telling them to wait, pestering the developer, finding a new maintainer, etc. - Daniel
dherring@ll.mit.edu wrote:
On Sun, 28 Mar 2010, vicente.botet wrote:
From: "Stewart, Robert" <Robert.Stewart@sig.com>
Instead, I was looking to keep the phrasing sufficiently vague to leave wiggle room based upon community perception and maintainer response when the community complains.
I see, but I think that we need however to set some high limits.
It is common for "parlimentary" bodies to have clauses that can be used to trigger debate. Such a technique might be good for boost.
That's an interesting approach.
Pick lower bounds that seem reasonable for bugs, patches, etc. Maybe one month for patch resolution or bug triage, and six months for a "will do" bugfix. When a time limit is exceeded, interested users can call for new maintainership; the community can respond by telling them to wait, pestering the developer, finding a new maintainer, etc.
I'll see what I can do with the text. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
Gottlob Frege wrote:
I understand why you want to avoid the detail. But without this level detail we are unable to state when a library is unmaintained. Or, are we?
Create a ticket that says 'this library in unmaintained'. If it doesn't get looked at it must be true. :-)
+1
----- Original Message ----- From: "Gottlob Frege" <gottlobfrege@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, April 01, 2010 12:56 AM Subject: Re: [boost] Transfer of Maintenance Rights
I understand why you want to avoid the detail. But without this level detail we are unable to state when a library is unmaintained. Or, are we?
Create a ticket that says 'this library in unmaintained'. If it doesn't get looked at it must be true. :-)
Excelent idea. And what will we do when we see that the library is unmaintained? I would like we setup something to avoid to reach such a situation. Something that help us to prevent instead of attend. I support deeply the idea to extend the maintenance to a group. Best, Vicente
I like the main thrust of this proposal, but there was one point of discussion I wanted to jump in on. On Mar 25, 2010, at 11:54 AM, Stewart, Robert wrote:
Is there a "deferred" state for bugs? We could explicitly ignore those in the minimum time to handle statement.
Even if there were, depending on what its semantics are within the bug tracking system I might suggest avoiding it. My group made an explicit decision to never use bugzilla's "Resolve / Remind" and "Resolve / Later" states, because these indicate that the bug is "resolved" when in fact it isn't, just de-prioritized. Instead we have milestones such as "future" or "backlog" for issues which we have not yet scheduled to be worked on.
Vicente Botet Escriba
Rob Stewart wrote:
Library Maintainer's Rights and Responsibilities
As a library maintainer, you agree to provide timely support to users of the library, and to fix bugs and release those fixes in a timely fashion.
What about been less subjective? what do you think about constraining the maintainer to take care of a bug before 6 months?
I didn't want to specify a time because I figured there would be arguments about what is long enough. That's also why I suggested that the Boost community would determine the time to transfer maintenance due to inactivity. The timeliness of maintenance activities could be addressed on a case by case basis.
Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for approval and is not rejected by anyone within a reasonable time.
What about been less subjective? what do you think about limiting this time to 1 month?
I thought about specifying a time for this because there really should be a minimum time to give enough people a chance to notice the submitted patch. By the same token, if there isn't a maximum time limit, then the patch submitter will be uncomfortable moving forward. There will still be some argument about the times, but that's probably worthwhile.
I would add that if the library has too many BUGS, the library maintainer should make a request for a qualified group to help to maintain the library. IMO a library with more than 40 BUGS should reinforce the maintenance team.
I wouldn't want to give a number of bugs, because it should be based upon their severity and the platforms to which they apply, and I think it is important that no bug be allowed to languish in perpetuity. Perhaps the following version would do? _____________________________ As a library maintainer, you agree to provide timely support to users of the library, to note and fix regression test failures, to fix bugs and release those fixes in a timely fashion, and not allow any bugs to languish for longer than a year. You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for verification for at least two weeks and is not rejected by anyone. That gives the maintainer and interested users a reasonable chance to notice and reject the patch. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
Stewart, Robert wrote:
I would add that if the library has too many BUGS, the library maintainer should make a request for a qualified group to help to maintain the library. IMO a library with more than 40 BUGS should reinforce the maintenance team.
I wouldn't want to give a number of bugs, because it should be based upon their severity and the platforms to which they apply, and I think it is important that no bug be allowed to languish in perpetuity.
Does closing bugs as "wontfix" counts as "not languishing in perpetuity"? - Volodya
Vladimir Prus wrote:
Does closing bugs as "wontfix" counts as "not languishing in perpetuity"?
Yes. It would also not fit into the "active bugs" category in my latest version of the text. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
Stewart, Robert wrote:
Library Author's Responsibilities
By submitting a library to Boost, you agree to put the library and its documentation under a Boost-compatible license, if it is accepted.
I know this isn't the main thrust of this discussion, but I just wanted to point out that submissions really ought to be under the Boost license (and I guess not just 'a Boost-compatible license') when they are submitted, not when they are accepted. As far as I recall this has been what has happened in the past.
we encourage you to make constant improvements.
As someone else has pointed out, sometimes code can actually be declared "finished"! Regards, Phil.
Phil Endecott wrote:
Stewart, Robert wrote:
By submitting a library to Boost, you agree to put the library and its documentation under a Boost-compatible license, if it is accepted.
I just wanted to point out that submissions really ought to be under the Boost license (and I guess not just 'a Boost-compatible license') when they
I'm not sure it is required that they use the Boost License, though perhaps we could phrase that as, "By submitting a library to Boost, you agree to put the library and its documentation under the Boost License, at least, if it is accepted."
are submitted, not when they are accepted. As far as I recall this has been what has happened in the past.
I wasn't sure I could say that. What is an author to do if their library is rejected and they want to put it under a different license later? Can they really rescind the freedom of the Boost License and replace it with another? My guess is no.
we encourage you to make constant improvements.
As someone else has pointed out, sometimes code can actually be declared "finished"!
I addressed that in another reply in this thread. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
Stewart, Robert wrote:
Phil Endecott wrote:
Stewart, Robert wrote:
By submitting a library to Boost, you agree to put the library and its documentation under a Boost-compatible license, if it is accepted.
I just wanted to point out that submissions really ought to be under the Boost license (and I guess not just 'a Boost-compatible license') when they
I'm not sure it is required that they use the Boost License, though perhaps we could phrase that as, "By submitting a library to Boost, you agree to put the library and its documentation under the Boost License, at least, if it is accepted."
are submitted, not when they are accepted. As far as I recall this has been what has happened in the past.
I wasn't sure I could say that. What is an author to do if their library is rejected and they want to put it under a different license later? Can they really rescind the freedom of the Boost License and replace it with another? My guess is no.
They can publish new versions under a different license, or under multiple licenses, and this doesn't retroactively change the terms of their boost-candidate submission. We don't want to be in a position where a negative review result means that existing users of a candidate library have to stop using it. Or that the review manager feels pressured into accepting a borderline library because rejecting it would mean it could no longer be used by a minority of reviewers who did like it. Personally, "my lawyer" wouldn't want me to even look at code (e.g. for review) if it didn't already have a clear and liberal license. Phil.
On 25 March 2010 07:14, Stewart, Robert <Robert.Stewart@sig.com> wrote:
If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement.
I don't see why we need this. If the author has already abandoned the library, I just don't see them suddenly coming back and spending energy to find their replacement. So, exactly how many libraries (and which ones) are currently abandoned? How widespread of a problem is this? -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote:
On 25 March 2010 07:14, Stewart, Robert <Robert.Stewart@sig.com> wrote:
If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement.
I don't see why we need this. If the author has already abandoned the library, I just don't see them suddenly coming back and spending energy to find their replacement.
That part is addressed to maintainers that haven't actually abandoned their library yet but know they must do so. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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 25 March 2010 13:26, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Nevin Liber wrote:
On 25 March 2010 07:14, Stewart, Robert <Robert.Stewart@sig.com> wrote:
If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement.
I don't see why we need this. If the author has already abandoned the library, I just don't see them suddenly coming back and spending energy to find their replacement.
That part is addressed to maintainers that haven't actually abandoned their library yet but know they must do so.
Which libraries are in the state of no maintainer and how serious are their bug lists at this moment? I follow the boost lists on an every day basis, both for personal interest, and because I maintain, patch and upgrade the boost package in our production code base (it's a good way to find issues that I might need to be aware of). I have not had any problems with abandoned libraries, and we use about half of the amount of libs listed ( http://www.boost.org/doc/libs/1_42_0/libs/libraries.htm). I think a summary of abandoned libs would be good start. Or is there one already?
On 25 March 2010 15:30, Christian Holmquist <c.holmquist@gmail.com> wrote:
Which libraries are in the state of no maintainer and how serious are their bug lists at this moment?
Given that no one seems to be answering this, I'm getting the feeling that we are trying to address a non-problem... -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 26 March 2010 10:05, Rutger ter Borg <rutger@terborg.net> wrote:
Christian Holmquist wrote:
Which libraries are in the state of no maintainer and how serious are their bug lists at this moment?
I guess there's a difference between "no maintainer" and "unmaintained"/"needs more attention".
Cheers,
Rutger
Nit pickings aside, what is the immediate problem? This whole thread seems very theoretical to me. A lot of energy put into it from many people, that maybe could be used to improve the current state of affairs instead (i.e. by fixing bugs in abandoned libs)? / Christian
On 26 Mar 2010, at 20:17, Christian Holmquist wrote:
On 26 March 2010 10:05, Rutger ter Borg <rutger@terborg.net> wrote:
Christian Holmquist wrote:
Which libraries are in the state of no maintainer and how serious are their bug lists at this moment?
I guess there's a difference between "no maintainer" and "unmaintained"/"needs more attention".
Cheers,
Rutger
Nit pickings aside, what is the immediate problem? This whole thread seems very theoretical to me. A lot of energy put into it from many people, that maybe could be used to improve the current state of affairs instead (i.e. by fixing bugs in abandoned libs)?
Can I just get a svn account, and start applying fixes to bugs in any libs I deem to be abandoned? Chris
Christian Holmquist wrote:
On 26 March 2010 10:05, Rutger ter Borg <rutger@terborg.net> wrote:
Christian Holmquist wrote:
Which libraries are in the state of no maintainer and how serious are their bug lists at this moment? I guess there's a difference between "no maintainer" and "unmaintained"/"needs more attention".
Cheers,
Rutger
Nit pickings aside, what is the immediate problem? This whole thread seems very theoretical to me. A lot of energy put into it from many people, that maybe could be used to improve the current state of affairs instead (i.e. by fixing bugs in abandoned libs)?
I think the immediate problem is this report of number of open tickets per component: https://svn.boost.org/trac/boost/report/19 Some of those issues are surely bugs that happen only on VAX machines, or misuses of library, or features only submitter wants, but when a library has 70, or 50, or 40 it still sounds too much. - Volodya
On 3/27/2010 3:38 AM, Vladimir Prus wrote:
Christian Holmquist wrote:
On 26 March 2010 10:05, Rutger ter Borg <rutger@terborg.net> wrote:
Christian Holmquist wrote:
Which libraries are in the state of no maintainer and how serious are their bug lists at this moment? I guess there's a difference between "no maintainer" and "unmaintained"/"needs more attention".
Cheers,
Rutger
Nit pickings aside, what is the immediate problem? This whole thread seems very theoretical to me. A lot of energy put into it from many people, that maybe could be used to improve the current state of affairs instead (i.e. by fixing bugs in abandoned libs)?
I think the immediate problem is this report of number of open tickets per component:
https://svn.boost.org/trac/boost/report/19
Some of those issues are surely bugs that happen only on VAX machines, or misuses of library, or features only submitter wants, but when a library has 70, or 50, or 40 it still sounds too much.
There does seem, from this end-user's perspective, some libraries where the original developer does not seem to be working on it anymore, whether to fix bugs, update docs, or possibly to make changes. This is quite understandable if a library does not need changes aside from the very occasional bug, which is probably the case with many libraries. I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong: iostreams date_time tokenizer random value_init variant pool format array Again let me reiterate that I am neither trying to create work for Boost developers nor in any way trying to put down anyone. My earlier post about maintenance of Boost libraries, which Robert Stewart happily turned into specifics, was just an attempt to suggest that when a Boost library has no one maintaining it anymore it would probably be easier to try to find someone else to maintain it than rely in a series of individuals trying to understand it and make changes to it. I wrote that because from my perspective it takes much effort to really understand library code for a Boost library, and it is better to have one ( or possibly a few ) maintainers of a library who invest the time to understand it thoroughly rather than a number of people who may understand only small parts and attempt to fix problems or make changes.
On Mar 27, 2010, at 7:52 AM, Edward Diener wrote:
There does seem, from this end-user's perspective, some libraries where the original developer does not seem to be working on it anymore, whether to fix bugs, update docs, or possibly to make changes. This is quite understandable if a library does not need changes aside from the very occasional bug, which is probably the case with many libraries. I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong:
iostreams date_time tokenizer random value_init variant pool format array
This is great - actual data ;-) I've been away for a couple of days, and catching up on this thread, I'm getting there's a lot of sound and fury about unmaintained libraries, but no hard facts. https://svn.boost.org/trac/boost/report/15 shows the following libraries with no assigned maintainer: array functional lambda preprocessor random utility As for the ones that you've listed: Chris Newbold has recently taken over maintenance of the pool library Steven Watanabe and I have been fixing problems in the array library. Steven Watanable is currently working on the random library. Andysem has been fixing date_time bugs recently. Danieljames has been fixing iostreams bugs Variant, I agree, is in need of a maintainer. Does someone want to volunteer? -- Marshall P.S. I too see the large list of open tickets as (at the very least) a bit of "Bad PR" by boost. I think that we (as a group) should be more proactive about dealing with tickets/fixing bugs/responding to feature requests (even if the answer is 'No, that's not going to happen'/etc. The first "bug sprint" closed about 100 tickets, the second noticeably less. Now there are more open tickets than ever. P.P.S. The fact that there are 90 patches waiting to be looked at/applied is really too bad. <https://svn.boost.org/trac/boost/report/25> <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&group=component&order=priority&col=id&col=summary&col=status&col=type&col=milestone&col=component&type=Patches&row=description>
Marshall Clow wrote:
On Mar 27, 2010, at 7:52 AM, Edward Diener wrote: https://svn.boost.org/trac/boost/report/15 shows the following libraries with no assigned maintainer:
array functional lambda preprocessor random utility
Hm, I've always wanted to clean up the utility library :-\ But isn't utility special? In the sense that it has multiple open ended authors? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Sat, 2010-03-27 at 14:14 -0700, Marshall Clow wrote:
On Mar 27, 2010, at 7:52 AM, Edward Diener wrote:
There does seem, from this end-user's perspective, some libraries where the original developer does not seem to be working on it anymore, whether to fix bugs, update docs, or possibly to make changes. This is quite understandable if a library does not need changes aside from the very occasional bug, which is probably the case with many libraries. I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong:
There is at least some perception that Boost.Python is somewhat unmaintained, even though its authors are still very active in boost development in general - a project I'm working with cited the "lack of active development" in Boost.Python as a major reason they chose to use SWIG instead (and I think that's a terrible shame, because I personally like the Boost.Python approach better). Jim Bosch
On 27 March 2010 21:14, Marshall Clow <mclow.lists@gmail.com> wrote:
Danieljames has been fixing iostreams bugs
I've been mostly accepting patches. Although sometimes that takes longer than you'd expect as I'm not very familiar with the library or the APIs that it uses. It really needs a proper maintainer who can devote more time to it. Daniel
iostreams date_time tokenizer random value_init variant pool format array
This is great - actual data ;-) I've been away for a couple of days, and catching up on this thread, I'm getting there's a lot of sound and fury about unmaintained libraries, but no hard facts.
You can add integer to the list as well - yes I know I patched it up a bit recently - but that's just a stop gap till someone else volunteers to look after it properly :-) John.
Edward Diener wrote:
I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong: ... value_init
As far as I know, Fernando Cacciola, the original developer of utility/value_init, is still around. I've been doing some maintenance to value_init as well, reviewed by Fernando. And I'm still busy fixing "Unconditional call to memset in value_initialized()" <https://svn.boost.org/trac/boost/ticket/3869>. Unfortunately I haven't got enough time to finalize the fix this month, sorry! I hope to do so before the end of April. We still need to have a decision about your "Setting value_initialized<T> to a value when T is a top-level const" <https://svn.boost.org/trac/boost/ticket/3472>. You know, I wasn't entirely sure about your proposed fix, so I proposed a slightly different fix. I still hope Fernando can make a choice between the two. HTH, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
On 3/27/2010 7:20 PM, Niels Dekker - address until 2010-10-10 wrote:
Edward Diener wrote:
I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong: ... value_init
As far as I know, Fernando Cacciola, the original developer of utility/value_init, is still around. I've been doing some maintenance to value_init as well, reviewed by Fernando. And I'm still busy fixing "Unconditional call to memset in value_initialized()" <https://svn.boost.org/trac/boost/ticket/3869>. Unfortunately I haven't got enough time to finalize the fix this month, sorry! I hope to do so before the end of April.
I am aware that you have taken over some of the work on it from Fernando.
We still need to have a decision about your "Setting value_initialized<T> to a value when T is a top-level const" <https://svn.boost.org/trac/boost/ticket/3472>. You know, I wasn't entirely sure about your proposed fix, so I proposed a slightly different fix. I still hope Fernando can make a choice between the two.
I never heard back from Fernando about this so I assumed he was no longer active as a maintainer of his library. My suggested fix is so simple that it is hard for me to understand why it should take so long for a decision to be made on it unless he was no longer involved.
Hi Edward,
On 3/27/2010 7:20 PM, Niels Dekker - address until 2010-10-10 wrote:
Edward Diener wrote:
I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong: ... value_init
As far as I know, Fernando Cacciola, the original developer of utility/value_init, is still around. I've been doing some maintenance to value_init as well, reviewed by Fernando. And I'm still busy fixing "Unconditional call to memset in value_initialized()" <https://svn.boost.org/trac/boost/ticket/3869>. Unfortunately I haven't got enough time to finalize the fix this month, sorry! I hope to do so before the end of April.
I am aware that you have taken over some of the work on it from Fernando.
We still need to have a decision about your "Setting value_initialized<T> to a value when T is a top-level const" <https://svn.boost.org/trac/boost/ticket/3472>. You know, I wasn't entirely sure about your proposed fix, so I proposed a slightly different fix. I still hope Fernando can make a choice between the two.
I never heard back from Fernando about this so I assumed he was no longer active as a maintainer of his library.
I guess you can say that, though is not I'm intentionally out of the loop. I just never have the time.
My suggested fix is so simple that it is hard for me to understand why it should take so long for a decision to be made on it unless he was no longer involved.
Actually, your fix is NOT so simple, not conceptually. That's why Niels proposed something else. Anyway a decision needs to be made and if I won't do it on time (for whatever reason), someone else must be given the mantaince rights. Having said that, I'll make a decision in the next few days. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
On 3/29/2010 10:54 AM, Fernando Cacciola wrote:
Hi Edward,
On 3/27/2010 7:20 PM, Niels Dekker - address until 2010-10-10 wrote:
Edward Diener wrote:
I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong: ... value_init
As far as I know, Fernando Cacciola, the original developer of utility/value_init, is still around. I've been doing some maintenance to value_init as well, reviewed by Fernando. And I'm still busy fixing "Unconditional call to memset in value_initialized()" <https://svn.boost.org/trac/boost/ticket/3869>. Unfortunately I haven't got enough time to finalize the fix this month, sorry! I hope to do so before the end of April.
I am aware that you have taken over some of the work on it from Fernando.
We still need to have a decision about your "Setting value_initialized<T> to a value when T is a top-level const" <https://svn.boost.org/trac/boost/ticket/3472>. You know, I wasn't entirely sure about your proposed fix, so I proposed a slightly different fix. I still hope Fernando can make a choice between the two.
I never heard back from Fernando about this so I assumed he was no longer active as a maintainer of his library.
I guess you can say that, though is not I'm intentionally out of the loop. I just never have the time.
My suggested fix is so simple that it is hard for me to understand why it should take so long for a decision to be made on it unless he was no longer involved.
Actually, your fix is NOT so simple, not conceptually.
I understand that, but I did mean syntax-wise. But clearly, as my argument shows, value_init can not be used in any situation in which an object including a value_init value is declared as a const object unless you allow the value initialized value to be initialized to something other than its value-initialized default upon construction ( which is my fix ). And since a developer can hardly control how an end-user uses his object, whether as const or non-const, essentially you are telling any developer that value_init is useless to him unless he enforces the fact that his own object which has a value_init value is never const, which in my opinion makes its practical usage much, much less than it conceptually could be. How many developers do you think want to restrict their own objects to non-const ? But currently value_init is practically useless to them unless they do. Which is fine if you want it that way, but clearly developers wanting a value_init value for a potentially const object will not use it and just revert back to a default constructed object which may be constructed based on an alternative constructor. Which is a shame because value initialization as you have conceived and coded it is much clearer and safer to use.
That's why Niels proposed something else. Anyway a decision needs to be made and if I won't do it on time (for whatever reason), someone else must be given the mantaince rights. Having said that, I'll make a decision in the next few days.
It is appreciated.
Edward Diener wrote about https://svn.boost.org/trac/boost/ticket/3472
My suggested fix is so simple that it is hard for me to understand why it should take so long for a decision to be made on it unless he was no longer involved.
Fernando Cacciola wrote:
Actually, your fix is NOT so simple, not conceptually.
Edward replied:
I understand that, but I did mean syntax-wise.
But clearly, as my argument shows, value_init can not be used in any situation in which an object including a value_init value is declared as a const object unless you allow the value initialized value to be initialized to something other than its value-initialized default upon construction ( which is my fix ). And since a developer can hardly control how an end-user uses his object, whether as const or non-const, essentially you are telling any developer that value_init is useless to him unless he enforces the fact that his own object which has a value_init value is never const, which in my opinion makes its practical usage much, much less than it conceptually could be.
How many developers do you think want to restrict their own objects to non-const ? But currently value_init is practically useless to them unless they do. Which is fine if you want it that way, but clearly developers wanting a value_init value for a potentially const object will not use it and just revert back to a default constructed object which may be constructed based on an alternative constructor. Which is a shame because value initialization as you have conceived and coded it is much clearer and safer to use.
Edward, you know I agree that it would be useful to have an extra value_inititialized<T> constructor to allow direct-initialization of the wrapped T object. It's just that I'm not entirely sure if it's a good idea to declare it as value_initialized(T const&). I think it would be a bit safer to add an extra "tag" parameter, to clarify that the constructed object is direct-initialized, instead of value-initialized: struct direct_initialized_t { }; value_initialized(T const&, direct_initialized_t). I know you prefer your own proposed constructor, value_initialized(T const &), but does that mean that you're /opposed/ to having value_initialized(T const&, direct_initialized_t) instead? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
On 3/29/2010 4:14 PM, Niels Dekker - address until 2010-10-10 wrote:
Edward Diener wrote about https://svn.boost.org/trac/boost/ticket/3472
My suggested fix is so simple that it is hard for me to understand why it should take so long for a decision to be made on it unless he was no longer involved.
Fernando Cacciola wrote:
Actually, your fix is NOT so simple, not conceptually.
Edward replied:
I understand that, but I did mean syntax-wise.
But clearly, as my argument shows, value_init can not be used in any situation in which an object including a value_init value is declared as a const object unless you allow the value initialized value to be initialized to something other than its value-initialized default upon construction ( which is my fix ). And since a developer can hardly control how an end-user uses his object, whether as const or non-const, essentially you are telling any developer that value_init is useless to him unless he enforces the fact that his own object which has a value_init value is never const, which in my opinion makes its practical usage much, much less than it conceptually could be.
How many developers do you think want to restrict their own objects to non-const ? But currently value_init is practically useless to them unless they do. Which is fine if you want it that way, but clearly developers wanting a value_init value for a potentially const object will not use it and just revert back to a default constructed object which may be constructed based on an alternative constructor. Which is a shame because value initialization as you have conceived and coded it is much clearer and safer to use.
Edward, you know I agree that it would be useful to have an extra value_inititialized<T> constructor to allow direct-initialization of the wrapped T object. It's just that I'm not entirely sure if it's a good idea to declare it as value_initialized(T const&).
I think it would be a bit safer to add an extra "tag" parameter, to clarify that the constructed object is direct-initialized, instead of value-initialized:
struct direct_initialized_t { };
value_initialized(T const&, direct_initialized_t).
I know you prefer your own proposed constructor, value_initialized(T const &), but does that mean that you're /opposed/ to having value_initialized(T const&, direct_initialized_t) instead?
I do not understand what the extra parameter specifying direct initialization is supposed to do. Making something safer implies that something else is not safe but I can not understand what is not safe with merely 'value_initialized(T const &)'. Because Microsoft, as we both know, has a bug with erroneous calling base class constructors of the type I suggested is not a reason to change code to make it 'safer'. One might as well change all code one writes with more elaborate constructs guaranteeing better 'safeness' from potential compiler bugs. But I do not believe this can ever be a way of doing programming. However if your alternative is the chosen final result, it is better IMO than no way to initialize a value_initialized with a const T value. And if Fernando rejects any way to initialize a value_initialized with its T value I will fully understand also and, as I said, just go back to using default initialization for my needs.
Stewart, Robert wrote:
If your library is accepted, you are free to change it any way you wish. Indeed, we encourage you to make constant improvements. This doesn't seem right to me. If there is a formal review and vote on inclusion then material changes should have broadly the same process.
James Mansion wrote:
Stewart, Robert wrote:
If your library is accepted, you are free to change it any way you wish. Indeed, we encourage you to make constant improvements.
This doesn't seem right to me. If there is a formal review and vote on inclusion then material changes should have broadly the same process.
That's not the way Boost does it. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
At Thu, 25 Mar 2010 08:14:20 -0400, Stewart, Robert wrote:
Dave asked for a policy proposal for how Boost library maintenance rights may be transferred. Edward Diener declined, so I'll offer one and go a little further while I'm at it. Consider the following as a replacement for the text at <http://www.boost.org/community/reviews.html#Maintainer>.
Thanks, Robert! Can you describe the difference from the existing policy and why you think yours is an improvement? -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Stewart, Robert wrote:
Dave asked for a policy proposal for how Boost library maintenance rights may be transferred. Edward Diener declined, so I'll offer one and go a little further while I'm at it. Consider the following as a replacement for the text at <http://www.boost.org/community/reviews.html#Maintainer>.
Note: I have included an updated version of my initial proposal below.
Can you describe the difference from the existing policy and why you think yours is an improvement?
My version splits the original section into two -- one for library authors and one for maintainers -- because they aren't necessarily the same person or people. My original version only required a Boost-compatible license upon acceptance. There was concern that perhaps that should be upon submission. Indeed, Phil Endecott said he wouldn't look at a candidate library otherwise. I wasn't sure I could or should specify that. I look forward to hearing from others on that point. In the meantime, I've reworded that part to indicate the need for that upon submission. My version stresses the maintainer role and indicates that the author can select a cadre of maintainers if desired. My version describes the maintainer's activities and stresses the importance of responding within a reasonable time and to not let bug reports or bug fixes languish. This is to address the state of some current libraries that have many outstanding bugs that have existed for years and of others that have changes in the trunk that have not been released. My version includes the suggested (and controversial) idea of allowing others to commit patches to a library after proposing the patch and giving others an opportunity to reject it. My version spells out more clearly what should happen when maintainers wish to abandon that role and what the Boost community can do if a maintainer simply vanishes. Here's an updated version of the proposal based upon feedback received thus far: _____________________________ Library Author's Responsibilities By submitting a library to Boost, you agree to apply the Boost License to the library and its documentation, solely or alongside other licenses you may wish to apply, if it is accepted. If your library is accepted, you are free to change it any way you wish. Indeed, we encourage you to make improvements, at least until the library reaches a proven level of maturity. At that point, changes may be less helpful to the user community and might be better put into a new library that would coexist with the original, if accepted. Note that because peer review is an important part of the Boost process, you should consider getting Boost community feedback before making substantial changes to the interface of your library. Furthermore, if your library is accepted, you agree to be the library maintainer or to find a qualified volunteer to serve in your stead. You may, of course, assemble a qualified group to act as maintainers of your library, regardless of whether you continue to be a maintainer. Library Maintainer's Rights and Responsibilities As a library maintainer, you agree to provide timely support to users of the library, to note and fix regression test failures, to fix bugs and release those fixes in a timely fashion, and not allow any active bugs to languish for longer than a year. You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for verification for at least two weeks and is not rejected by anyone. That gives the maintainer and interested users a reasonable chance to notice and reject the patch. If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement. If for some reason you fail to fulfill your responsibilities as maintainer of a library, as judged by the Boost community, whether through willful neglect or otherwise, you agree to allow the Boost community to provide a suitable replacement. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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 Fri, 2010-03-26 at 06:50 -0400, Stewart, Robert wrote:
David Abrahams wrote:
[snip]
My original version only required a Boost-compatible license upon acceptance. There was concern that perhaps that should be upon submission. Indeed, Phil Endecott said he wouldn't look at a candidate library otherwise. I wasn't sure I could or should specify that. I look forward to hearing from others on that point. In the meantime, I've reworded that part to indicate the need for that upon submission.
I would prefer to require to use the boost license upon submission. And not a Boost-compatible license. Don't we require a boost license already for acceptance? [snip]
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
Felipe Magno de Almeida
I would prefer to require to use the boost license upon submission. And not a Boost-compatible license. Don't we require a boost license already for acceptance?
The current text only calls for a Boost-compatible license and doesn't specify when it must be applied. Practice might differ from that text, of course. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.
participants (25)
-
Christian Holmquist -
Christopher Jefferson -
Daniel James -
David Abrahams -
dherring＠ll.mit.edu -
Edward Diener -
Felipe Magno de Almeida -
Fernando Cacciola -
Gottlob Frege -
James Mansion -
Jeremiah Willcock -
Jim Bosch -
John Maddock -
Kim Barrett -
Marshall Clow -
Nevin Liber -
Niels Dekker - address until 2010-10-10 -
Phil Endecott -
Rene Rivera -
Rutger ter Borg -
Stewart, Robert -
Thomas Klimpel -
Vicente Botet Escriba -
vicente.botet
-
Vladimir Prus