[Proposal] Boost Community Maintenance Team Goals and Guidelines
Start here: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html I have contacted the authors of the libraries listed in Beman’s proposals. Some have responded affirmatively; the rest have not responded. So, I thought I would put down some thoughts about how the Boost Community Maintenance Team (Boost.CMT) should work. Goals (in priority order): 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. How I see this working: 0) We’ll set up a separate Boost.CMT mailing list. (the main developer list has too much traffic already) 1) People would pick a problem and post a note to the list that they were working on it. 2) {Optional] discussion ensues about the way to solve the problem. 3) A potential solution is implemented (and tested!) 4) A pull request is posted to the mailing list (with tests) 5) Discussion ensues. Repeat steps 3/4/5 as needed. 6) The pull request is merged to ‘develop’ 7) After test cycles, the change is merged to ‘master' Notes: 1) All of this should happen on the Boost.CMT ML. 2) Discussions _about_ the CMT should happen on the main Boost ML. 3) The person who lands the patch is responsible for checking the test results and merging to “master” (and closing out the bug report, if any). 4) The goal of the CMT will be the same as the Boy Scouts - “Leave the code cleaner than when you found it” Comments? -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Marshall Clow Sent: Monday, December 23, 2013 7:46 PM To: boost@lists.boost.org List Subject: [boost] [Proposal] Boost Community Maintenance Team Goals and Guidelines
Start here: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html
I have contacted the authors of the libraries listed in Beman's proposals. Some have responded affirmatively; the rest have not responded.
So, I thought I would put down some thoughts about how the Boost Community Maintenance Team (Boost.CMT) should work.
Goals (in priority order): 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.
How I see this working:
0) We'll set up a separate Boost.CMT mailing list. (the main developer list has too much traffic already) 1) People would pick a problem and post a note to the list that they were working on it. 2) {Optional] discussion ensues about the way to solve the problem. 3) A potential solution is implemented (and tested!) 4) A pull request is posted to the mailing list (with tests) 5) Discussion ensues. Repeat steps 3/4/5 as needed. 6) The pull request is merged to 'develop' 7) After test cycles, the change is merged to 'master'
Notes: 1) All of this should happen on the Boost.CMT ML. 2) Discussions _about_ the CMT should happen on the main Boost ML. 3) The person who lands the patch is responsible for checking the test results and merging to "master" (and closing out the bug report, if any). 4) The goal of the CMT will be the same as the Boy Scouts - "Leave the code cleaner than when you found it"
Comments?
I'd like to add another goal, albeit lower priority than bugs and enhancements. * Improve the documentation, including worked and well-commented examples. A lot of the orphaned libraries are quite old and our documentation tools have improved a lot since then, and working examples are often missing or thin. I'll be willing to volunteer for this task - in as far as my ignorance permits ;-) Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Dec 24, 2013, at 4:24 AM, Paul A. Bristow
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Marshall Clow Sent: Monday, December 23, 2013 7:46 PM To: boost@lists.boost.org List Subject: [boost] [Proposal] Boost Community Maintenance Team Goals and Guidelines
Start here: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html
I have contacted the authors of the libraries listed in Beman's proposals. Some have responded affirmatively; the rest have not responded.
So, I thought I would put down some thoughts about how the Boost Community Maintenance Team (Boost.CMT) should work.
Goals (in priority order): 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.
How I see this working:
0) We'll set up a separate Boost.CMT mailing list. (the main developer list has too much traffic already) 1) People would pick a problem and post a note to the list that they were working on it. 2) {Optional] discussion ensues about the way to solve the problem. 3) A potential solution is implemented (and tested!) 4) A pull request is posted to the mailing list (with tests) 5) Discussion ensues. Repeat steps 3/4/5 as needed. 6) The pull request is merged to 'develop' 7) After test cycles, the change is merged to 'master'
Notes: 1) All of this should happen on the Boost.CMT ML. 2) Discussions _about_ the CMT should happen on the main Boost ML. 3) The person who lands the patch is responsible for checking the test results and merging to "master" (and closing out the bug report, if any). 4) The goal of the CMT will be the same as the Boy Scouts - "Leave the code cleaner than when you found it"
Comments?
I'd like to add another goal, albeit lower priority than bugs and enhancements.
* Improve the documentation, including worked and well-commented examples.
A lot of the orphaned libraries are quite old and our documentation tools have improved a lot since then, and working examples are often missing or thin.
I'll be willing to volunteer for this task - in as far as my ignorance permits ;-)
Excellent! (and yes, I agree - improving docs belongs on the list) — Marshall
participants (2)
-
Marshall Clow -
Paul A. Bristow