Chip For #1, I prefer to keep the fix version same as 410 for duplicates, but it can be closed so it will not show up in open issues
For #8, I will take care of creating Test sub tasks for the cleaned up new features/improvements. I have started on the process and reviewing feature and creating tasks ( started with Resolved ones first) Thanks /sudha -----Original Message----- From: Chip Childers [mailto:[email protected]] Sent: Monday, January 07, 2013 10:01 AM To: [email protected] Subject: [ACS41] Help requested reviewing new features and improvements 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
