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?
