Open Stack

Hi Ben, Joe

Thank you for your reply

(2) Avoid duplication of works
I have several experience of this.  Anyway, we should encourage people
to check listed bug before
writing patches.

(3) Release management
-> TTX is doing this after each release. so we can know how many bugs we fixed.
(or we can know how many bugs remaining in this release)

(4) sync code from oslo-incubator
IMO, this kind of 'sync' commit don't need to filing bug such as
Transmaniax, requirement update etc.





2014-05-23 12:16 GMT-07:00 Joe Gordon <joe.gordon0 at gmail.com>:
>
>
>
> On Sat, May 24, 2014 at 4:02 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>>
>>
>>
>>
>> On Sat, May 24, 2014 at 2:23 AM, Nachi Ueno <nachi at ntti3.com> wrote:
>>>
>>> Hi folks
>>>
>>> I believed we should link bug or bp for any commit except automated
>>> commit by infra.
>>> However, I found also there is no written policy for this.
>>> so may be, I'm wrong for here.
>>>
>>> The reason, we need bug or bp linked , is
>>>
>>> (1) Triage for core reviewing
>>>
>>> (2) Avoid duplication of works
>>
>>
>> I'm not sure how this will help. folks will just file duplicate bugs write
>> before the push there patch for review.
>>
>>>
>>> (3) Release management
>>
>>
>> Can you give some examples to show why requiring a bug or bp helps with
>> the items listed above.
>>
>>>
>>>
>>> IMO, generally, the answer is yes.
>>>
>>> However, how about small 5-6 nit change?
>>> so such patch will be exception or not?
>>>
>>> I wanna ask community opinion, and I'll update gerrit workflow page based
>>> on
>>> this discussion.
>>
>>
>> I don't trying to enforce this policy alone will help. For a patch that
>> doesn't have a bug or blueprint assocatiated we have two options.
>>
>> * File a blueprint. Now that many projects use specs repos blueprints have
>> a significant overhead associated with them, so we should be careful about
>> incurring that overhead.
>> * File a bug. Sure we can file a bug for every patch, but there is still
>> an overhead associated with that, and in most cases I don't think it really
>> buys us much. If the change isn't a real bug but say 'sync code from
>> oslo-incubator' what does adding a linked bug really buy us?
>>
>
>
> Wow, that came out garbled, I guess that is what a long flight does. Here is
> take two:
>
> I don't think this policy of requiring a linked blueprint or bug for every
> patch is enough to significantly help with the list of items listed above.
>
> Now that many projects use specs repositories, we have just ratcheted up the
> overhead associated with using blueprints. While this is a good thing
> overall, this also means we should be careful about making process changes
> that require folks to file more blueprints.
> As for bugs, it is unclear to me what the value of filing a bug for a patch
> that 'synces code from oslo-incubator' is. How would this help with review
> triage, especially when we don't do a great job of bug triage?
>
>
>
>
>
>
>>>
>>>
>>> Best
>>> Nachi
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>