On Mon, Jan 7, 2013 at 1:11 PM, Chip Childers <[email protected]> wrote: > On Mon, Jan 7, 2013 at 1:05 PM, David Nalley <[email protected]> wrote: >> On Jan 7, 2013 1:01 PM, "Chip Childers" <[email protected]> wrote: >>> >>> Hi all, >>> >>> I'm going to start the work to go through all 106 new features and >>> improvements that we have tagged for the 4.1.0 release now. I've >>> shared a filter to find the issue list at [1]. >>> >>> I'm looking for someone to volunteer to help with this process (we >>> don't need a ton of people, just one or two). >>> >>> I'll be starting at the lowest issue number, and working my way up. >>> If someone wants to take the opposite direction, we can meet in the >>> middle. >>> >>> Basically, the checklist I'd like to go through would be as follows: >>> >>> Record maintenance: >>> (1) Ensure that the issue is not a duplicate, and if it is, pick one >>> and resolve the other. The one resolved as duplicate should have the >>> fix version field emptied to make sure that a query for 4.1.0 release >>> items is clean. We have had several duplicate issues created recently, >>> so this is more of a cleanup review. >>> (2) Ensure that the type is appropriately classified as a new feature >>> or improvement (or even reclassify as as bug if required). >>> (3) Ensure that a developer is in the assignee field. >>> >>> Discussion and Design checks: >>> (4) Check that the feature / improvement has been discussed on the >>> mailing list (or is still being discussed). Put a link to the >>> relevant DISCUSS and / or PROPOSAL threads in the record's description >>> field. >>> (5) Check that we have a functional spec started (or done) on the wiki >>> (and that it's a child page of the 4.1 design page). Put a link to >>> the FS wiki page in the record's description field. >>> >>> Release Planning Checks: >>> (6) Link in any blocker issues for the item, if it is dependent on >>> some other change (i.e.: re-architecture work as a blocker for a >>> feature that relies on it) >>> (7) Ensure that we have a documentation sub-task for any required doc >>> changes (we'll need to ensure that someone volunteers to document the >>> feature) >>> (8) Ensure that we have a test sub-task for functional testing (we'll >>> need to ensure >>> that someone volunteers to test the feature) >>> (9) Note in the comments if the code is expected to come in via >>> review-board vs. a merge request of an asf repo feature branch. This >>> would be based on the assignee's commit rights. >>> >>> Thanks, and let me know if you can help or have any concerns with this >> process! >>> >>> -chip >>> >>> [1] https://issues.apache.org/jira/issues/?filter=12323345 >> >> Happy to help. How do you want to divide things up? > > I'm starting at the lowest number (which happens to be CLOUDSTACK-1). > Want to start on the other end?
BTW - some of the improvements don't really need all that formality. ex: CLOUDSTACK-1 doesn't need a functional spec, because it's just about updating documentation for the build process.
