Open Stack

Assaf Muller 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.

Just the thought I had. The dashboard generator is being very helpful to 
me :), but it's
something that could be automated.

>
>> [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