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?
