cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [ACS41] Help requested reviewing new features and improvements
Date Mon, 07 Jan 2013 18:12:52 GMT
On Mon, Jan 7, 2013 at 1:11 PM, Chip Childers <> wrote:
> On Mon, Jan 7, 2013 at 1:05 PM, David Nalley <> wrote:
>> On Jan 7, 2013 1:01 PM, "Chip Childers" <> 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]
>> Happy to help. How do you want to divide things up?
> I'm starting at the lowest number (which happens to be CLOUDSTACK-1).
> Want to start on the other end?

BTW - some of the improvements don't really need all that formality.
ex: CLOUDSTACK-1 doesn't need a functional spec, because it's just
about updating documentation for the build process.

View raw message