Open Stack

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