| openstackgerrit | Brant Knudson proposed openstack/releases: keystoneauth 0.4.0 https://review.openstack.org/213573 | 01:13 |
|---|---|---|
| *** sigmavirus24_awa is now known as sigmavirus24 | 01:48 | |
| *** bnemec has quit IRC | 01:50 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 03:20 | |
| *** openstackgerrit has quit IRC | 03:31 | |
| *** openstackgerrit has joined #openstack-relmgr-office | 03:32 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 04:23 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 04:34 | |
| openstackgerrit | Andreas Jaeger proposed openstack/releases: Fix invocation of git_log https://review.openstack.org/216111 | 06:20 |
| openstackgerrit | Andreas Jaeger proposed openstack/releases: Fix invocation of git_log https://review.openstack.org/216111 | 06:42 |
| *** flaper87 has quit IRC | 07:08 | |
| *** flaper87 has joined #openstack-relmgr-office | 07:08 | |
| openstackgerrit | Merged openstack/releases: fix releases where SHA is not HEAD https://review.openstack.org/215790 | 09:57 |
| dhellmann | good morning | 10:45 |
| *** isviridov_away has quit IRC | 10:55 | |
| *** jroll has quit IRC | 10:56 | |
| *** jroll has joined #openstack-relmgr-office | 11:02 | |
| *** isviridov_away has joined #openstack-relmgr-office | 11:04 | |
| dhellmann | ttx; I'm looking at the release tags governance changes this morning. I see a note about renaming cycle-with-milestones to once-per-cycle. How strongly do you feel we need to do that? | 11:14 |
| *** gordc has joined #openstack-relmgr-office | 11:43 | |
| ttx | dhellmann: I think once-per-cycle is clearer, but I'd like to stop gratuitously changing tags as we near the end of the cycle, which means we need to decide soon :) | 11:46 |
| ttx | I guess cycle-with-milestones could do it | 11:47 |
| dhellmann | ttx: ok, I'm not sure either is clearer than the other myself | 11:47 |
| ttx | ok, then we should keep it as is | 11:47 |
| ttx | oh, I remember now | 11:48 |
| ttx | dhellmann: it's when we said that "milestones" might not match beta tags in the next cycle | 11:48 |
| dhellmann | oh, good point | 11:49 |
| ttx | so to support projects that would not follow milestones (but still issue beta tags leading to a single release) | 11:49 |
| dhellmann | but I expect most projects to move to cycle-with-intermediary at that point | 11:49 |
| ttx | which we don't need to track separatelyt from cycle-with-milestones | 11:49 |
| dhellmann | cycle-with-intermediary projects treat milestones as dates on the schedule, cycle-with-milestones add beta tags on those dates | 11:50 |
| ttx | thinking from a consumer perspective, I think what they want to know is whether they can expect intermediary releases, or if the project won't make any. | 11:51 |
| ttx | hence the "once-per-cycle" | 11:51 |
| ttx | they don't really care about milestones | 11:51 |
| ttx | those are dev artifacts | 11:51 |
| ttx | so it's not necessarily clearer, but it's closer to the question it's supposed to answer | 11:52 |
| dhellmann | yeah, and I'm not sure we can always predict when a project will make releases mid-cycle. I'm not sure we want a model that forbids it. | 11:52 |
| dhellmann | other than the milestone model, that is | 11:52 |
| ttx | I don't think you would accidentally switch from a "single release" to a "any number of releases" model by accident though | 11:53 |
| ttx | once model uses a mostly-flat model, the other uses a bell curve model | 11:53 |
| ttx | one* | 11:53 |
| dhellmann | hmm | 11:54 |
| ttx | if some team decides to switch in the middle, they switch | 11:54 |
| ttx | but I don't think they would flap between the two | 11:54 |
| ttx | it's a maturity thing | 11:54 |
| ttx | we could also decide it's not a question anyone but us want answered | 11:55 |
| ttx | and remove those tags altogether | 11:55 |
| dhellmann | remove all of the release model tags? | 11:57 |
| ttx | if we can't figure out the question enough to judge the quality of the answer... that means we aren't sure about the question | 11:58 |
| ttx | feels like those tags are for us (buckets for work and process) and not to answer a question downstream users have | 11:58 |
| * dhellmann stops submitting patches to update release tags | 11:59 | |
| dhellmann | I'm not sure. I think they're probably more useful to distros than to deployers. | 11:59 |
| ttx | distros are a "downstream user" to me | 12:00 |
| ttx | Let's just keep using the two tags we have now | 12:00 |
| dhellmann | of course if we get most everyone onto the cycle-with-intermediary model, there will be fewer exceptions | 12:00 |
| dhellmann | the goal of my original patch was to get us into a state where we could require all new repositories to declare their release model | 12:01 |
| ttx | agreed | 12:01 |
| ttx | release-none is imho a useful bit of info for downstream :) | 12:01 |
| dhellmann | breaking up the patch will take more work to get there, but do you still think that's a useful end state? | 12:01 |
| dhellmann | heh | 12:02 |
| ttx | I think it's a useful end state. | 12:02 |
| ttx | I just have trouble seeing the future enough to see which of those will end up being useful one year from now | 12:03 |
| dhellmann | ok, sure | 12:03 |
| *** dims has joined #openstack-relmgr-office | 13:12 | |
| *** sigmavirus24_awa has quit IRC | 13:22 | |
| *** jroll has quit IRC | 13:23 | |
| *** dims has quit IRC | 13:23 | |
| *** sigmavirus24_awa has joined #openstack-relmgr-office | 13:28 | |
| openstackgerrit | Andreas Jaeger proposed openstack/releases: openstackdocstheme 1.2.1 release https://review.openstack.org/216028 | 13:31 |
| *** jroll has joined #openstack-relmgr-office | 13:37 | |
| *** dims_ has joined #openstack-relmgr-office | 13:52 | |
| openstackgerrit | Andreas Jaeger proposed openstack/releases: openstack-doc-tools 0.30.0 release https://review.openstack.org/216264 | 14:01 |
| dhellmann | ttx: I'm going to go through the list of release requests and publish them. Let me know if you want to talk through the end-of-release sequence more, or if you want to talk to lifeless first. | 14:01 |
| ttx | dhellmann: I'll start a specific thread about it, and talk to lifeless tomorrow | 14:02 |
| dhellmann | ok | 14:02 |
| ttx | notmyname: ping me when around | 14:03 |
| *** bswartz has joined #openstack-relmgr-office | 14:05 | |
| bswartz | dhellmann: ping re: http://lists.openstack.org/pipermail/openstack-dev/2015-August/072697.html | 14:06 |
| bswartz | dhellmann: there's no patch in the listed link for manila, however I don't think any changes are required | 14:06 |
| dhellmann | bswartz: pong | 14:06 |
| dhellmann | bswartz: checking... | 14:06 |
| dhellmann | bswartz: yes, I think all your repos had a release tag already. Do you have a specs repo? | 14:07 |
| bswartz | dhellmann: no spcs | 14:07 |
| bswartz | no specs* repo | 14:08 |
| dhellmann | ok, that's usually the one that even an up to date project has missing a tag | 14:08 |
| openstackgerrit | Merged openstack/releases: openstackdocstheme 1.2.1 release https://review.openstack.org/216028 | 14:13 |
| ttx | dhellmann, lifeless: pushed to ML | 14:17 |
| *** ativelkov has joined #openstack-relmgr-office | 14:26 | |
| *** jokke_ has joined #openstack-relmgr-office | 14:26 | |
| nikhil_k | ttx: dhellmann hi | 14:26 |
| dhellmann | hi, nikhil_k | 14:27 |
| nikhil_k | ativelkov: has a question regarding python-glanceclient release of a experimental branch for liberty to be used by murano | 14:27 |
| *** mfedosin has joined #openstack-relmgr-office | 14:27 | |
| nikhil_k | dhellmann: we wish to seek a solution that will not break gates and help murano consume the lib | 14:27 |
| notmyname | ttx: around | 14:28 |
| nikhil_k | dhellmann: there's a feature branch for this experiemental feature and wondering if there was a way to release client for this purpose | 14:28 |
| ttx | notmyname: hi! wanted to discuss th need to have "release candidates" for swift's final liberty release. A bit of historical context first | 14:29 |
| *** sergmelikyan has joined #openstack-relmgr-office | 14:29 | |
| ttx | notmyname: swift releases don't do RCs, we did tag RCs on the "final" one to emulate what was done with the milestone-droven thingies like Nova | 14:30 |
| ttx | notmyname: now more things move to an "intermediary release" ala-swift model | 14:30 |
| ttx | which doesn't really need RCs | 14:31 |
| ttx | since you can just apply a new .Z tag | 14:31 |
| ttx | This has several benefits | 14:31 |
| dhellmann | nikhil_k: let me think about that a bit while ttx and notmyname chat | 14:31 |
| ttx | One is that you don't really make any release "special" | 14:31 |
| nikhil_k | dhellmann: thanks! | 14:31 |
| ttx | intermediary and end-of-cycle swift releases follow same process | 14:31 |
| ttx | the other is that you don't have to retag the rc1 to final at the end of the cycle | 14:32 |
| ttx | notmyname: what do you think about not using RCs for the final swift libert release ? | 14:32 |
| notmyname | a few things | 14:32 |
| ttx | ISTR I was the one asking for it back then, not you, but thought I'd rather doublecheck | 14:33 |
| notmyname | 1) ultimately it doesn't really matter since, for my perspective, it's low-cost either way | 14:33 |
| notmyname | 2) it's not the tags that make a release special. it's the stuff around it (eg this is the Integrated Release. all the marketing etc). so if that's still happening, then that tag is still more equal than the others | 14:34 |
| ttx | notmyname: re:(2) the only difference is that instead of tagging 2.3.4rc1, 2.3.4rc2, 2.3.4 you would tag 2.3.4, 2.3.5 on the stable/liberty branch before the end of the cycle | 14:35 |
| notmyname | 3) I'd be happy to drop the rc tag dance and the milestone-proposed branch (more happy about not doing m-p), but I will be the first to bring up that we have used that to find and fix bugs. the "cost" of doing new tags, and potentially having several right around release, is the tradeoff, I think | 14:35 |
| ttx | Agree the "last one" is more equal. But "last one" doesn't necessarily mean "using RCs" | 14:36 |
| ttx | notmyname: we don't do m-p since kilo | 14:36 |
| ttx | there we did stable/kilo directly | 14:36 |
| notmyname | right :-) | 14:37 |
| ttx | basically the proposed process is: | 14:37 |
| ttx | - you come up with something that looks like it will be the final swift release for liberty | 14:37 |
| ttx | - you tag that (2.3.4) | 14:37 |
| ttx | - we create a stable/liberty release branch from there | 14:37 |
| ttx | - you find critical issues in that branch | 14:38 |
| ttx | - you fix in master and backport the fix | 14:38 |
| ttx | - you tag a new release on the release branch (2.3.5) | 14:38 |
| ttx | - it's release day ! fireworks | 14:38 |
| ttx | - stable/liberty becomes a stable branch and only has security fixes and major issues backported. | 14:38 |
| ttx | next release of swift is done off master and called 2.4.0 or 3.0.0 | 14:39 |
| notmyname | ok. so the only difference is bumping the rev version number instead of doing a bunch of rc tags. otherwise the same as normal | 14:39 |
| ttx | yeah | 14:39 |
| notmyname | ah...except | 14:39 |
| notmyname | so everything sounds great until that last thing | 14:39 |
| notmyname | means that again the last release is more special, and now not just because of marketing | 14:40 |
| notmyname | means that it's the last of the X.Y series | 14:40 |
| ttx | that's more an artifact of having a stable branch | 14:40 |
| ttx | and it's true already | 14:41 |
| notmyname | it's that you can't follow a Liberty release with a quick release of bugfixes | 14:41 |
| ttx | phone ringing | 14:41 |
| ttx | ok, call dismissed | 14:42 |
| notmyname | but TBH, that's somethign I can probably get over. the practical reality is that there will be (for the foreseeable future) new stuff more than just bugfixes in releases after a cycle release | 14:42 |
| ttx | notmyname: the alternative is.. not being able to issue a point release on the stable branch at all | 14:42 |
| ttx | I guess that could work too | 14:42 |
| ttx | we kind of need that for libraries, but probably not require it for services | 14:43 |
| ttx | dhellmann: opinion on that ? | 14:43 |
| * ttx checks if we did that for swift in the past | 14:44 | |
| * dhellmann reads scrollback | 14:44 | |
| notmyname | ttx: what do you mean? | 14:44 |
| ttx | issue a point release on a stable branch | 14:45 |
| notmyname | "not doing point releases on stable"? the .Z would always be 0? | 14:45 |
| ttx | notmyname: it's quite orthogonal to the change I'm discussing though. We have that issue whether we use RCs or not | 14:45 |
| dhellmann | ttx: we do want point releases for both services and libs on stable branches | 14:45 |
| openstackgerrit | Merged openstack/releases: pycadf 1.1.0 https://review.openstack.org/215232 | 14:46 |
| ttx | the question of bumping Y on the first release of a new dev cycle is not linked to the question of using RCs in the final release process | 14:46 |
| openstackgerrit | David Lyle proposed openstack/releases: Release django_openstack_auth 1.3.2 https://review.openstack.org/214689 | 14:46 |
| notmyname | ttx: true. the rc-tag-ectomy is fine with me. the rest is making sure we dont' become slave to our own processes | 14:46 |
| openstackgerrit | David Lyle proposed openstack/releases: Release django_openstack_auth 1.4.0 https://review.openstack.org/214689 | 14:47 |
| jokke_ | ?wi23 | 14:48 |
| ttx | notmyname: ok, we'll discuss the Y start-of-cycle bump separately then | 14:48 |
| notmyname | ttx: if we have our strict x.y.z policy that we must never deviate from (which is something we made up for ourselves), then what you describe is the way to do it: .Y gets increased the first release after a cycle release. if we allow for a x.y.z.Ω for backports, that goes away (but breaks the policy) | 14:50 |
| notmyname | ttx: to be clear, it doesn't really matter to me | 14:50 |
| notmyname | (it's near the bottom of my Things I Want to Spend a Lot of Time Thinking About list ;-) | 14:50 |
| ttx | notmyname: understood | 14:51 |
| notmyname | dhellmann: I got a reply from graham about wsgi. thanks again | 14:51 |
| ttx | nikhil_k: so... having a special release for Murano triggers plenty of "WRONG" signs blinking around me | 14:52 |
| ttx | beyond the technical madness, it's a slippery slope | 14:53 |
| ttx | experimentation is fine, but having /some/ projects wanting to consume that experimentation is where the bucket stops imho | 14:53 |
| ttx | it's either released or it's not. | 14:54 |
| ttx | So the only way to make it work woud be to create a completely separate project called glance-for-murano and release that | 14:54 |
| nikhil_k | ttx: I see, this is py-client though. | 14:55 |
| nikhil_k | ttx: and yes, I was thinking the same that we might possibly need to releae this feature branch in pip as some py-glanceclient-for-murano | 14:55 |
| ttx | glance-client-for-murano then. Or you manage to merge the feature back in python-glanceclient proper and trigger the code path using --murano | 14:56 |
| nikhil_k | ttx: please no, having it in the master is more troubling! | 14:56 |
| nikhil_k | ativelkov: jokke_ ^ | 14:56 |
| nikhil_k | mfedosin: ^ | 14:56 |
| ttx | nikhil_k: maybe more troubling for you, but less troubling for me, the gate, QA guys and the world :) | 14:56 |
| nikhil_k | haha | 14:57 |
| ativelkov | sergmelikyan: ^ | 14:57 |
| nikhil_k | ttx: it shall be more troubling for all of us in the near future if we don't have it sperate, please trust me on that! | 14:57 |
| ttx | nikhil_k: how about Murano team waits for that experimentation to be merged back ? Or better, contribute resources to finish it asap ? | 14:58 |
| * ttx has no idea what feature we are tralking about here, so probably conjecturing | 14:59 | |
| nikhil_k | ttx: it's the artifacts thing | 14:59 |
| sergmelikyan | ativelkov: correct me, if I am wrong, but I guess it's not the question of resources for now | 14:59 |
| nikhil_k | the Glance API is being restructured as per suggestions from the API_WG | 14:59 |
| ativelkov | murano team is contributing the resources (I am the resource) :) | 14:59 |
| ttx | just saying I see no way of having parallel release channels for experimental branches that would make sense in a x.y.z versioning and not break everything if done on the same namespace | 14:59 |
| nikhil_k | so we want the client to support minimalistic for now | 14:59 |
| ttx | ativelkov: sounds fun :) | 15:00 |
| sergmelikyan | ativelkov: ttx is asking if it's possible to add more people in order to finish on time | 15:00 |
| ativelkov | Folks, there is one more option | 15:02 |
| ttx | so yeah, slightly less worse options would be: copy-paste the client code to Murano, publish it temporarily under a glanceclient-for-murano repo. Best solution would be to wait until it's released, but I suspect that was considered and rejected | 15:02 |
| ativelkov | ttx - you stole it! | 15:02 |
| ativelkov | I just wanted to propose the same :) | 15:02 |
| ttx | ativelkov: it's not a good option, but at least it's not a completely wrong one | 15:03 |
| ativelkov | So, if sergmelikyan is ok with some copy-paste from glanceclient to temporary land in muranoclient, then we'll have the solved | 15:03 |
| nikhil_k | I am okay with that because I trust ativelkov . We shall have a consistent working code next cycle! | 15:04 |
| sergmelikyan | ativelkov: I think we are ok with that, it will allow us to make sure that code is complete and contribute back in beginning of the M | 15:04 |
| sergmelikyan | once we will be able to release first version of glanceclient | 15:05 |
| sergmelikyan | with artifacts | 15:05 |
| nikhil_k | awesome | 15:06 |
| ativelkov | OK, so the feature branch will remain in glance for now, but will be published in python-muranoclient releases in L | 15:06 |
| ativelkov | i.e. we will copy-paste the code from python-glanceclient/feature/artifacts to python-muranoclient/master | 15:07 |
| ativelkov | (similar as we do with oslo incubator code) | 15:07 |
| ativelkov | After the v3 refactoring is complete and API is stable (in M), wel'll drop the copy from murano and merge the artifact client from feature/artifacts to master of python-glanceclient | 15:09 |
| ativelkov | Looks fine | 15:09 |
| ativelkov | thanks ttx :) | 15:09 |
| ttx | np | 15:09 |
| nikhil_k | Excellent, thanks all! | 15:15 |
| nikhil_k | ttx: what would be our freeze for release of clients? | 15:15 |
| nikhil_k | ttx: just for awareness | 15:15 |
| jokke_ | ativelkov, nikhil_k, sergmelikyan, mfedosin, ttx: thnx that sounds very sane resolution! | 15:23 |
| dhellmann | notmyname: great, I hope things work out with graham & wsgi | 15:24 |
| ativelkov | nikhil_k: jokke_: I'll send an email to ML about this solution | 15:25 |
| nikhil_k | ativelkov: thanks! | 15:25 |
| dhellmann | nikhil_k, ttx, ativelkov : have you explored the idea of releasing the experimental client under a different name? | 15:25 |
| ativelkov | dhellmann: well, adding | 15:26 |
| ativelkov | dhellmann: well, adding a new project just for one release sounds cumbersome | 15:26 |
| dhellmann | that is, use the same feature branch in the repo but change the name of the dist that it builds | 15:26 |
| dhellmann | ativelkov: all you have to do is change the name in setup.cfg | 15:27 |
| ativelkov | dhellmann: we'll get pythons' package name conflict in this cas | 15:27 |
| ativelkov | case | 15:27 |
| dhellmann | ah, true, so you'd have to rename the root package :-/ | 15:27 |
| ativelkov | yup | 15:27 |
| dhellmann | which is still not actually that much work, but might not be worth it | 15:27 |
| ativelkov | It's easier to copy-paste the glanceclient/v3 to muranoclient/artifacts and release with murano | 15:27 |
| dhellmann | ativelkov: is this a whole new glance client api? | 15:28 |
| jokke_ | Curly haired guy sitting at the end of our row ;) | 15:28 |
| jokke_ | darn, sry | 15:28 |
| ativelkov | dhellmann: it will be. However for now it cannot work with the legacy images, just artifacts | 15:28 |
| dhellmann | ativelkov: ok, I've caught up on scrollback now -- vendoring it in murano for now seems reasonable | 15:28 |
| openstackgerrit | Merged openstack/releases: Release django_openstack_auth 1.4.0 https://review.openstack.org/214689 | 15:33 |
| * SergeyLukjanov doing openstack/django_openstack_auth release 1.4.0 now | 15:35 | |
| SergeyLukjanov | dhellmann ^^ | 15:35 |
| *** dims__ has joined #openstack-relmgr-office | 15:36 | |
| dhellmann | SergeyLukjanov: ack, thanks -- I assumed as much since you approved it | 15:36 |
| SergeyLukjanov | :) | 15:36 |
| SergeyLukjanov | heh, looks like we have no django_openstack_auth | 15:37 |
| *** david-ly_ is now known as david-lyle | 15:38 | |
| SergeyLukjanov | oh, I it's using - instead of _ | 15:38 |
| *** dims_ has quit IRC | 15:39 | |
| redrobot | hello relmgrs. I believe the acl issues in python-barbicanclient have been fixed. Could someone take a look at https://review.openstack.org/#/c/214280/ again? | 15:42 |
| SergeyLukjanov | redrobot, I'll do it | 15:43 |
| redrobot | SergeyLukjanov thanks! | 15:44 |
| dhellmann | SergeyLukjanov: do you think we can automate a check for release permissions so we don't run into a problem like ^^ again? I would have hated to approve that patch only to discover the permissions issue later | 15:44 |
| openstackgerrit | Merged openstack/releases: python-barbicanclient 3.3.0 https://review.openstack.org/214280 | 15:45 |
| SergeyLukjanov | dhellmann, I think it's possible, but could be complicated | 15:47 |
| SergeyLukjanov | dhellmann, we'll need to grep the ACL file path from the gerrit's project list file in project-config and then grep the needed rule in this file | 15:47 |
| ttx | SergeyLukjanov: announce approved | 15:58 |
| SergeyLukjanov | ttx thx | 15:59 |
| SergeyLukjanov | redrobot, released | 16:04 |
| *** dims__ has quit IRC | 16:12 | |
| *** dims has joined #openstack-relmgr-office | 16:13 | |
| *** dims is now known as dims__ | 16:13 | |
| openstackgerrit | Merged openstack/releases: openstack-doc-tools 0.30.0 release https://review.openstack.org/216264 | 16:25 |
| david-lyle | SergeyLukjanov: thanks for the d-o-a release | 16:28 |
| dhellmann | devananda, jroll : I'm looking at the ironic 4.0.0 release request (https://review.openstack.org/#/c/214301/). We need to coordinate this so we land a patch to remove the version from setup.cfg, too. | 16:36 |
| dhellmann | devananda, jroll : I have to step out for a bit, but I should be able to help you with the release this week if we can find a good time to do it together. | 16:37 |
| devananda | awesome, let's do it | 16:37 |
| devananda | dhellmann: also, I leave early thursday morning for black rock. will be offline completely for ~ 10 days | 16:37 |
| devananda | maybe closer to 14 | 16:38 |
| dhellmann | devananda: ok, I have an errand I need to take care of but I should be back in about an hour | 16:38 |
| devananda | cool. i'll be around | 16:38 |
| dhellmann | I also need to think through the steps before we start | 16:38 |
| dhellmann | ok, I'll ping you again | 16:38 |
| redrobot | SergeyLukjanov awesome, thank you! | 16:41 |
| *** dims__ has quit IRC | 16:43 | |
| *** dims__ has joined #openstack-relmgr-office | 16:45 | |
| *** armax has joined #openstack-relmgr-office | 17:53 | |
| dhellmann | devananda: hey, I'm back if you're around | 17:56 |
| *** bswartz has quit IRC | 17:57 | |
| devananda | dhellmann: finishing a meeting, then a few wrap ups. around in 30 ? | 17:58 |
| dhellmann | devananda: sure | 17:58 |
| lifeless | dims__: we should put that new fix of yours in a point release of pbr | 18:03 |
| dims__ | lifeless: ++ | 18:05 |
| lifeless | dims__: if I put up a releases patch, will you do it ? | 18:11 |
| dims__ | lifeless: ack | 18:11 |
| lifeless | dims__: (I'm in quiet time just before daughter wakes right now ;)) | 18:11 |
| dims__ | totally hear you :) | 18:12 |
| openstackgerrit | lifeless proposed openstack/releases: pbr 1.5.1 https://review.openstack.org/216365 | 18:14 |
| lifeless | dims__: ^ | 18:14 |
| openstackgerrit | Doug Hellmann proposed openstack/releases: Make list-changes smarter https://review.openstack.org/216370 | 18:20 |
| dhellmann | lifeless, dims__ : ^^ should make it easier to look at the ironic release in https://review.openstack.org/#/c/214301/2 | 18:21 |
| *** sergmelikyan has quit IRC | 18:30 | |
| openstackgerrit | Doug Hellmann proposed openstack/releases: keystoneauth 0.4.0 https://review.openstack.org/213573 | 18:31 |
| devananda | dhellmann: ok - i think i can give this my undivided attention for a while :) | 18:37 |
| dhellmann | devananda: ok, first question, I notice you're not releasing HEAD of master. Is that intentional? | 18:38 |
| devananda | let me see what jroll was doing | 18:39 |
| devananda | also, it's unfortunate that he's on vacation this week, and I'm on vacation next week | 18:39 |
| dhellmann | that change is about 40 patches earlier than head | 18:40 |
| dhellmann | the sha in the request, that is | 18:40 |
| dhellmann | ideally we would release head, land a patch to remove the version, and then you would continue landing regular patches | 18:40 |
| devananda | right - I suspect that was HEAD when he proposed it | 18:41 |
| devananda | judging by the proposal date, and merge date of that SHA | 18:41 |
| dhellmann | ah, yeah | 18:41 |
| devananda | I can update it | 18:41 |
| dhellmann | ok, good | 18:41 |
| dhellmann | is there anything in the merge queue for ironic right now? | 18:41 |
| * devananda checks | 18:41 | |
| dhellmann | I don't see anything, so that's good | 18:41 |
| devananda | dhellmann: nothing afaict either | 18:42 |
| dhellmann | ok, so while you update the release request I'll put up a patch to remove the version from ironic's setup.cfg | 18:43 |
| devananda | dhellmann: side question: my understanding is that we should still have a "stabilization period" on master before tagging a new major release | 18:43 |
| devananda | this 4.0.0 is going to be a bit of an exception since we're in the ramp-up period right now. I know folks wanted to get this oiut a few weeks ago, when it was slower | 18:44 |
| devananda | but coordination issues and then learning about the new relesae system stalled us | 18:44 |
| dhellmann | yeah, I think this came in while ttx and I were both out | 18:44 |
| devananda | and other developers kept going | 18:44 |
| devananda | yea | 18:44 |
| dhellmann | switching to post-versioning requires some coordination | 18:45 |
| dhellmann | after that, you can tag whatever you want at any point | 18:45 |
| devananda | c/should we do a 4.0.0-beta as the first tag, then? | 18:45 |
| dhellmann | you could do that. I'm not sure what it would buy you. What're your thoughts? | 18:46 |
| devananda | hm. or we end up doing, say, 4.1.0 a couple weeks from now | 18:47 |
| devananda | that's probably also fine | 18:47 |
| dhellmann | oh, yeah, you shouldn't plan on tagging alphas or betas as a regular thing | 18:47 |
| devananda | right | 18:47 |
| devananda | so yea, let's just cut 4.0.0 and then I'll ask folks to stabilize it, and we'll do another release real soon | 18:48 |
| devananda | will be good learning for the team to finally be able to release on demand | 18:49 |
| dhellmann | ok, so, next question: 4.0 is right? I can't remember how many cycles ironic has been doing releases. It looks like 2014.1, 2014.2, 2015.1.0 exist so 4 should be right | 18:49 |
| dhellmann | ++ | 18:49 |
| devananda | yes, we've had 3 releases managed by openstack | 18:49 |
| devananda | I, J, K | 18:50 |
| dhellmann | cool | 18:50 |
| openstackgerrit | Devananda van der Veen proposed openstack/releases: Add Ironic 4.0.0 https://review.openstack.org/214301 | 18:50 |
| dhellmann | ok, so next I need to figure out whether anyone is going to be confused if ^^ has a different version in setup.cfg | 18:50 |
| dhellmann | pbr is not, as long as the git repository is there | 18:51 |
| dhellmann | packaging tools that don't use the git repo might be | 18:51 |
| devananda | pbr borks for me if I try to pip install ^ | 18:52 |
| dhellmann | so the question is, is it better to have those tools be confused or to land the patch to remove the version from setup.cfg (which would cause the version number to dip to a dev version of 2015.1.1) and then tag that commit as 4.0.0, | 18:52 |
| lifeless | devananda: what error | 18:52 |
| devananda | dhellmann: I think we already proposed a patch to ironic for that | 18:52 |
| lifeless | devananda: and had you removed the version= from setup.cfg ? | 18:52 |
| dhellmann | devananda: possibly, but your setup.cfg still has a version in it | 18:53 |
| lifeless | dhellmann: what tools? | 18:53 |
| dhellmann | lifeless: I don't know, the deb and rpm guys always yell when things change with packaging and I don't know how those work but they seem fragile | 18:53 |
| lifeless | dhellmann: anything in the openstack ecosystem should cope fine since the clients have not had versions in their setup.cfgs for a very long time | 18:53 |
| dhellmann | so I'm worried that even if we tag $SHA as 4.0.0 if the setup.cfg in $SHA has version=x.y.z their tools will be confused | 18:54 |
| devananda | https://review.openstack.org/#/c/192404/1 | 18:54 |
| dhellmann | lifeless: this is ironic server | 18:54 |
| devananda | dhellmann: looks like you tried it a while ago. I'll update to 4.0.0, one sec | 18:54 |
| lifeless | dhellmann: yes, but the packaging tools are the same | 18:54 |
| dhellmann | devananda: no, don't do that | 18:54 |
| dhellmann | devananda: the right way to do it is to remove the line entirely, and I have another patch ready for that now | 18:54 |
| devananda | ahhh | 18:54 |
| devananda | ok | 18:54 |
| dhellmann | devananda: I'm working out what order to do things, tag then land or land then tag | 18:55 |
| lifeless | devananda: so I bet you get an error saying pbr can't cope,right ? | 18:55 |
| dhellmann | lifeless: I'm sure tools we own will work fine. I'm less sure that zigo is going to figure out that the version number of ironic is 4.0.0 instead of 2015.1.1.dev80+ | 18:55 |
| devananda | lifeless: to that ^ patch, yes | 18:55 |
| lifeless | devananda: so thats because the new version being targeted in the config is less than the most recent tag | 18:55 |
| lifeless | devananda: its an impossible situation per versioning rules | 18:56 |
| devananda | lifeless: indeed. which is why that line is being removed, IIUC | 18:56 |
| lifeless | devananda: you have to do the actual tag. The removal of the line makes maintenance easier | 18:56 |
| lifeless | devananda: so if you do a signed tag locally of 4.0.0 and then either a) change version to 4.1.0 in the cfg or b) remove the line, then pbr should be happy | 18:57 |
| devananda | dhellmann: oh - is this done by signed git tags now (similar to the client release mechanism) ? | 18:57 |
| dhellmann | devananda: yes, you'll be switching to post-versioning using tags | 18:57 |
| devananda | what is the purpose of the CR to openstack/releases then? | 18:57 |
| dhellmann | devananda: it triggers the tagging, although we don't have the final step automated yet | 18:57 |
| dhellmann | I have a script that reads the file you're editing there | 18:58 |
| dhellmann | devananda: at some point next cycle (I hope) approval will cause all of the rest of the process to happen, and this won't take up so much of our day-to-day :-) | 18:58 |
| dhellmann | so, lifeless, what do you think about ordering? If we tag, then remove the version in setup.cfg, the tagged version and its setup.cfg don't match. If we change setup.cfg first and tag the results, the version number will dip from 2015.2.0.dev563 to 2015.1.1.dev564 | 19:00 |
| dhellmann | and then to 4.0.0 of course | 19:00 |
| devananda | dhellmann: "it triggers the tagging" -- you mean it lands the tag that I signed and proposed? | 19:01 |
| devananda | I can see how this is confusing then | 19:01 |
| dhellmann | devananda: yes, there will be a job to do the tagging based on the instructions you're giving in that file -- it will run more or less the same script I'm going to run for you shortly | 19:01 |
| dhellmann | and it will fix launchpad, and send email, and whatever else we need to do | 19:02 |
| devananda | nice | 19:02 |
| devananda | oh yea, LP | 19:02 |
| devananda | we have nearly stopped using it, btw | 19:02 |
| dhellmann | oh? | 19:02 |
| dhellmann | bugs go where? | 19:02 |
| devananda | for features, | 19:02 |
| dhellmann | ah | 19:02 |
| devananda | I hit enter too fast :) | 19:02 |
| devananda | bugs are very much still in LP; features are in specs and a spreadsheet | 19:05 |
| dhellmann | ok, that's fine (though I'm curious to hear about how that's working for you) | 19:05 |
| devananda | it saves time. but how effective is it? still to be seen | 19:05 |
| dhellmann | k | 19:05 |
| devananda | I'm curious how it will affect the release process | 19:06 |
| dhellmann | well, it's going to mean your release reporting pages don't talk about any features, for one | 19:06 |
| devananda | since that is/was tied to LP series numbers, release milestones, and the autogeneration of change logs from BPs | 19:06 |
| dhellmann | so that's less than ideal | 19:06 |
| devananda | right | 19:06 |
| devananda | we still require specs be linked to a BP, though we don't do anything beyond that | 19:07 |
| dhellmann | oh, so you have the blueprints but their statuses are likely to be wrong? | 19:07 |
| devananda | I could script updating LP based on completed specs ... or see if ttx' scripts could do what we need | 19:07 |
| devananda | dhellmann: yes | 19:07 |
| dhellmann | ok | 19:07 |
| * dhellmann thinks | 19:07 | |
| dhellmann | the release script will update the status of targeted bugs from "fix committed" to "fix released" | 19:08 |
| dhellmann | I think it depends on the blueprints being done by hand | 19:08 |
| dhellmann | mostly because for libraries we don't tend to have a lot of blueprints for any one lib, so it's not a big problem | 19:09 |
| dhellmann | devananda: spec2bp.py might be close to what you want | 19:11 |
| dhellmann | devananda: that or adjust_blueprints.py | 19:12 |
| devananda | hmmm yea | 19:12 |
| lifeless | dhellmann: tag + land updated setup.cfg IMO | 19:12 |
| lifeless | dhellmann: the very next patch to land will be the updated setup.cfg because everything else will error | 19:12 |
| dhellmann | lifeless: ok, so we're not worried about the mismatch for packagers not having the git repo where they're building a package? | 19:13 |
| dhellmann | lifeless: well, it won't, because 2015.2 is higher than 4.0 | 19:13 |
| lifeless | dhellmann: oh, right. Meh | 19:13 |
| lifeless | dhellmann: it really doesn't matter | 19:13 |
| dhellmann | ok | 19:13 |
| lifeless | dhellmann: we've already signed on to 'we are breaking all the rules on versioning here' | 19:14 |
| lifeless | trying to make it 'correct' is a bit of an oxymoron | 19:14 |
| dhellmann | lifeless: do do you know where the distros get a version number for something like oslo.config, if they don't package from a dir with the git repo? | 19:14 |
| lifeless | dhellmann: from the sdist | 19:14 |
| lifeless | dhellmann: pbr bundles that into it | 19:14 |
| dhellmann | yeah, I'm not trying for "correct" just "less broken | 19:15 |
| dhellmann | ah, right, metadata | 19:15 |
| dhellmann | ok, I think we're good to do it in that order, then | 19:15 |
| dhellmann | so now we just need to sort out the blueprints | 19:15 |
| dhellmann | devananda: here's your ironic version fix: https://review.openstack.org/216388 -- that needs to be the very next ironic patch to land after we tag the repo | 19:16 |
| devananda | dhellmann: ok - so - process is: 1) I sign a tag on HEAD now. 2) I push the tag to gerrit 3) ???? 4) I approve that ^ patch 5) profit | 19:17 |
| patchbot | devananda: https://review.openstack.org/#/c/5/ | 19:17 |
| dhellmann | devananda: no, you don't do any of those things, I do them. | 19:17 |
| dhellmann | that's why I asked you to submit the patch to the releases repository :-) | 19:17 |
| devananda | ooh | 19:18 |
| dhellmann | devananda: as a managed project, you will just submit patches there with instructions, we'll review them, and then the release will happen after the change is approved | 19:18 |
| devananda | and after this is done, you will continue doing those things when I (or jroll) submits a patch to openstack/releases ? | 19:19 |
| dhellmann | that's right | 19:19 |
| devananda | gotcha | 19:19 |
| dhellmann | until such a time as I can automate myself out of this particular job | 19:19 |
| lifeless | first rung on the automation ladder | 19:19 |
| dhellmann | right | 19:19 |
| devananda | interesting. jroll and I both thought we would become responsible for doing that for the point releases | 19:19 |
| dhellmann | oh, no, just for submitting the request | 19:19 |
| devananda | and you'd only do it for the integrated "Liberty" release | 19:19 |
| dhellmann | I mean, you could go release:independent, but I'm not sure you want to | 19:20 |
| dhellmann | I'm sorry, that was poor communication on our part | 19:20 |
| devananda | interesting | 19:21 |
| devananda | the client is also release:managed | 19:21 |
| devananda | that is NOT what I thought | 19:22 |
| devananda | also, I know the release process for the client has been, up to now, thta I sign and push a tag to gerrit | 19:22 |
| dhellmann | yeah, that will also be done with a change to the releases repo | 19:22 |
| dhellmann | we changed a lot of the libraries early in the cycle so we could get a handle on the use of semver | 19:22 |
| dhellmann | devananda: so, next step is to figure out what to do with the blueprints in lp | 19:24 |
| dhellmann | I see a bunch in https://blueprints.launchpad.net/ironic/liberty | 19:24 |
| dhellmann | I wonder if any of those have accurate status? | 19:25 |
| devananda | dhellmann: so ecd007e1 looks like an error | 19:25 |
| dhellmann | oh? | 19:26 |
| devananda | dhellmann: in that commit to openstack/governance, you tagged a couple ironic projects as manged which are not | 19:26 |
| devananda | python-ironicclient and python-ironic-inspector-client | 19:27 |
| dhellmann | we want to manage those | 19:27 |
| devananda | oh | 19:28 |
| dhellmann | there was a whole thread about this months ago, when I changed the acls, did you miss that? | 19:28 |
| devananda | apparently so | 19:28 |
| devananda | :( | 19:28 |
| dhellmann | ok, sorry | 19:28 |
| devananda | so all clients are now managed? | 19:28 |
| dhellmann | the tl;dr is that folks were doing semver wrong and confusing everyone, so we pulled in the clients for the integrated release projects and some others, changed the acls, and instituted this releases repo | 19:28 |
| dhellmann | not all, but most | 19:29 |
| devananda | heh | 19:29 |
| devananda | ++ for consistency | 19:29 |
| dhellmann | obviously we missed some ptls along the way | 19:29 |
| dhellmann | we discussed it on the ML and in some cross-project meetings, so I thought silence was consent | 19:29 |
| devananda | I have been, well, distracted .... my fault | 19:30 |
| dhellmann | yeah, no problem, my fault for not getting explicit acks from everyone | 19:30 |
| devananda | anyway, knowing that, it's fine. I don't have any particular desire to do the tagging myself | 19:30 |
| dhellmann | yeah, it's the same process, with a patch to the releases repo | 19:30 |
| devananda | if you want to do all the work, well, good for you :) | 19:30 |
| dhellmann | eventually we'll do everything that way and let the bots do the hard work | 19:30 |
| dhellmann | heh | 19:31 |
| devananda | still need a human to review the incoming request | 19:31 |
| dhellmann | so far you haven't asked me to do any work on that :-) | 19:31 |
| dhellmann | yeah, but that'll probably be one +2a | 19:31 |
| devananda | cause I didnt know you were working on that :) | 19:31 |
| dhellmann | "does their semver make sense? ok" | 19:31 |
| devananda | I was going to do a client release on my own soon, heh | 19:31 |
| devananda | so we'll need to do a similar switch in the client, but there it won't break anything because we have been doing semver | 19:32 |
| devananda | at least as far as i understand it | 19:32 |
| devananda | :) | 19:32 |
| dhellmann | yeah, the other thing I want to do is publish an unreleased log so we can find things we need to be releasing more often | 19:32 |
| devananda | ++ | 19:32 |
| dhellmann | the client is already post-versioning, so you just need to submit the patch with the sha and version | 19:32 |
| dhellmann | the rest is easy, once we've made the shift | 19:32 |
| devananda | cool | 19:32 |
| dhellmann | well, unless you need to do the launchpad work, too | 19:33 |
| devananda | ok - anything else to get me up to speed? | 19:33 |
| devananda | oh - we don't track the client on LP. never did. I have manually generated the release notes in the tag message | 19:33 |
| devananda | *track the releases of | 19:34 |
| dhellmann | so right now we need: 1) do not land any more ironic patches until we've tagged 2) clean up LP for ironic server 3) dhellmann tag ironic 4) devananda land patch 216388 | 19:34 |
| patchbot | dhellmann: https://review.openstack.org/#/c/216388/ | 19:34 |
| devananda | we, again, just use it for bugs | 19:34 |
| dhellmann | that's new, I wonder where patchbot came from | 19:34 |
| devananda | I've notified cores of (1). I'll take a look at (2) now | 19:34 |
| dhellmann | k | 19:34 |
| devananda | oh interesting -- it looks like some automation has been keeping https://launchpad.net/python-ironicclient up to date with milestones | 19:35 |
| dhellmann | yes, that's part of what you get when we tag releases for you | 19:35 |
| devananda | neat. I imagine the same will happen for ironic 4.0.0 then, once the switch is complete? | 19:37 |
| dhellmann | yes, that's right | 19:38 |
| dhellmann | that's part of why we want to clean up the blueprints now :-) | 19:38 |
| devananda | :) | 19:38 |
| dhellmann | I'll make a next-liberty milestone, and you can put anything there that's been done in liberty | 19:39 |
| dhellmann | that will be renamed to 4.0.0 when we cut the release | 19:39 |
| devananda | cool | 19:39 |
| devananda | once that's created, i'll move things that are currently targeted to l1, l2, l3 to that | 19:39 |
| dhellmann | ok, that's done | 19:40 |
| devananda | actually, simply deleting l1, l2, l3 should free those items up, yes? | 19:40 |
| devananda | "fix committed" bugs will get picked up when we close next-liberty | 19:40 |
| dhellmann | yes, that's right | 19:41 |
| dhellmann | it picks up all of them, whether they are in a milestone or not | 19:41 |
| dhellmann | bugs, but not blueprints | 19:41 |
| devananda | right | 19:41 |
| devananda | ok - milestones deleted | 19:43 |
| devananda | lets see if I can figure out ttx' scripts again :) | 19:43 |
| dhellmann | those tend to work best when there are a bunch of blueprints in a certain state | 19:44 |
| dhellmann | in this case, it might be simpler to just update them one by one | 19:44 |
| dhellmann | if you have a list, I can help | 19:44 |
| devananda | http://specs.openstack.org/openstack/ironic-specs/ | 19:45 |
| devananda | woops, better link | 19:45 |
| devananda | http://specs.openstack.org/openstack/ironic-specs/#implemented-in-liberty | 19:45 |
| dhellmann | those 4? | 19:46 |
| dhellmann | I'll do the 2nd 2 | 19:46 |
| devananda | also, part of our "new" release process would be to go through those and make sure folks have updated their spec to "done" when the work is done | 19:46 |
| devananda | I suspect a few of the "approved" are actually "implemented" right now | 19:46 |
| dhellmann | oops, I started with the first one | 19:46 |
| devananda | no worries, easy enough for me to do these | 19:47 |
| * devananda goes through the rest | 19:48 | |
| dhellmann | https://launchpad.net/ironic/+milestone/next-liberty looks good | 19:50 |
| devananda | give me a bit to review the rest of these specs | 19:50 |
| dhellmann | sure | 19:50 |
| dhellmann | devananda: I'm going to keep double verifying that you're ready for me to do steps before I do them, don't worry :-) | 19:51 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: fix ms2version.py use of print https://review.openstack.org/215719 | 20:15 |
| notmyname | devananda: patchbot is mine | 20:17 |
| dhellmann | notmyname: nice work | 20:19 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: pbr 1.5.1 https://review.openstack.org/216365 | 20:27 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: Add oslo.versionedobjects 0.8.0 deliverable https://review.openstack.org/212665 | 20:27 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: Oslo Releases for Aug 24, 2015 https://review.openstack.org/216415 | 20:27 |
| dims__ | dhellmann: 3 reviews to cover oslo releases this week - https://etherpad.openstack.org/p/library-releases | 20:29 |
| dhellmann | dims__: ok, I'll take a look shortly | 20:31 |
| devananda | dhellmann: I think https://launchpad.net/ironic/+milestone/next-liberty is accurate now, as far as BPs go | 20:32 |
| dhellmann | devananda: great, I think that means we're ready to tag your release! | 20:37 |
| dhellmann | devananda: I'll approve the release request now if you agree | 20:37 |
| devananda | dhellmann: do it | 20:45 |
| devananda | at least we have a few days to fix something if it breaks :) | 20:46 |
| dhellmann | right | 20:48 |
| * dhellmann finishes his expense report while waiting for the patch to land | 20:48 | |
| openstackgerrit | Merged openstack/releases: Add Ironic 4.0.0 https://review.openstack.org/214301 | 20:50 |
| dhellmann | devananda: the tag has been pushed. Release note generation failed to parse some info out of your readme, so I'll submit a patch to fix that | 21:02 |
| dhellmann | it's updating bugs now, and that may take it a while | 21:02 |
| dhellmann | devananda: you should +2a https://review.openstack.org/#/c/216388 in the mean time | 21:07 |
| dhellmann | that will then free up the ironic team to continue working | 21:07 |
| devananda | ack | 21:07 |
| dhellmann | devananda: launchpad is updated https://launchpad.net/ironic/+milestone/4.0.0 | 21:08 |
| devananda | approved | 21:08 |
| dhellmann | ok, the release job is still running but from my end everything looks ok | 21:09 |
| dhellmann | devananda: I'll work on the release notes script and send a release announcement tomorrow morning | 21:10 |
| dhellmann | ttx: I assume we still want to send release announcements for post-versioned server projects that aren't published to pypi? | 21:10 |
| devananda | dhellmann: so in the new world, the openstack liberty/stable branch of ironic will be based on the most current released version at that point | 21:11 |
| devananda | dhellmann: yes? | 21:11 |
| dhellmann | that's right | 21:11 |
| devananda | perfect | 21:11 |
| dhellmann | we won't create that branch yet, but it will be created from some tagged version we pick together | 21:11 |
| devananda | ++ | 21:11 |
| dims__ | dhellmann: all the jobs for the 3 reviews are green. fyi | 21:13 |
| dhellmann | dims__: do you want me to approve, and you do the releasing? | 21:14 |
| dims__ | dhellmann: sounds good | 21:14 |
| dims__ | yes please | 21:14 |
| *** dougwig has joined #openstack-relmgr-office | 21:14 | |
| dhellmann | dims__: is it easier for you to merge them one at a time, or should I go ahead and +a them? (otherwise I can +2 and let you +a) | 21:14 |
| * dougwig waves | 21:14 | |
| dhellmann | dougwig: o/ | 21:14 |
| dims__ | dhellmann: please +2 and i can +A | 21:15 |
| dhellmann | dims__: ack | 21:15 |
| dhellmann | lifeless, dims__ : for pbr 1.5.1 I see "Expose a 'rpm_version' extra command" -- is that a feature? | 21:15 |
| dhellmann | dims__: for oslo.versionedobjects, did you work out the nova issues? https://review.openstack.org/#/c/212665/ | 21:16 |
| dims__ | dhellmann: yep, done | 21:16 |
| dims__ | checking the pbr one | 21:16 |
| lifeless | dhellmann: bah humbug, ssssh :) | 21:18 |
| dims__ | LOL | 21:18 |
| * dhellmann smiles sweetly at lifeless | 21:18 | |
| dhellmann | dims__: +2 on those others, they look good | 21:19 |
| dhellmann | lifeless: if you have time for a quick review, https://review.openstack.org/216370 would be nice | 21:20 |
| lifeless | dhellmann: did you see my one on the i18n patch? | 21:20 |
| dhellmann | no? | 21:20 |
| dhellmann | lifeless: those are good points | 21:21 |
| lifeless | dhellmann: you were mid-ironic release discussion at the time | 21:21 |
| dhellmann | it came about 10 min after I approved, so we'll have to either revert or clean it up in another patch | 21:22 |
| dhellmann | dims__: you might want to hold off on the i18n release ^^ | 21:22 |
| dims__ | ack | 21:22 |
| dhellmann | lifeless: do you think it's worth reverting? I'm about to go start a fire to make dinner on :-/ | 21:22 |
| dhellmann | if we fix it in the next day or two, we could treat the update as a bug fix | 21:22 |
| dims__ | dhellmann: lifeless: holding off on i18n and pbr | 21:23 |
| lifeless | dims__: change the pbr thing to 1.6.0 ? | 21:23 |
| lifeless | dhellmann: update as bug fix would be fine I think | 21:24 |
| lifeless | dhellmann: your call really - you filed the bug :) | 21:24 |
| dims__ | lifeless: +1 if you are ok with that | 21:24 |
| dhellmann | lifeless: heh, if you don't think this is going to be worse than where we were, I'm fine with continuing to iterate on it | 21:24 |
| lifeless | dhellmann: I don't think its worse | 21:25 |
| lifeless | dhellmann: I don't think its necessarily better - and since I don't know what prompted the report I'm not qualified to know :) | 21:25 |
| lifeless | dhellmann: so I'm just giving things that occur to me when I think about the code in front of me | 21:25 |
| dhellmann | oh, I think someone pointed out that since we don't test translated strings a bad one could cause the service to fall over in unexpected ways | 21:25 |
| dhellmann | yeah, it has been so long since I thought about that problem I'm in the same mode, I just wasn't as thorough | 21:26 |
| *** gordc has quit IRC | 21:26 | |
| dims__ | so go for pbr as 1.6.0 - lifeless please update review | 21:26 |
| dims__ | i18n, release what we have | 21:27 |
| dims__ | ok dhellmann and lifeless | 21:27 |
| dhellmann | dims__: ++ | 21:27 |
| openstackgerrit | lifeless proposed openstack/releases: pbr 1.5.1 https://review.openstack.org/216365 | 21:28 |
| dims__ | lifeless: subject too :) | 21:28 |
| openstackgerrit | lifeless proposed openstack/releases: pbr 1.6.0 https://review.openstack.org/216365 | 21:28 |
| openstackgerrit | Merged openstack/releases: Make list-changes smarter https://review.openstack.org/216370 | 21:28 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: Fix formatting in process_bugs.py output https://review.openstack.org/216434 | 21:36 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: pbr 1.6.0 https://review.openstack.org/216365 | 21:44 |
| openstackgerrit | Merged openstack/releases: Add oslo.versionedobjects 0.8.0 deliverable https://review.openstack.org/212665 | 21:45 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: pbr 1.6.0 https://review.openstack.org/216365 | 21:48 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/releases: Oslo Releases for Aug 24, 2015 https://review.openstack.org/216415 | 21:48 |
| openstackgerrit | Merged openstack/releases: pbr 1.6.0 https://review.openstack.org/216365 | 21:52 |
| *** bnemec has joined #openstack-relmgr-office | 22:20 | |
| *** dims_ has joined #openstack-relmgr-office | 23:16 | |
| *** dims__ has quit IRC | 23:18 | |
| *** dims__ has joined #openstack-relmgr-office | 23:19 | |
| *** dims_ has quit IRC | 23:21 | |
| *** morganfainberg is now known as morgan | 23:42 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!