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:05:51 GMT

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)


-----Original Message-----
From: Chip Childers [] 
Sent: Monday, January 07, 2013 10:01 AM
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

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
(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!



View raw message