| *** sigmavirus24 is now known as sigmavirus24_awa | 00:22 | |
| *** armax has joined #openstack-relmgr-office | 02:10 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 02:23 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 02:53 | |
| *** sigmavirus24_awa has quit IRC | 03:25 | |
| *** jroll has quit IRC | 03:26 | |
| *** jroll has joined #openstack-relmgr-office | 03:31 | |
| *** sigmavirus24_awa has joined #openstack-relmgr-office | 03:31 | |
| *** sigmavirus24_awa has joined #openstack-relmgr-office | 03:31 | |
| *** ig0r__ has joined #openstack-relmgr-office | 04:58 | |
| *** ig0r_ has quit IRC | 04:59 | |
| *** armax has quit IRC | 06:28 | |
| ttx | lifeless: re: netaddr 0.7.16 release causing breakage, wondering why the constraints stuff didn't prevent it... It still is at ==0.7.15 there | 08:48 |
|---|---|---|
| openstackgerrit | Merged openstack-infra/release-tools: Document library release process https://review.openstack.org/217307 | 09:06 |
| *** ig0r_ has joined #openstack-relmgr-office | 09:37 | |
| *** ig0r__ has quit IRC | 09:39 | |
| *** gordc has joined #openstack-relmgr-office | 11:43 | |
| *** openstackgerrit has quit IRC | 11:46 | |
| *** openstackgerrit has joined #openstack-relmgr-office | 11:47 | |
| sdague | ttx: because it doesn't work on unit tests | 12:18 |
| sdague | all these failures are on unit tests | 12:19 |
| ttx | sdague: Ah, thought I had seen a few integration tests fail, but maybe those were just accidental | 12:23 |
| sdague | yeh, right now it looks like neutron and horizon unit tests | 12:24 |
| dhellmann | good morning | 12:53 |
| * dhellmann is glad to not have any travel lined up for a few weeks | 12:53 | |
| ttx | dhellmann: ready for meeting? | 13:01 |
| dhellmann | ttx: sorry, yep | 13:06 |
| *** superdan is now known as dansmith | 13:35 | |
| *** dims has joined #openstack-relmgr-office | 13:36 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:56 | |
| ttx | dhellmann: switching from pre to post is relatively easy. Just do the setup.cfg bump when the branch is cut as usual, then at some point after tag .0a0 and remove setup.cfg version | 14:01 |
| dhellmann | for the version updating, I have in mind something like: tag release x.y.z ; create stable branch ; commit minor update to master ; tag master (maybe using an alpha version like x.y+1.0.a1 or just x.y+1.0) | 14:01 |
| ttx | right -- the "commit minor update" part is where setup.cfg was easier: it IS a commit, so you can just branch from the commit before that | 14:02 |
| dhellmann | yes, we tried to be very careful with the ironic switch because I was worried about having 2 patches with the same version | 14:02 |
| dhellmann | we haven't actually tagged ironic master with a new version, yet | 14:02 |
| ttx | also that "minor update" will genrate a conflict with the equivalent one on stable branch | 14:03 |
| dhellmann | oh, we don't have a stable branch for ironic yet, either so that's ok | 14:03 |
| ttx | but it's a short window | 14:03 |
| dhellmann | yes, that's what I was worried about | 14:03 |
| dhellmann | I think we're going to have a 4.0.1 for ironic before they create their stable branch | 14:04 |
| *** bnemec has joined #openstack-relmgr-office | 14:05 | |
| dhellmann | if we start adding stable branch release notes to the main docs, one minor commit we'll always have is to add the page for the new stable branch | 14:05 |
| ttx | so there is no way to avoid the duplicate. You have to tag a different commit and it will generate a wrong number | 14:06 |
| dhellmann | assuming we want each series on its own page | 14:06 |
| ttx | before generating a good one | 14:06 |
| dhellmann | yeah | 14:06 |
| dhellmann | :-/ | 14:07 |
| ttx | Taking notes | 14:07 |
| dhellmann | I wonder, if we were tagging releases more often, if people would not deploy from master directly. | 14:08 |
| dhellmann | maybe we don't really want to do that, I'm just thinking out loud | 14:09 |
| *** jroll has quit IRC | 14:09 | |
| *** jroll has joined #openstack-relmgr-office | 14:09 | |
| ttx | dhellmann: we already have the issue with cycle-with-intermediary things | 14:12 |
| dhellmann | how does swift handle this? | 14:13 |
| ttx | historically they didn't do stable series, so they did not encounter this. But notmyname already said that the .y bump on master was not a good idea | 14:14 |
| ttx | since they want to be able to do bugfix-only releases at the start of a cycle | 14:15 |
| ttx | and the .y bump kind of communciates otherwise | 14:15 |
| dhellmann | yeah | 14:15 |
| ttx | but then I think it's more of a mindshift | 14:16 |
| ttx | if they want to do a bugfix-only release they should just do it on the stable branch | 14:16 |
| ttx | and land features on master | 14:16 |
| ttx | but "releasing 4.1.0" is kind of an issue for them | 14:17 |
| ttx | it's like they would benefit from starting the branch in preversion | 14:18 |
| ttx | (it's like everyone would) | 14:18 |
| dhellmann | "starting the branch in preversion"? | 14:18 |
| ttx | i.e. start of a new master branch you push the "next y" in setup.cfg ans start generating 4.1.0pre1243 thingies until you're ready to tag 4.1.0 | 14:19 |
| dhellmann | so master would be post-version and stable would be pre-version? | 14:19 |
| ttx | no, stable is post, and master is pre until the first tag there | 14:19 |
| ttx | that solves all issues | 14:19 |
| dhellmann | that's more or less what we have now, isn't it? | 14:20 |
| ttx | le me script it in the etherpad | 14:20 |
| ttx | not really, pre stays pre | 14:20 |
| dhellmann | oh, I thought we were doing post-versioning in stable branches | 14:22 |
| ttx | dhellmann: it's a bit of a mess currently | 14:24 |
| dhellmann | ttx: your proposal does eliminate the duplicate version problem, though I'm not sure it's really any easier to understand. Let me think about it some more. | 14:33 |
| ttx | yep, it's like the CAP theorem, pick to between simple consistent and accurate | 14:33 |
| ttx | two* | 14:33 |
| ttx | mine is consistent and accurate, yours is consistent and simple :) | 14:34 |
| dhellmann | right | 14:34 |
| ttx | now we need to find which would be simple and accurate :) | 14:34 |
| ttx | probably current situation | 14:34 |
| dhellmann | no stable branches? :-) | 14:34 |
| ttx | (two separate processes) | 14:34 |
| ttx | I kinda like that we solve the "obligation to bump y" with my proposal though | 14:35 |
| dhellmann | yeah, that does seem like an improvement | 14:35 |
| ttx | which will become more and more of a problem as we add intermediary-released things | 14:36 |
| dhellmann | I'll experiment with what happens with pbr if there's a commit after the tag that doesn't update setup.cfg | 14:36 |
| dhellmann | the release automation is going to need to have the release model accurately expressed in a repository | 14:36 |
| dhellmann | I don't think we want to rely on governance tags for switching between these modes for a given project | 14:37 |
| ttx | agreed. Although with my model everything follows the same pattern. The only difference is whether you tag betas/rcs or not | 14:38 |
| ttx | so then it's easy to switch everyone to the same model (no betas tagged) | 14:38 |
| dhellmann | so you're proposing we do this for libs, too? | 14:39 |
| ttx | I don't see why not | 14:39 |
| dhellmann | makes sense | 14:39 |
| dhellmann | I wasn't thinking of that, but it wouldn't hurt | 14:39 |
| ttx | like I say on the pad, I think 2 simple systems is more complex than a single complex one. | 14:39 |
| dhellmann | yeah | 14:40 |
| ttx | it's not as if pbr didn't support both already | 14:40 |
| ttx | heck, once it's in place we don't really care if a project does betas or not | 14:41 |
| ttx | since there is less adherence in the tooling and processes | 14:42 |
| ttx | ok, let's give it more thought over the week, see if it still sounds sane one week from now | 14:42 |
| dhellmann | sounds good | 14:42 |
| * dhellmann moves inside to avoid the yard service crew | 14:43 | |
| dhellmann | ttx: I was going to suggest to mriedeman that we not manage sqlalchemy-migrate releases using the releases repo, as in https://review.openstack.org/#/c/218607/ and just do the tags | 14:49 |
| dhellmann | I don't know if we want versions of that lib associated with releases of openstack, since none of our project teams own that library | 14:49 |
| *** dims has quit IRC | 14:51 | |
| ttx | yeah, sounds unmanaged to me | 14:51 |
| openstackgerrit | Doug Hellmann proposed openstack/releases: Release Aodh 1.0.0 https://review.openstack.org/217766 | 14:58 |
| openstackgerrit | Doug Hellmann proposed openstack/releases: Handle errors from git describe https://review.openstack.org/218892 | 14:58 |
| *** dims has joined #openstack-relmgr-office | 15:03 | |
| *** bnemec has quit IRC | 15:04 | |
| *** bnemec has joined #openstack-relmgr-office | 15:09 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 15:09 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 15:17 | |
| *** wshao_ has joined #openstack-relmgr-office | 15:24 | |
| *** david-ly_ has joined #openstack-relmgr-office | 15:31 | |
| *** david-ly_ is now known as david-lyle_ | 15:33 | |
| *** david-lyle has quit IRC | 15:33 | |
| *** david-lyle_ is now known as david-lyle | 15:35 | |
| *** TravT_ is now known as TravT | 15:52 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 15:59 | |
| *** wshao_ has quit IRC | 15:59 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 16:01 | |
| *** armax has joined #openstack-relmgr-office | 16:15 | |
| david-lyle | If someone has a chance can you please approve https://review.openstack.org/#/c/216469/ I need to cut another release of django_openstack_auth with the updated requirements for Liberty. | 16:20 |
| david-lyle | it's a Django supported versions change to coincide with upstream Django support | 16:21 |
| *** TravT has quit IRC | 16:23 | |
| *** TravT has joined #openstack-relmgr-office | 16:24 | |
| dhellmann | david-lyle: upper-constraints.txt has Django===1.7.10 so you probably want to update that, too | 16:24 |
| david-lyle | dhellmann: ok, didn't realize | 16:25 |
| david-lyle | is that scripted or manual? | 16:25 |
| dhellmann | there's a script to update it, so maybe that's what lifeless was counting on | 16:25 |
| dhellmann | there's an automated job, that is, but I find it makes more sense to update it with the requirements range change, esp. in this case where you're saying we're testing with an unsupported version | 16:26 |
| david-lyle | so just the latest 1.8 release? | 16:26 |
| dhellmann | david-lyle: yeah, you want to set that to the version you actually want us testing with in devstack-gate jobs (it doesn't apply to unit tests, yet) | 16:27 |
| david-lyle | ok, will that update with newer 1.8.* releases? | 16:27 |
| dhellmann | I think the automated job does propose updates for patch releases, yes | 16:28 |
| david-lyle | ok and in the meantime we know that say 1.8.6 is good | 16:28 |
| openstackgerrit | Merged openstack/releases: Add Austin and Bexar index pages https://review.openstack.org/218168 | 16:32 |
| openstackgerrit | Merged openstack/releases: Reorder releases https://review.openstack.org/218186 | 16:33 |
| notmyname | dhellmann: ttx: it's easy to do a Y version bump at the start of the cycle (or "simple", if you prefer). I'm completely ok with that. Yes, I think it limits some flexibility. but I also think it's a totally minor thing to do | 16:33 |
| *** lifeless has quit IRC | 16:34 | |
| david-lyle | dhellmann: add upper-constaints.txt change for Django patch | 16:34 |
| david-lyle | thanks | 16:34 |
| dhellmann | notmyname: cool. it's a little tricky, because we need some patch to land, and because for a brief window we have pbr generating the same version # for 2 separate patches (on different branches). So ttx's proposal avoids that window at the expense of a bit of complexity | 16:36 |
| dhellmann | david-lyle: looking | 16:37 |
| dhellmann | david-lyle: +2a | 16:38 |
| *** lifeless has joined #openstack-relmgr-office | 16:41 | |
| david-lyle | dhellmann: thank you | 16:49 |
| *** dims has quit IRC | 16:55 | |
| *** dims has joined #openstack-relmgr-office | 17:29 | |
| *** dims_ has joined #openstack-relmgr-office | 17:30 | |
| *** dims has quit IRC | 17:30 | |
| dims_ | dhellmann: should our upper-constraints stuff have caught netaddr? | 17:38 |
| *** ig0r__ has joined #openstack-relmgr-office | 17:43 | |
| *** ig0r_ has quit IRC | 17:46 | |
| sdague | dims_: no, it was unit tests and kilo | 17:47 |
| sdague | it caught it in master / dsvm jobs | 17:47 |
| dims_ | sdague: nice! | 17:47 |
| sdague | so it worked as expected, where it was implemented | 17:47 |
| dims_ | right | 17:48 |
| lifeless | ttx: 'unit tests' | 18:06 |
| sdague | oh, lifeless I saw the damnest fail this morning wrt requirements, let me go find the log | 18:30 |
| lifeless | sdague: k | 18:33 |
| lifeless | sdague: so - I really want to move forward on unit test contraints | 18:33 |
| lifeless | sdague: and not block until we've got one-click-dev-support | 18:33 |
| lifeless | sdague: devs can opt in easily enough right from the start | 18:33 |
| lifeless | sdague: it will be no -worse- than the status today | 18:34 |
| sdague | lifeless: ok, as long as it evolves towards an intergrated experience | 18:34 |
| sdague | lifeless: that's where I disagree, because of the confusion of local reproduce | 18:34 |
| sdague | but there will be a tradeoff of more working gate | 18:34 |
| sdague | lifeless: here is the failure - http://logs.openstack.org/86/218286/1/gate/gate-tempest-dsvm-neutron-full/f070942/logs/devstacklog.txt.gz#_2015-08-31_12_54_59_018 | 18:37 |
| sdague | it's a permissions denied failure to write the temp file | 18:37 |
| sdague | it's shown up twice | 18:37 |
| sdague | http://logstash.openstack.org/#eyJzZWFyY2giOiJcInVwcGVyLWNvbnN0cmFpbnRzLnR4dC50bXBcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQ0MTA0NjE4MTE3NX0= | 18:37 |
| sdague | I have no idea why that would be a race or what it could be racing on | 18:38 |
| *** ig0r__ has quit IRC | 18:48 | |
| lifeless | thats bizarre | 18:50 |
| lifeless | -> -dev | 18:51 |
| lifeless | or -qa perhaps? | 18:51 |
| morgan | dhellmann, ttx. Want to sync up re: m3 when you have a little time. | 18:51 |
| dims_ | sdague: lifeless: found one more occurance not related to edit-constraints though - http://logs.openstack.org/07/202207/18/gate/gate-neutron-lbaasv2-dsvm-api/4e704ba/console.html#_2015-08-30_04_17_05_454 | 18:55 |
| jroll | does each deliverables/liberty/*.yaml need its own launchpad? what do I do for a library (ironic-lib) that shares a launchpad with another project (ironic) | 18:56 |
| jroll | dhellmann: ^ | 18:56 |
| openstackgerrit | Jim Rollenhagen proposed openstack/releases: Add initial ironic-lib release https://review.openstack.org/218985 | 18:57 |
| jroll | relevant patch ^ | 18:57 |
| jroll | not sure if that works as expected though :) | 18:57 |
| dims_ | dhellmann: ttx: when is g-r freeze? | 19:01 |
| dhellmann | morgan: let me know when you're back to talk about L3 | 19:17 |
| morgan | Back | 19:17 |
| morgan | I didnt go far ;) | 19:17 |
| dhellmann | jroll: things that share a launchpad project are considered the same deliverable, and would be tagged together. if that's not true, you need separate launchpad projects | 19:17 |
| dhellmann | dims_: it should be this week, except I think for oslo stuff, but we should confirm that with ttx | 19:18 |
| dhellmann | morgan: hi! | 19:18 |
| dims_ | dhellmann: y, was wondering when i can release oslo.libs with g-r and translation updates | 19:18 |
| morgan | dhellmann: hope to ask for keystoneauth 1.0 this week too fwiw | 19:18 |
| dhellmann | morgan: sooner is better | 19:19 |
| morgan | Not that it has to hit g-r because nothing uses it. | 19:19 |
| morgan | But it would be nice to 1.0 it before g-r freeze | 19:19 |
| dhellmann | dims_: good question, and I'm not seeing that date called out on https://wiki.openstack.org/wiki/Liberty_Release_Schedule | 19:19 |
| morgan | Just so we are able to start working with it. | 19:19 |
| morgan | G-r freeze has historically been feature freeze. | 19:20 |
| dhellmann | yeah, that's thursday | 19:20 |
| morgan | So oslo probably follows right after that | 19:20 |
| morgan | ? | 19:20 |
| morgan | Anyway. L3 keystone. | 19:21 |
| dims_ | g-r freeze -> oslo libs with g-r updates -> then other libs -> then services i guess | 19:21 |
| dhellmann | with the constraints system in place it should be possible to push that date out further, but I don't know if we've talked about actually changing it | 19:21 |
| dhellmann | dims_: since ttx is probably offline, do you want to send an email about the dates? | 19:21 |
| dims_ | dhellmann: ack will do | 19:22 |
| dhellmann | morgan: yes, let's talk milestone | 19:22 |
| morgan | So lots of stuff to muck with still this week. I hope we can get the few bps closed out | 19:22 |
| morgan | My goal is to have everything approved by tomorrow. | 19:22 |
| dhellmann | ok | 19:22 |
| morgan | And require FFE/punt till m if not approved | 19:23 |
| jroll | dhellmann: define "tagged together"? same version identifier? | 19:23 |
| dhellmann | morgan: ttx created https://launchpad.net/keystone/+milestone/liberty-rc1 for you to populate with the things blocking the release candidate | 19:23 |
| dhellmann | jroll: yes, same version same time | 19:23 |
| dhellmann | jroll: I think you want to set up a second launchpad bug tracker in this case | 19:23 |
| jroll | dhellmann: ok, anything special to make the launchpad? | 19:23 |
| jroll | agree | 19:23 |
| dhellmann | jroll: you should be OK if you follow the instructions in http://docs.openstack.org/infra/manual/creators.html related to LP | 19:24 |
| morgan | I hope rc1 is empty this time around :P | 19:24 |
| jroll | dhellmann: perfect, ty | 19:24 |
| dhellmann | jroll: thanks for staying on top of this! | 19:24 |
| dhellmann | morgan: it is right now, yes :-) | 19:24 |
| morgan | dhellmann: i just wanted to sync before we hit tomorrow. | 19:24 |
| dhellmann | sure | 19:25 |
| morgan | I will troll through any bugs tonight/tomorrow to see if they are l3 blocking (unlikely) | 19:25 |
| dhellmann | there's quite a few in-progress items in https://launchpad.net/keystone/+milestone/liberty-3 so if you want to look those over and remove any that aren't actual blockers that would be a good idea | 19:25 |
| morgan | or need to hit rc | 19:25 |
| morgan | Yah. | 19:25 |
| morgan | That is the plan | 19:25 |
| dhellmann | ++ | 19:25 |
| morgan | Ill also once-over keystone middleware | 19:25 |
| morgan | Client i want to check but we should plan a release on wednesday if anything has landed | 19:26 |
| morgan | Then we can evaluate g-r bump | 19:26 |
| morgan | Pycadf should be good. And like i said keystoneauth will hopefully be 1.0 this week. But not needing in g-r (but i would like it to be for sdk) | 19:27 |
| dhellmann | morgan: even if you don't need to update the mins for those releases, it would be good to make sure the constraint updates work so we're testing with the new releases | 19:27 |
| morgan | If we dont 1.0 keystoneauth i'd be "ok" with putting a 0.x in g-r but.... | 19:28 |
| morgan | I would rather not do a pre1.0 in g-r | 19:28 |
| jroll | dhellmann: one more thing, I assume I should follow all of the pypi bits etc in that doc? | 19:28 |
| morgan | dhellmann: thnx. | 19:28 |
| dhellmann | jroll: yes, if those haven't all been done already (would be good to check either way) | 19:29 |
| jroll | thanks | 19:29 |
| dhellmann | morgan: it sounds like you have it all in hand, thanks | 19:29 |
| openstackgerrit | Jim Rollenhagen proposed openstack/releases: Add initial ironic-lib release https://review.openstack.org/218985 | 19:33 |
| jroll | dhellmann: ^ should be good to go now, pypi exists and has openstackci user attached, https://launchpad.net/ironic-lib is a thing | 19:34 |
| jroll | it's already release:managed in governance | 19:34 |
| dhellmann | jroll: looks good, I'll go ahead and do that release now | 19:41 |
| jroll | thanks much! | 19:42 |
| * jroll preps g-r patch | 19:42 | |
| dhellmann | jroll: the check queue is pretty full, so it may take a while | 19:42 |
| jroll | yeah, no worries | 19:42 |
| jroll | so now, more philosophical question | 19:43 |
| jroll | I want to add this g-r unpinned in order to be able to use newer versions of it in ironic during reqs freeze | 19:43 |
| jroll | does upper-constraints break my assumption that this is possible? | 19:43 |
| dhellmann | yes | 19:43 |
| jroll | ok, so we can't use new releases of this during freeze, without getting a freeze exception | 19:44 |
| dhellmann | we'll also be more strict about actually doing releases during that freeze period | 19:44 |
| jroll | will exceptions be a big deal given only ironic uses this? | 19:44 |
| jroll | nod | 19:44 |
| dhellmann | part of the point of the freeze is to give deployers a still target for what to package | 19:44 |
| jroll | (eventually both ironic and ironic-python-agent will use this, but not yet) | 19:45 |
| jroll | right | 19:45 |
| dhellmann | so even though only ironic would use this, we would still be pretty strict about not updating just for feature work | 19:46 |
| dhellmann | because that could destabilize the gate for everyone else | 19:46 |
| jroll | realistically its refactoring work, but yeah I get it | 19:46 |
| jroll | yeah, transient deps etc | 19:46 |
| dhellmann | right | 19:46 |
| dhellmann | and ironic is installed from source in the gate. if we were installing servers from packages, that might make it a different story, but that has its own drawbacks -- punctuated integration periods being the biggest | 19:47 |
| jroll | sure | 19:47 |
| jroll | reqs freeze is this week? | 19:48 |
| dhellmann | I expect it to be thursday with the feature freeze | 19:48 |
| jroll | nod | 19:48 |
| jroll | alright, thanks much :) | 19:48 |
| dhellmann | jroll: I see quite a few unreleased changes in ironic, are you all planning to do a 4.1 release by the end of the cycle? | 19:49 |
| dhellmann | jroll: http://paste.openstack.org/show/435504 | 19:50 |
| jroll | dhellmann: yeah, so we have a couple patches we wanted to drop as 4.0.1 ASAP, and then a 4.1.0 around openstack RC time, to become stable/liberty | 19:50 |
| dhellmann | cool, sounds good | 19:50 |
| dhellmann | jroll: with c17108d in place, the next release should be 4.1 | 19:51 |
| dhellmann | the rest are bug fixes, it seems | 19:51 |
| dhellmann | but that's HEAD right now | 19:51 |
| jroll | dhellmann: why 4.1? | 19:51 |
| jroll | because library updates? | 19:51 |
| dhellmann | compatible requirements changes increment the minor version number | 19:51 |
| jroll | interesting | 19:52 |
| jroll | so basically almost every release will be a minor version bump | 19:52 |
| dhellmann | off of master, yes | 19:52 |
| jroll | yeah | 19:52 |
| jroll | I'm skeptical that we'll ever do a major version bump, since we never intend to require a breaking upgrade sort of thing | 19:53 |
| jroll | (it could happen, yes, but the goal is never) | 19:53 |
| dhellmann | yeah, we (as a community) need to talk about why we increment the major version # for servers | 19:53 |
| dhellmann | it might be useful to raise it each cycle, for example | 19:54 |
| jroll | indeed | 19:54 |
| dhellmann | breaking changes are sort of the obvious case, but we try to avoid those | 19:54 |
| jroll | I almost like swift's method, but it definitely isn't semver | 19:54 |
| dhellmann | any time we have a schema migration rollup might be another, but those are seeming to go away, too | 19:54 |
| dhellmann | yeah, semver is sort of an odd fit for an API service | 19:54 |
| jroll | mhm | 19:55 |
| openstackgerrit | Matt Riedemann proposed openstack/releases: Release os-brick 0.4.0 https://review.openstack.org/219013 | 20:01 |
| *** david-lyle has quit IRC | 20:01 | |
| *** david-lyle has joined #openstack-relmgr-office | 20:06 | |
| notmyname | jroll: how so? (swift not being semver) | 20:07 |
| jroll | notmyname: AIUI the major version is "marketing based" | 20:07 |
| jroll | or that's what I've heard, at least | 20:07 |
| notmyname | lol | 20:07 |
| jroll | like "lots of new features" rather than "breaks backwards compat" | 20:07 |
| notmyname | we bumped from 1.x to 2.x because (1) yes there was a significant new feature (biggest ever) and it was good to have something that designated that. and (2) there were some upgrade+downgrade issues there. you can' really upgrade from 1.x to 2.x and then downgrade and still have access to all of your data | 20:09 |
| notmyname | so yes there were some marketing reasons :-) | 20:09 |
| jroll | heh | 20:09 |
| jroll | like I said, I kind of like it | 20:09 |
| jroll | it's better than "never bump major version ever" | 20:10 |
| notmyname | I look at is a way to communicate to users (ops) that I never have another chance of talking with | 20:11 |
| notmyname | I can stand up in front of a crowd or send an email, but most people will never see/read that | 20:11 |
| jroll | heh, yep | 20:11 |
| *** dims has joined #openstack-relmgr-office | 20:12 | |
| notmyname | but the version number is soemthing that everyone will see. so versioning major, minor, trival releases (so they know what to expect when packaging/deploying) is good | 20:12 |
| *** dims_ has quit IRC | 20:14 | |
| openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: clarify duties in library release process https://review.openstack.org/219017 | 20:18 |
| dhellmann | lifeless: can you give this a quick look? the bug is blocking some first-time releases: https://review.openstack.org/#/c/218892/1 | 20:55 |
| *** dims has joined #openstack-relmgr-office | 20:57 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 22:15 | |
| *** gordc has quit IRC | 23:02 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!