cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <>
Subject RE: [ACS41] Help requested reviewing new features and improvements
Date Mon, 07 Jan 2013 18:26:56 GMT
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
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?? 

-----Original Message-----
From: Chip Childers [] 
Sent: Monday, January 07, 2013 10:10 AM
Subject: Re: [ACS41] Help requested reviewing new features and improvements

On Mon, Jan 7, 2013 at 1:05 PM, Sudha Ponnaganti <> 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 []
> Sent: Monday, January 07, 2013 10:01 AM
> To:
> 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
> 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
> 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]

View raw message