|
|
| (9 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | '''Meeting time: The neutron-lib sub-Team ([[Neutron-Lib]]) holds public meetings on Wednesdays at 1730 UTC in the #openstack-meeting-4 channel on Freednode. Everyone is encouraged to attend.''' | + | '''Meetings have been cancelled and made part of the weekly Neutron meetings until further notices |
| | | | |
| − | === Announcements / Reminders ===
| + | * Cancellation annoucement : http://lists.openstack.org/pipermail/openstack-dev/2016-November/107008.html |
| − | | + | * Neutron Meetings: http://eavesdrop.openstack.org/#Neutron_Team_Meeting |
| − | * None this week
| |
| − | | |
| − | === Current Work Items ===
| |
| − | | |
| − | * Using the lib in neutron - https://review.openstack.org/#/c/268232/ | |
| − | * Moving base db gunk - https://review.openstack.org/#/c/267214/
| |
| − | | |
| − | === Open Discussion ===
| |
| − | | |
| − | [boden]
| |
| − | * Looking for feedback on the high-level approach for a public python API generation tool as in [https://review.openstack.org/#/c/338571/ 338571]. NB: code is not ready for review, just looking to understand if the current approach is worth honing further.
| |
| − | * Have we put any thought into what impacts it would have if we released neutron-lib more frequently/continuously? For example suppose we did releases of neutron-lib every 2 weeks (for sake of argument); what implications would that have to our process and consumers? With our current release process there's a large latency when trying to get function into lib. While I understand the merits of this approach, it "seems" to impact adoption/consumption.
| |
| − | * As per [http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-4/%23openstack-meeting-4.2016-06-29.log.html our meeting] I thought we were going to get the neutron pep8 jobs running for neutron-lib gate? Is that going to happen? | |
| − | * What's our stance on documenting public APIs with pydoc string? I think we should decide on an approach and doc it so we are all on the same page. IMHO we should strive to doc all public APIs. For new function; the doc should come in the initial commit. For rehomed code, it should come as an add-on patch, as I proposed [https://review.openstack.org/#/c/340580/ here].
| |
| − | * Our neutron-lib-coverage jobs report 'File Not Found' when trying to view the coverage for an individual file; for example [http://logs.openstack.org/75/339875/2/check/neutron-lib-coverage/389bd91/cover/neutron_lib_db_utils_py.html here].
| |
| − | * Our general process of "letting code back" in its source project before rehoming to neutron-lib can be a bit of a catch22. Often neutron reviews are flagged as lib function, but they can't get a lib patch merged until it bakes for awhile in neutron.
| |
