Open Stack

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140524/55ca785c/attachment.html>