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.gord...@gmail.com>: > > > > On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno <na...@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.gord...@gmail.com>: >> > >> > >> > >> > On Sat, May 24, 2014 at 4:02 AM, Joe Gordon <joe.gord...@gmail.com> >> > wrote: >> >> >> >> >> >> >> >> >> >> On Sat, May 24, 2014 at 2:23 AM, Nachi Ueno <na...@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@lists.openstack.org >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
