[openstack-dev] Policy for linking bug or bp in commit message

Nachi Ueno nachi at ntti3.com
Wed May 28 21:03:28 UTC 2014


Hi folks

OK, so it looks like this is consensus in the community,

Link bug or bp for most of commit
Exception for not linking bug:
 (1)  Infra sync
 (2)  minor fix. (typo, small code refactor, fix doc string etc)

> Ihar, Assaf
Sorry for taking time for this discussion, I'll remove my comment for
requesting bug report.

Best
Nachi


2014-05-27 16:54 GMT-07:00 Joe Gordon <joe.gordon0 at gmail.com>:
>
>
>
> On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>>
>> 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.
>
>
> 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.
>
>>
>>
>> (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.
>
>
> This is why a strict rule won't work IMHO.
>
>>
>>
>>
>>
>>
>>
>> 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
>> >
>>
>> _______________________________________________
>> 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
>



More information about the OpenStack-dev mailing list