<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ben, Joe<br>
<br>
Thank you for your reply<br>
<div class=""><br>
(2) Avoid duplication of works<br>
</div>I have several experience of this.  Anyway, we should encourage people<br>
to check listed bug before<br>
writing patches.<br></blockquote><div><br></div><div>That's a very good point, but I don't think requiring a bug/bp for every patch is a good way to address this. Perhaps there is another way.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
(3) Release management<br>
-> TTX is doing this after each release. so we can know how many bugs we fixed.<br>
(or we can know how many bugs remaining in this release) </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(4) sync code from oslo-incubator<br>
IMO, this kind of 'sync' commit don't need to filing bug such as<br>
Transmaniax, requirement update etc.<br></blockquote><div><br></div><div>This is why a strict rule won't work IMHO.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


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