Open Stack

++

On Wed, Nov 25, 2015 at 3:05 PM, Assaf Muller <amuller at redhat.com> wrote:
> On Mon, Nov 23, 2015 at 7:02 AM, Rossella Sblendido <rsblendido at suse.com> wrote:
>>
>>
>> On 11/20/2015 03:54 AM, Armando M. wrote:
>>>
>>>
>>>
>>> On 19 November 2015 at 18:26, Assaf Muller <amuller at redhat.com
>>> <mailto:amuller at redhat.com>> wrote:
>>>
>>>     On Wed, Nov 18, 2015 at 9:14 PM, Armando M. <armamig at gmail.com
>>>     <mailto:armamig at gmail.com>> wrote:
>>>     > Hi Neutrites,
>>>     >
>>>     > We are nearly two weeks away from the end of Mitaka 1.
>>>     >
>>>     > I am writing this email to invite you to be mindful to what you
>>> review,
>>>     > especially in the next couple of weeks. Whenever you have the time
>>> to review
>>>     > code, please consider giving priority to the following:
>>>     >
>>>     > Patches that target blueprints targeted for Mitaka;
>>>     > Patches that target bugs that are either critical or high;
>>>     > Patches that target rfe-approved 'bugs';
>>>     > Patches that target specs that have followed the most current
>>> submission
>>>     > process;
>>>
>>>     Is it possible to create Gerrit dashboards for patches that answer
>>> these
>>>     criteria, and then persist the links in Neutron's dashboards devref
>>>     page?
>>>     http://docs.openstack.org/developer/neutron/dashboards/index.html
>>>     That'd be super useful.
>>>
>>>
>>> We should look into that, but to be perfectly honest I am not sure how
>>> easy it would be, since we'd need to cross-reference content that lives
>>> into gerrit as well as launchpad. Would that even be possible?
>>
>>
>> To cross-reference we can use the bug ID or the blueprint name.
>>
>> I created a script that queries launchpad to get:
>> 1) Bug number of the bugs tagged with approved-rfe
>> 2) Bug number of the critical/high bugs
>> 3) list of blueprints targeted for the current milestone (mitaka-1)
>>
>> With this info the script builds a .dash file that can be used by
>> gerrit-dash-creator [2] to produce a dashboard url .
>>
>> The script prints also the queries that can be used in gerrit UI directly,
>> e.g.:
>> Critical/High Bugs
>> (topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421 OR
>> topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100 OR
>> topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790 OR
>> topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678 OR
>> topic:bug/1513765 OR topic:bug/1514810)
>>
>>
>> This is the dashboard I get right now [3]
>>
>> I tried in many ways to get Gerrit to filter patches if the commit message
>> contains a bug ID. Something like:
>>
>> (message:"#1399249" OR message:"#1399280" OR message:"#1443421" OR
>> message:"#1453350" OR message:"#1462154" OR message:"#1478100" OR
>> message:"#1490051" OR message:"#1491131" OR message:"#1498790" OR
>> message:"#1505575" OR message:"#1505843" OR message:"#1513678" OR
>> message:"#1513765" OR message:"#1514810")
>>
>> but it doesn't work well, the result of the filter contains patches that
>> have nothing to do with the bugs queried.
>> That's why I had to filter using the topic.
>>
>> CAVEAT: To make the dashboard work, bug fixes must use the topic "bug/ID"
>> and patches implementing a blueprint the topic "bp/name". If a patch is not
>> following this convention it won't be showed in the dashboard, since the
>> topic is used as filter. Most of us use this convention already anyway so I
>> hope it's not too much of a burden.
>>
>> Feedback is appreciated :)
>
> Rossella this is exactly what I wanted :) Let's iterate on the patch
> and merge it.
> We could then consider running the script automatically on a daily
> basis and publishing the
> resulting URL in a nice bookmarkable place.
>
>>
>> [1] https://review.openstack.org/248645
>> [2] https://github.com/openstack/gerrit-dash-creator
>> [3] https://goo.gl/sglSbp
>>
>>>
>>> Btw, I was looking at the current blueprint assignments [1] for Mitaka:
>>> there are some blueprints that still need assignee, approver and
>>> drafter; we should close the gap. If there are volunteers, please reach
>>> out to me.
>>>
>>> Thanks,
>>> Armando
>>>
>>> [1] https://blueprints.launchpad.net/neutron/mitaka/+assignments
>>>
>>>
>>>     >
>>>     > Everything else should come later, no matter how easy or interesting
>>> it is
>>>     > to review; remember that as a community we have the collective duty
>>> to work
>>>     > towards a common (set of) target(s), as being planned in
>>> collaboration with
>>>     > the Neutron Drivers team and the larger core team.
>>>     >
>>>     > I would invite submitters to ensure that the Launchpad resources
>>>     > (blueprints, and bug report) capture the most updated view in terms
>>> of
>>>     > patches etc. Work with your approver to help him/her be focussed
>>> where it
>>>     > matters most.
>>>     >
>>>     > Finally, we had plenty of discussions at the design summit, and some
>>> of
>>>     > those discussions will have to be followed up with actions (aka code
>>> in
>>>     > OpenStack lingo). Even though, we no longer have deadlines for
>>> feature
>>>     > submission, I strongly advise you not to leave it last minute. We
>>> can only
>>>     > handle so much work for any given release, and past experience tells
>>> us that
>>>     > we can easily hit a breaking point at around the ~30 blueprint mark.
>>>     >
>>>     > Once we reached it, it's likely we'll have to start pushing back
>>> work for
>>>     > Mitaka and allow us some slack; things are fluid as we all know, and
>>> the
>>>     > random gate breakage is always lurking round the corner! :)
>>>     >
>>>     > Happy hacking,
>>>     > Armando
>>>     >
>>>      >
>>>
>>> __________________________________________________________________________
>>>      > OpenStack Development Mailing List (not for usage questions)
>>>      > Unsubscribe:
>>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>      > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>      >
>>>
>>>
>>> __________________________________________________________________________
>>>     OpenStack Development Mailing List (not for usage questions)
>>>     Unsubscribe:
>>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev