Re: [openstack-dev] [heat] spec-lite for simple feature requests

[Sergey Kraynev]

+1 from my side. I agree with this idea.

There is only one question from my side, which IMO we should  describe in
documentation:

Do we need to upload release-notes for such small features?
My guess is  - Yes. I'd like to know what other guys think about it.

On 20 January 2016 at 18: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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Sergey.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] spec-lite for simple feature requests

[Andreas Jaeger]

On 2016-01-25 10:56, Sergey Kraynev wrote:
> +1 from my side. I agree with this idea.
> 
> There is only one question from my side, which IMO we should  describe
> in documentation:
> 
> Do we need to upload release-notes for such small features?
> My guess is  - Yes. I'd like to know what other guys think about it.

If it has a user-visible change: Yes,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] spec-lite for simple feature requests

[Sergey Kraynev]

On 21 January 2016 at 05:57, Rico Lin  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 :
>
>> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
>
> *Rico Lin*
> 
> 迎棧科技股份有限公司
> │ 886-963-612-021
> │ ric...@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)
>
>
> 

Re: [openstack-dev] [heat] spec-lite for simple feature requests

[Jay Dobies]

On 01/20/2016 10:21 AM, 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


I think the concept is a really good idea. I like the idea of a light 
weight verification that something makes sense before beginning coding.


One question, when are bugs triaged?


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] spec-lite for simple feature requests

[Rico Lin]

+1

And how everyone think about if we deprecate to use Blueprint in Launchpad
and use bug system instead?
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 :

> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,

*Rico Lin*

迎棧科技股份有限公司
│ 886-963-612-021
│ ric...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] spec-lite for simple feature requests

[Steve Baker]

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-requ...@lists.openstack.org?subject:unsubscribe
http://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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev