incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [ACS41] Help requested reviewing new features and improvements
Date Mon, 07 Jan 2013 18:05:03 GMT
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
> -chip
> [1]

Happy to help. How do you want to divide things up?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message