incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <sudha.ponnaga...@citrix.com>
Subject RE: [ACS41] Help requested reviewing new features and improvements
Date Mon, 07 Jan 2013 22:56:39 GMT
Sure Chip! Make sense If RN is going to be auto generated 

-----Original Message-----
From: Chip Childers [mailto:chip.childers@sungard.com] 
Sent: Monday, January 07, 2013 10:34 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [ACS41] Help requested reviewing new features and improvements

On Mon, Jan 7, 2013 at 1:26 PM, Sudha Ponnaganti <sudha.ponnaganti@citrix.com> 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:chip.childers@sungard.com]
> Sent: Monday, January 07, 2013 10:10 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [ACS41] Help requested reviewing new features and 
> improvements
>
> On Mon, Jan 7, 2013 at 1:05 PM, Sudha Ponnaganti <sudha.ponnaganti@citrix.com>
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:chip.childers@sungard.com]
>> Sent: Monday, January 07, 2013 10:01 AM
>> To: cloudstack-dev@incubator.apache.org
>> 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
>>
>

Mime
View raw message