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