The Community Maintenance Team proposal accepted
The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader. See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal. Thanks to everyone who contributed ideas and discussion. I tried to capture contributors names in the Acknowledgements section of the proposal. Apologies if I missed anyone. --Beman
On Tue, Dec 17, 2013 at 6:35 AM, Beman Dawes <bdawes@acm.org> wrote:
The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader.
See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal.
Change the "...htmlfor" -> "html" to get to the page: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html
In the document itself: Change "we no long give blanket write" -> "we no longer give blanket write" Change "have also volunteer to help" -> "have also volunteered to help" Michael P.S. I'd like to volunteer for the CMT.
On Dec 17, 2013, at 8:00 AM, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
On Tue, Dec 17, 2013 at 6:35 AM, Beman Dawes <bdawes@acm.org> wrote:
The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader.
See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal.
Change the "...htmlfor" -> "html" to get to the page: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html
In the document itself:
Change "we no long give blanket write" -> "we no longer give blanket write"
Change "have also volunteer to help" -> "have also volunteered to help"
Michael
P.S. I'd like to volunteer for the CMT.
Noted - thanks! I’ll be sending out an announcement and “call for participation” in the next few days. However, here are the priorities for the CMT that I suggested to the Steering Committee: 1. Keep things building on all the supported compilers (and as many others as possible) 2. Get the test matrix “all green” and keep it that way. 3. Fix the accumulated bugs; drive the bug count to zero, and keep it there. 4. Add new features. and: * Find people who are willing to maintain the libraries themselves (and are acceptable to the authors). — Marshall
On 2013-12-17 11:32 AM, Marshall Clow wrote:
On Dec 17, 2013, at 8:00 AM, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
On Tue, Dec 17, 2013 at 6:35 AM, Beman Dawes <bdawes@acm.org> wrote:
The Steering Committee has voted to accept the Community Maintenance Team proposal... https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html
... ...
I’ll be sending out an announcement and “call for participation” in the next few days.
However, here are the priorities for the CMT that I suggested to the Steering Committee:
1. Keep things building on all the supported compilers (and as many others as possible) 2. Get the test matrix “all green” and keep it that way. 3. Fix the accumulated bugs; drive the bug count to zero, and keep it there. 4. Add new features.
and: * Find people who are willing to maintain the libraries themselves (and are acceptable to the authors).
Very glad to see this, as it seems to be an incarnation of the Boost.Guild idea from a couple years ago: http://lists.boost.org/Archives/boost/2010/11/172966.php http://jc-bell.com/contributions/boost-guild
I was reading the Review Wizard report and was wondering:
The following libraries have been accepted to Boost, but have not yet been submitted to SVN:
* Constrained Value - accepted September 2010; author: Robert Kawulak.
This library is not in the initial list of suggested libraries to be maintained by the CMT, which is normal as it is not yet part of the boost distribution. However, I wonder if such edge case would be part of the CMT mission? An accepted library is basically an almost acceptable/complete version of the library, which mean that the code under review could be enhanced with whatever requests but managed by the CMT. I'm not sure it's really the role of the CMT to "save" such orphaned too early library.
On Dec 19, 2013, at 4:19 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I was reading the Review Wizard report and was wondering:
The following libraries have been accepted to Boost, but have not yet been submitted to SVN:
* Constrained Value - accepted September 2010; author: Robert Kawulak.
This library is not in the initial list of suggested libraries to be maintained by the CMT, which is normal as it is not yet part of the boost distribution. However, I wonder if such edge case would be part of the CMT mission? An accepted library is basically an almost acceptable/complete version of the library, which mean that the code under review could be enhanced with whatever requests but managed by the CMT. I'm not sure it's really the role of the CMT to "save" such orphaned too early library.
I think that's clearly out of scope. ___ Rob (Sent from my portable computation engine)
From: Klaim - Joël Lamotte
* Constrained Value - accepted September 2010; author: Robert Kawulak.
This library is not in the initial list of suggested libraries to be maintained by the CMT, which is normal as it is not yet part of the boost distribution. However, I wonder if such edge case would be part of the CMT mission? An accepted library is basically an almost acceptable/complete version of the library, which mean that the code under review could be enhanced with whatever requests but managed by the CMT. I'm not sure it's really the role of the CMT to "save" such orphaned too early library.
The library is not orphaned, just progressing (too) slowly. Recently I've done a major change in implementation that makes quite an improvement with regards to space efficiency. I still have a few items on my todo list - after completing them and git-ifying the library I'm definitely going to add it to the repository. Best regards, Robert
On Sat, Dec 21, 2013 at 7:55 PM, Robert Kawulak <robert.kawulak@gmail.com>wrote:
The library is not orphaned, just progressing (too) slowly. Recently I've done a major change in implementation that makes quite an improvement with regards to space efficiency. I still have a few items on my todo list - after completing them and git-ifying the library I'm definitely going to add it to the repository.
Nice to hear! I'm a bit surprised that you didn't release at least a version since the review, so that even if the implementation still need changes, we can start to use it's interface. Are you also tweaking the interface or is it changes that were required by the review?
Date: Sun, 22 Dec 2013 13:16:45 +0100 From: mjklaim@gmail.com
On Sat, Dec 21, 2013 at 7:55 PM, Robert Kawulak <robert.kawulak@gmail.com>wrote:
The library is not orphaned, just progressing (too) slowly. Recently I've done a major change in implementation that makes quite an improvement with regards to space efficiency. I still have a few items on my todo list - after completing them and git-ifying the library I'm definitely going to add it to the repository.
Nice to hear! I'm a bit surprised that you didn't release at least a version since the review, so that even if the implementation still need changes, we can start to use it's interface. Are you also tweaking the interface or is it changes that were required by the review?
I wonder if the library can be added to the Boost group, but its initial files are ONLY in the "develop" branch. (Since it hasn't been finalized, there shouldn't be any files in the "master" branch yet.) Daryle W.
From: robert.kawulak@gmail.com Date: Thu, 26 Dec 2013 03:59:55 +0100
From: Daryle Walker I wonder if the library can be added to the Boost group, but its initial files are ONLY in the "develop" branch.
What would be the point of doing this?
To work on the library while moving to its repository spot. Since the code isn't at "ship it" quality, we shouldn't have a copy in the "master" branch. Would it be better to wait until a "ship it" version of the library is ready? In that case, I think we should initialize the library's repository with that first finalized version in the "develop" branch, do test runs, then copy the branch (with fixes) as the first version of the "master" branch. Daryle W.
From: Daryle Walker
I wonder if the library can be added to the Boost group, but its initial files are ONLY in the "develop" branch.
What would be the point of doing this?
To work on the library while moving to its repository spot. Since the code isn't at "ship it" quality, we shouldn't have a copy in the "master" branch.
Would it be better to wait until a "ship it" version of the library is ready?
I don't see any gain in doing this now, while I see extra work to do now and in the future to merge the reviewed version with the post-review version. Moreover, adding the code to the official Boost repository would mean that some people may start depending on the interface and their code is broken when the library code is updated. Note that if somebody wants to try the code out anyway than it's been available all the time at the link provided. Best regards, Robert
Le 17/12/13 14:35, Beman Dawes a écrit :
The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader.
See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal.
Thanks to everyone who contributed ideas and discussion. I tried to capture contributors names in the Acknowledgements section of the proposal. Apologies if I missed anyone.
IoStream has more that 60 tickets and only 5 fixed in the last 17 months. Is this library maintained? Best, Vicente
Le 17/12/13 14:35, Beman Dawes a écrit :
The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader.
See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal.
Thanks to everyone who contributed ideas and discussion. I tried to capture contributors names in the Acknowledgements section of the proposal. Apologies if I missed anyone.
Boost.Filesystem has 100 bug tickets and only 11 fixed since the last year. Beman do you need some help to maintain your library? Best, Vicente
Le 13/01/14 23:49, Vicente J. Botet Escriba a écrit :
Le 17/12/13 14:35, Beman Dawes a écrit :
The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader.
See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal.
Thanks to everyone who contributed ideas and discussion. I tried to capture contributors names in the Acknowledgements section of the proposal. Apologies if I missed anyone.
Boost.Filesystem has 100 bug tickets and only 11 fixed since the last year. Beman do you need some help to maintain your library?
The same situation for * Boost.Python 50 bugs and only 4 fixes the last year. * Boost.Test 48 bugs and only 3 fixes the last year. * Phoenix 38 bugs and only 3 fixes the last year. Do the authors of these libraries need some help to maintain these libraries? Vicente
On 1/14/14, 6:55 AM, Vicente J. Botet Escriba wrote:
* Phoenix 38 bugs and only 3 fixes the last year.
Do the authors of these libraries need some help to maintain these libraries?
(CC'ing Thomas Heller and John Fletcher) I've been communicating with John Fletcher recently and he is interested in carrying on with the maintenance of Phoenix. Before I pass on the torch, I'd like to know if Thomas (the current maintainer) is OK with it. Thomas? I'd also take this opportunity to ask anyone else interested. Please email me off-list. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On 01/14/2014 12:53 AM, Joel de Guzman wrote:
On 1/14/14, 6:55 AM, Vicente J. Botet Escriba wrote:
* Phoenix 38 bugs and only 3 fixes the last year.
Do the authors of these libraries need some help to maintain these libraries?
(CC'ing Thomas Heller and John Fletcher)
I've been communicating with John Fletcher recently and he is interested in carrying on with the maintenance of Phoenix. Before I pass on the torch, I'd like to know if Thomas (the current maintainer) is OK with it. Thomas? I'd also take this opportunity to ask anyone else interested. Please email me off-list.
Yes, I am fine with it. I couldn't find the time to properly maintain the library in the past and probably can't find the time in the future. It would be a shame if this library continues to decay. I think passing on the torch is the right thing to do here. Of course, I will be around to help wherever I can. Please either CC or email me off-list if you have any further questions regarding the code etc. Thanks, Thomas
Regards,
Thomas Thank you. It looks as though I am taking this on. I am sure I am going to need some help here. Cheers John -----Original Message----- From: Thomas Heller [mailto:thom.heller@gmail.com] Sent: 14 January 2014 12:46 To: Joel de Guzman Cc: boost@lists.boost.org; Fletcher, John P Subject: Re: The Community Maintenance Team proposal accepted On 01/14/2014 12:53 AM, Joel de Guzman wrote:
On 1/14/14, 6:55 AM, Vicente J. Botet Escriba wrote:
* Phoenix 38 bugs and only 3 fixes the last year.
Do the authors of these libraries need some help to maintain these libraries?
(CC'ing Thomas Heller and John Fletcher)
I've been communicating with John Fletcher recently and he is interested in carrying on with the maintenance of Phoenix. Before I pass on the torch, I'd like to know if Thomas (the current maintainer) is OK with it. Thomas? I'd also take this opportunity to ask anyone else interested. Please email me off-list.
Yes, I am fine with it. I couldn't find the time to properly maintain the library in the past and probably can't find the time in the future. It would be a shame if this library continues to decay. I think passing on the torch is the right thing to do here. Of course, I will be around to help wherever I can. Please either CC or email me off-list if you have any further questions regarding the code etc. Thanks, Thomas
Regards,
(reorg'ed to fix top-post)
On 14 January 2014 12:46, Thomas Heller wrote:
On 01/14/2014 12:53 AM, Joel de Guzman wrote:
On 1/14/14, 6:55 AM, Vicente J. Botet Escriba wrote:
* Phoenix 38 bugs and only 3 fixes the last year.
Do the authors of these libraries need some help to maintain these libraries?
(CC'ing Thomas Heller and John Fletcher)
I've been communicating with John Fletcher recently and he is interested in carrying on with the maintenance of Phoenix. Before I pass on the torch, I'd like to know if Thomas (the current maintainer) is OK with it. Thomas? I'd also take this opportunity to ask anyone else interested. Please email me off-list.
Yes, I am fine with it. I couldn't find the time to properly maintain the library in the past and probably can't find the time in the future. It would be a shame if this library continues to decay. I think passing on the torch is the right thing to do here. Of course, I will be around to help wherever I can. Please either CC or email me off-list if you have any further questions regarding the code etc.
On 01/14/2014 04:31 AM, Fletcher, John P wrote: Thomas
Thank you. It looks as though I am taking this on.
I am sure I am going to need some help here.
Cheers
John
I'll be able to help out, too, as time allows. Eric
On 1/15/14, 1:15 AM, Eric Niebler wrote:
(reorg'ed to fix top-post)
On 14 January 2014 12:46, Thomas Heller wrote:
On 01/14/2014 12:53 AM, Joel de Guzman wrote:
On 1/14/14, 6:55 AM, Vicente J. Botet Escriba wrote:
* Phoenix 38 bugs and only 3 fixes the last year.
Do the authors of these libraries need some help to maintain these libraries?
(CC'ing Thomas Heller and John Fletcher)
I've been communicating with John Fletcher recently and he is interested in carrying on with the maintenance of Phoenix. Before I pass on the torch, I'd like to know if Thomas (the current maintainer) is OK with it. Thomas? I'd also take this opportunity to ask anyone else interested. Please email me off-list.
Yes, I am fine with it. I couldn't find the time to properly maintain the library in the past and probably can't find the time in the future. It would be a shame if this library continues to decay. I think passing on the torch is the right thing to do here. Of course, I will be around to help wherever I can. Please either CC or email me off-list if you have any further questions regarding the code etc.
On 01/14/2014 04:31 AM, Fletcher, John P wrote: Thomas
Thank you. It looks as though I am taking this on.
I am sure I am going to need some help here.
Cheers
John
I'll be able to help out, too, as time allows.
Sweet! Thank you, Eric. May I request then for John and yourself to have write access to the submodule? Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
The same situation for * Boost.Python 50 bugs and only 4 fixes the last year. * Boost.Test 48 bugs and only 3 fixes the last year. * Phoenix 38 bugs and only 3 fixes the last year.
Do the authors of these libraries need some help to maintain these libraries?
I probably can handle these (large number of these are new features requests, which require new development), but I can use some help. More importantly though I need help pushing new release out. I probably just start separate thread about this. Gennadiy
On Mon, Jan 13, 2014 at 5:49 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 17/12/13 14:35, Beman Dawes a écrit :
The Steering Committee has voted to accept the Community Maintenance Team
proposal, and Marshall Clow has volunteer to act as the team's fearless leader.
See https://dl.dropboxusercontent.com/u/9897665/community- maintenance.htmlfor the actual proposal.
Thanks to everyone who contributed ideas and discussion. I tried to capture contributors names in the Acknowledgements section of the proposal. Apologies if I missed anyone.
Boost.Filesystem has 100 bug tickets and only 11 fixed since the last year. Beman do you need some help to maintain your library?
Probably, but I'm in a holding pattern until the Filesystem TS vote closes January 20th, and the committee finishes ballot resolution at the February meeting. Then I'll start integrating changes, quite a few of which are already done and just waiting for the final vote. What would help the most is test cases that detect problems. Git also helps in that branches can be started for bugs without blocking progress while more information is requested from submitters. My limited experience with GitHub's pull request system has so far been positive. --Beman
participants (14)
-
Beman Dawes -
Cox, Michael -
Daryle Walker -
Eric Niebler -
Fletcher, John P -
Gennadiy Rozental -
Jim Bell -
Joel de Guzman -
Klaim - Joël Lamotte -
Marshall Clow -
Rob Stewart -
Robert Kawulak -
Thomas Heller -
Vicente J. Botet Escriba