Open Stack

On 21 January 2016 at 05:57, Rico Lin <rico.l at inwinstack.com> wrote:

> +1
>
> And how everyone think about if we deprecate to use Blueprint in Launchpad
> and use bug system instead?
>

Rico, I am not sure, that it will be really useful.
It's obvious, that we may track progress by reno + launchpad bugs.
However, it also has negative effects:
 - you need to add Partial-Bug for each patch which corresponds this bug
(feature).
 - and of course use Closes-Bug, when it be finished.
 - it's really difficult to find differences between real bug and BP during
release.
"Wishlist" status partially solves this issue, but it leads us to
situation, when we have a lot of "Whishlist" bugs, where can be real bugs
(not only features).
 - again it's more difficult for tracking status of feature  (you need to
list whole comments history for understanding list of all related patches,
while in BP all patches with necessary tag presented in short list :) )

May be I am a bit  skeptical, but I think, that we are not ready for this
step right now.


> If this make more sense, we can move all spec to bug system, lite or not.
> I have saw Ironic and some other project discuss about doing it. Most of
> the reason is they think Launchpad bug system + reno release note can
> already cover Launchpad Blueprint system.
>
> 2016-01-21 6:31 GMT+08:00 Steve Baker <sbaker at redhat.com>:
>
>> On 21/01/16 04:21, Rabi Mishra wrote:
>>
>> Hi All,
>>
>> As discussed in the team meeting, below is the proposed spec-lite process for simple feature requests. This is already being used in Glance project. Feedback/comments/concerns are welcome, before we update the contributor docs with this:).
>>
>>
>> tl;dr - spec-lite is a simple feature request created as a bug with enough details and with a `spec-lite` tag. Once triaged with status 'Triaged' and importance changed to 'Whishlist', it's approved. Status 'Won’t fix' signifies the request is rejected and 'Invalid' means it would require a full spec.
>>
>>
>> Heat Spec Lite
>> --------------
>>
>> Lite specs are small feature requests tracked as Launchpad bugs, with status 'Wishlist' and tagged with 'spec-lite' tag. These allow for submission and review of these feature requests before code is submitted.
>>
>> These can be used for simple features that don’t warrant a detailed spec to be proposed, evaluated, and worked on. The team evaluates these requests as it evaluates specs. Once a bug has been approved as a Request for Enhancement (RFE), it’ll be targeted for a release.
>>
>>
>> The workflow for the life of a spec-lite in Launchpad is as follows:
>>
>> 1. File a bug with a small summary of what the request change is and tag it as spec-lite.
>> 2. The bug is triaged and importance changed to Wishlist.
>> 3. The bug is evaluated and marked as Triaged to announce approval or to Won’t fix to announce rejection or Invalid to request a full spec.
>> 4. The bug is moved to In Progress once the code is up and ready to review.
>> 5. The bug is moved to Fix Committed once the patch lands.
>>
>> In summary the states are:
>>
>> New:	        This is where spec-lite starts, as filed by the community.
>> Triaged:	Drivers - Move to this state to mean, “you can start working on it”
>> Won’t Fix:	Drivers - Move to this state to reject a lite-spec.
>> Invalid:        Drivers - Move to this state to request a full spec for this request
>>
>> Lite spec Submission Guidelines
>> -------------------------------
>>
>> When a bug is submitted, there are two fields that must be filled: ‘summary’ and ‘further information’. The ‘summary’ must be brief enough to fit in one line.
>>
>> The ‘further information’ section must be a description of what you would like to see implemented in heat. The description should provide enough details for a knowledgeable developer to understand what is the existing problem and what’s the proposed solution.
>>
>> Add spec-lite tag to the bug.
>>
>>
>> Thanks,
>> Rabi
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> +1, this sounds useful for small features.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
>
> *Rico Lin*
> <http://www.inwinstack.com>
> 迎棧科技股份有限公司
> │ 886-963-612-021
> │ rico.l at inwinstack.com
> │ 886-2-7738-6804 #7754
> │ 新北市220板橋區遠東路3號5樓C室
> Rm.C, 5F., No.3, Yuandong Rd.,
> Banqiao Dist., New Taipei City 220, Taiwan (R.O.C)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160125/7da481e1/attachment.html>