Sure Chip! Make sense If RN is going to be auto generated -----Original Message----- From: Chip Childers [mailto:[email protected]] Sent: Monday, January 07, 2013 10:34 AM To: [email protected] Subject: Re: [ACS41] Help requested reviewing new features and improvements
On Mon, Jan 7, 2013 at 1:26 PM, Sudha Ponnaganti <[email protected]> wrote: > The reason is that it helps to review metrics at the end even if it is > duplicate i.e it will have history that it is logged for this release and > resolved in this release ( closed in this release). Assuming you are talking about bug reports vs. fixed metrics, those issue records aren't really useful in a new feature / improvement scenario. > Once closed, workflow will end and it will not be revisited and clean right?? > > When you generate query for review all features for 41, you can omit the > duplicates/invalid ones etc., in that query and list will be clean, right?? The release notes auto-generated from Jira includes everything tagged with the fix version (it isn't something you have a custom query for). I agree not to mess with the fix version for bugs, but new features / improvements that were opened by mistake don't seem like the type of thing to keep around within a release's records. > > > -----Original Message----- > From: Chip Childers [mailto:[email protected]] > Sent: Monday, January 07, 2013 10:10 AM > To: [email protected] > Subject: Re: [ACS41] Help requested reviewing new features and > improvements > > On Mon, Jan 7, 2013 at 1:05 PM, Sudha Ponnaganti > <[email protected]> wrote: >> 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 > > Leaving duplicate records tagged against the release (especially if they > don't have any useful information) doesn't make much sense to me. > It will muddy the waters if we use the Jira "release notes" feature to > publish a list of changes (which I would argue is basically silly not to use > as a starting point for the Release Notes and CHANGES file). > > Can you help explain your preference here? > >> 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) >> > > OK - sounds good. We can leave that one off the list, and assume that you'll > get it nailed down. Thanks Sudha! > >> 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 >> >
