I’ve put up a set of procedures for the Boost Community Maintenance Team (CMT) on the wiki at: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance Comments welcomed. — Marshall
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Marshall Clow [mclow.lists@gmail.com] Sent: 27 January 2014 01:17 To: boost-maint@lists.boost.org Cc: boost@lists.boost.org List Subject: [boost] Process for the Community Maintenance Team
I’ve put up a set of procedures for the Boost Community Maintenance Team (CMT) on the wiki at: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance
Comments welcomed.
— Marshall
Thank you I think his is a very good idea. 'The Boost Community Maintenance team (CMT) was created in January 2013 to provide maintenance for libraries where the author is unable to provide it. ' I assume you mean 2014. I am a new maitainer - I have just started on Boost Phoenix - and I am willing to play a part in this. I think I am very lucky to have come in just after the change to git, as I am already familiar with it, and more so now. I am very willing to share some of my experience of learning the job, with help from Eric Niebler and Joel de Guzman. Thank you again John Fletcher
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Fletcher, John P [j.p.fletcher@aston.ac.uk] Sent: 27 January 2014 10:47 To: boost@lists.boost.org; boost-maint@lists.boost.org Subject: Re: [boost] Process for the Community Maintenance Team ________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Marshall Clow [mclow.lists@gmail.com] Sent: 27 January 2014 01:17 To: boost-maint@lists.boost.org Cc: boost@lists.boost.org List Subject: [boost] Process for the Community Maintenance Team
I’ve put up a set of procedures for the Boost Community Maintenance Team (CMT) on the wiki at: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance
Comments welcomed.
— Marshall
Thank you I think his is a very good idea. 'The Boost Community Maintenance team (CMT) was created in January 2013 to provide maintenance for libraries where the author is unable to provide it. ' I assume you mean 2014. I am a new maitainer - I have just started on Boost Phoenix - and I am willing to play a part in this. I think I am very lucky to have come in just after the change to git, as I am already familiar with it, and more so now. I am very willing to share some of my experience of learning the job, with help from Eric Niebler and Joel de Guzman. Thank you again John Fletcher P.S. Rereading my own message, I was not commiting Eric and Joel to do anything, just saying that they had helped me. I must be more careful of my English!!
On Sun, Jan 26, 2014 at 6:17 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
I’ve put up a set of procedures for the Boost Community Maintenance Team (CMT) on the wiki at: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance
Comments welcomed.
The CMT will operate on a "propose and review" process, where a change goes through the following phases. 1. Someone decides to work on a bug/test failure/etc and announces this on the mailing list. Will the CMT have it's own mailing list or use boost-devel? In the case of a separate mailing list, you should add it to Boost's mailing list web page and have a link to it. If it's going to be boost-devel, we should probably have a standardized subject line tag to make it easy to filter out the non-CMT related mail, e.g. [boost][cmt] <subject line> or maybe just use the CMT libraries name, e.g. [boost][signals] <subject line> or maybe a combination, e.g. [boost][cmt][signals] <subject line> 1. Discussion may ensue on the ML about the best way to proceed. 2. The code/tests/docs are developed and a pull request is made (on the list). 3. The request is reviewed by other members of the list. (repeat steps 3 and 4 as necessary) 4. The request is committed to the "develop" branch by a CMT manager who notifies the person who made the pull request. Just to close the loop... 1. The person who made the pull request is responsible for verifying all the tests passed, and notifying the CMT manager when it is ready to be merged to "master"
— Marshall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Jan 29, 2014 at 6:20 AM, Cox, Michael <mhcox@bluezoosoftware.com>wrote:
Will the CMT have it's own mailing list or use boost-devel? In the case of a separate mailing list, you should add it to Boost's mailing list web page and have a link to it.
It is already stated in the current second line of the page: "The boost-maint <http://lists.boost.org/mailman/listinfo.cgi/boost-maint> mailing list is where the team holds discussions and makes decisions."
On Jan 28, 2014, at 9:20 PM, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
On Sun, Jan 26, 2014 at 6:17 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
I’ve put up a set of procedures for the Boost Community Maintenance Team (CMT) on the wiki at: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance
Comments welcomed.
The CMT will operate on a "propose and review" process, where a change goes through the following phases.
1. Someone decides to work on a bug/test failure/etc and announces this on the mailing list.
Will the CMT have it's own mailing list or use boost-devel? In the case of a separate mailing list, you should add it to Boost's mailing list web page and have a link to it.
Already there - on the top of that page. The boost-maint [link] mailing list is where the team holds discussions and makes decisions. [ snip ]
1. Discussion may ensue on the ML about the best way to proceed. 2. The code/tests/docs are developed and a pull request is made (on the list). 3. The request is reviewed by other members of the list. (repeat steps 3 and 4 as necessary) 4. The request is committed to the "develop" branch by a CMT manager who notifies the person who made the pull request.
Just to close the loop...
1. The person who made the pull request is responsible for verifying all the tests passed, and notifying the CMT manager when it is ready to be merged to “master"
I’m not sure what you’re suggesting here. There’s already a 6. The person who made the pull request is responsible to watching the test results, and notifying the CMT manager when it is ready to be merged to “master" on that page. I like your wording better, but I think you mean something more. — Marshall
On Tue, Jan 28, 2014 at 11:56 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
On Jan 28, 2014, at 9:20 PM, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
On Sun, Jan 26, 2014 at 6:17 PM, Marshall Clow <mclow.lists@gmail.com wrote:
I’ve put up a set of procedures for the Boost Community Maintenance Team (CMT) on the wiki at: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance
Comments welcomed.
The CMT will operate on a "propose and review" process, where a change goes through the following phases.
1. Someone decides to work on a bug/test failure/etc and announces this on the mailing list.
Will the CMT have it's own mailing list or use boost-devel? In the case of a separate mailing list, you should add it to Boost's mailing list web page and have a link to it.
Already there - on the top of that page.
The boost-maint [link] mailing list is where the team holds discussions and makes decisions.
Sorry, I missed that.
[ snip ]
1. Discussion may ensue on the ML about the best way to proceed. 2. The code/tests/docs are developed and a pull request is made (on the list).
I'm suggesting the above change to emphasize that a change should include not only library code changes, but possibly also unit-tests and documentation, e.g. bug fixes with new unit-tests and new features with new unit-tests and documentation describing the feature.
3. The request is reviewed by other members of the list. (repeat steps 3 and 4 as necessary) 4. The request is committed to the "develop" branch by a CMT manager who notifies the person who made the pull request.
Just to close the loop...
The "close the loop" refers to 4 above. How will the person submitting the pull request know that the commit has been made to "develop" (and start looking for the successful test results). I'm suggesting the CMT manager needs to notify the person submitting the pull request (and/or posting a message to the mailing list) that the change has been committed to "develop" (or does GitHub automatically do this?).
1. The person who made the pull request is responsible for verifying all the tests passed, and notifying the CMT manager when it is ready to be merged to “master"
I’m not sure what you’re suggesting here.
There’s already a 6. The person who made the pull request is responsible to watching the test results, and notifying the CMT manager when it is ready to be merged to “master" on that page.
I like your wording better, but I think you mean something more.
No, I'm just suggesting the wording could be better and more precise. The "responsible to watching" sounds awkward. Michael
— Marshall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Cox, Michael -
Fletcher, John P -
Klaim - Joël Lamotte -
Marshall Clow