20:28:23 <prometheanfire> #startmeeting requirements 20:28:23 <openstack> Meeting started Wed Jul 18 20:28:23 2018 UTC and is due to finish in 60 minutes. The chair is prometheanfire. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:28:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:28:27 <openstack> The meeting name has been set to 'requirements' 20:28:31 <prometheanfire> #topic rollcall 20:28:34 <prometheanfire> tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann ping 20:28:37 <prometheanfire> o/ 20:28:42 <dhellmann> o/ 20:28:52 <prometheanfire> dirk said he couldn't be here iirc 20:30:19 <smcginnis> o/ 20:31:07 <prometheanfire> gonna wait a couple min for tony if able 20:32:05 <tonyb> \o 20:32:37 * tonyb wonders if Octonauts references would work with this group? 20:33:01 * dhellmann googles octonauts 20:33:10 * prometheanfire googles octonauts 20:33:17 <prometheanfire> that the switch thing? 20:33:37 <tonyb> that was pretty much what I thought :( 20:33:42 <tonyb> It's a kids TV show 20:33:46 <smcginnis> I'm well past that stage. :) 20:33:58 <tonyb> anyway let's do this meeting thing ;P 20:33:58 <dhellmann> so, nothing to do with october 20:34:03 <prometheanfire> #topic Any controversies in the Queue? 20:34:17 <smcginnis> Is it being broken controversial? 20:34:50 <prometheanfire> lol 20:34:51 <dhellmann> is the pypi mirror still causing trouble, or is there something else? 20:34:59 <prometheanfire> just the mirror, ya 20:35:01 <tonyb> hehe I dont' see any controversies, but clearly it's broken and we wanted to talk about post releases 20:35:19 <prometheanfire> ok 20:35:29 <prometheanfire> #topic brokenness 20:35:33 <tonyb> prometheanfire: are infra on it? or should I monitor that during my day 20:35:47 <prometheanfire> they are 20:35:50 <smcginnis> There's a patch in gate right now to fix it. 20:35:51 <tonyb> \o/ 20:36:04 <smcginnis> Or at least work around it for now. 20:36:15 <prometheanfire> just pinged mordred about it 20:36:27 <prometheanfire> still bad 20:36:38 <smcginnis> Oh, looks like the one they hoped would get around it merged: https://review.openstack.org/#/c/583571/ 20:36:42 <tonyb> Ahh okay, that kind of broken I thought it was just the normal bindersnatch thing 20:36:48 <prometheanfire> anyway, once it's fixed we can update the uc on networkx and the two google libs 20:37:02 <tonyb> is there a 30sec summary of the problem? 20:37:13 <prometheanfire> they ran out of space 20:37:29 <tonyb> Oh okay that's well less that 30secs 20:37:30 <prometheanfire> said it'll be fixed in 15 minutes or so 20:37:30 <smcginnis> Taskflow uploads ~500m of packages nightly. Mirroring locally got too big. 20:37:42 <smcginnis> Darn storage. 20:37:43 <dhellmann> I guess we need a bandersnatch->swift converter 20:37:52 <smcginnis> I saw some discussion of that. 20:37:54 <prometheanfire> 500M for taskflow? 20:37:58 <smcginnis> prometheanfire: Yep 20:38:01 <tonyb> smcginnis: Really? what are they uploading? 20:38:01 <prometheanfire> wow 20:38:08 <smcginnis> The world? 20:38:10 <dhellmann> what on earth 20:38:22 <smcginnis> I guess some of the ML stuff is pretty big for some reason. 20:38:25 <tonyb> dhellmann: I dont' think so I think that the mirrors are staycing on AFS it's only logs that are moving 20:38:35 <dhellmann> tonyb : yeah, I meant for the future 20:38:52 <prometheanfire> anyway, moving on then 20:38:59 <prometheanfire> #topic freeze 20:39:23 <dhellmann> smcginnis : tensorflow? 20:39:37 <prometheanfire> I'll need to find more mr freeze puns, maybe rewatch batman & robin 20:39:38 <smcginnis> Oh, sorry. Yes, tensorflow. 20:39:48 <prometheanfire> the things I suffer for you 20:39:50 <dhellmann> ok, whew. 20:39:56 <tonyb> smcginnis, dhellmann: Oh that makes away mmore sense! 20:39:56 <smcginnis> prometheanfire: :D 20:40:06 <dhellmann> prometheanfire : I hear they're rebooting the iceman comics 20:40:08 <tonyb> the earth stops shaking ;P 20:40:12 <prometheanfire> dhellmann: :D 20:40:24 <smcginnis> Heh, sorry. That would be really bad if taskflow was that big. 20:40:31 <prometheanfire> this freeze should be easier because of the per-project reqs 20:40:33 <dhellmann> well, we could at least do something about that :-) 20:40:37 <tonyb> With the freeze and pre-project requirements we need to think a little about minimum bumping 20:41:37 <prometheanfire> this is still the process https://etherpad.openstack.org/p/requirements-cycle-process 20:41:41 <tonyb> in that say (bad example) oslo.privsep adds a new API/constant today and it merges and is released next week at what point can python-swiftclient bump the minimum to require that (for them)? 20:42:10 <tonyb> what about say $clientlibrary that is pulled into python-openstackclient? 20:42:38 <dhellmann> as long as the u-c list isn't changed, does it matter? 20:42:41 <prometheanfire> they could bump it immediately, as long as their min is not over our UC 20:43:03 <prometheanfire> packagers would need to look at swifts lower-constraints to find swifts min 20:44:11 <tonyb> dhellmann: I'm not sure, which is why I'm asking ;P I feel like if python-openstackclient took bumped a minimum that kinda of implies that they'd like a release and uc bump 20:44:22 <tonyb> which I guess will all come out in the exception proecess 20:44:36 <tonyb> I just wanted to discuss it ahead of time 20:44:39 <dhellmann> sure 20:44:44 <prometheanfire> so you want to make sure that their reqs are in any given release? 20:44:46 <dhellmann> I'm also making sure I'm not missing something :-) 20:45:04 <tonyb> prometheanfire: Yup and we have dhellmann build tool to make life slightly easier for packagers to work that out 20:45:17 <dhellmann> I do think if we end up needing a release of a library for a bug fix, we need to coordinate the u-c update ahead of time. But I think we generally do that in this period of the cycle anyway, right? 20:45:38 <prometheanfire> tonyb: ya, you talking about the global-lc.txt builder? 20:45:50 <dhellmann> we don't want to have a case where we release a library and then don't allow the u-c update, because then we have a thing out in the wild that we're not using in our own tests 20:45:54 <tonyb> prometheanfire: Yup 20:46:34 <prometheanfire> ok, anything else for now about the freeze? 20:46:52 <tonyb> dhellmann: Yup I agree and I guess without the bot updates a release is less impactful in that only projects that are actually impacted by the bug need to update 20:47:09 <tonyb> and if a project works that out after the fact the fixed version shoudl be available 20:47:14 <dhellmann> tonyb : ideally we wouldn't update minimums just for bug fixes, but yeah 20:48:00 <tonyb> dhellmann: true, but it does happen esp when a bug fix changes an API (by say adding a new kwarg) 20:48:19 <prometheanfire> yarp 20:48:29 <dhellmann> tonyb : sure 20:48:53 <tonyb> it may be I'm over thinking ia and worrying too much due to not enough coffee 20:49:33 <dhellmann> nah, it's good to review this stuff 20:49:43 <prometheanfire> ya, just in case 20:49:46 <dhellmann> maybe we should write the reasoning down so we don't have to think so hard next time :-) 20:50:03 <prometheanfire> dhellmann: formalizing the release process for reqs would be nice 20:50:05 <tonyb> dhellmann: good plan 20:50:12 <prometheanfire> turning https://etherpad.openstack.org/p/requirements-cycle-process more official 20:50:19 <dhellmann> yeah, that made a big difference in our confidence on the release team 20:50:20 <tonyb> prometheanfire: want to add something to the end of that etherpad 20:50:33 <prometheanfire> tonyb: go ahead? 20:50:41 <dhellmann> we have a rst file in the releases repo now; that etherpad could move over to the requirements repo eventually 20:50:46 <tonyb> prometheanfire: +1 having some process docs in repo (like releases) would be good 20:50:56 <tonyb> dhellmann: snap :_ 20:51:00 <smcginnis> That might be a good place for that. 20:51:00 <dhellmann> maybe that's a project for stein 20:51:44 <tonyb> prometheanfire: I mean *can you* add something to the end of that etherpad (or PROCESS.rst) 20:52:10 <prometheanfire> tonyb: of course, it's just a review away 20:52:11 <tonyb> dhellmann: I feel like we can start now. it has no material impact on the release 20:52:33 <tonyb> prometheanfire: cool 20:52:43 <dhellmann> oh, sure, I just meant that we could be deliberate about updating it throughout the cycle at different points where the rules change or whatever 20:52:47 <prometheanfire> #topic open floor 20:52:55 <tonyb> so we have 8mins left do we want to discuss post releases in general? 20:53:00 <tonyb> and pyldap specifically? 20:53:01 <dhellmann> do we have any topics lined up to discuss at the ptg? 20:53:11 <dhellmann> oh, sure, that's more important, let's do that 20:53:12 <prometheanfire> tonyb: sure 20:53:33 <prometheanfire> dhellmann: I think I'll start thinking about ptg next week (after freeze) 20:53:40 <dhellmann> makes sense 20:53:45 * tonyb wont be at the PTG but if y'all want to hangouts me into anything I can be available pening TZs 20:53:55 <dhellmann> aw! 20:54:03 <prometheanfire> tonyb: but you'll miss the choo choo puting you to sleep 20:54:06 <smcginnis> That's unfortunate. 20:54:09 <tonyb> dhellmann, smcginnis: goes for rleases to 20:54:22 <prometheanfire> tonyb: so, post release? 20:54:23 <dhellmann> yeah, we'll keep that in mind 20:54:30 <tonyb> so post releases 20:54:31 <smcginnis> tonyb: Thanks. If we have some topics we'll try to find a convenient time. 20:54:34 <dhellmann> so, what's the deal with post releases? why are we worried about them? 20:54:54 <tonyb> I think they got lumped with pre releases and theer was some unreasonable FUD about accepting them 20:55:05 <dhellmann> ah, ok 20:55:10 <tonyb> I think we shoudl at a minimum evealuate each, if not just accept them 20:55:20 <dhellmann> iirc, the only reason we don't like pre-releases is that pip needs special instructions to install them 20:55:29 <dhellmann> does that apply to post releases? 20:55:30 <prometheanfire> oh, those .post releases 20:55:39 <tonyb> and pyldap is a trivial one to accept as it's litterally the same code as 3.0.0 20:55:53 <prometheanfire> I think we should just accept them 20:56:15 <prometheanfire> we don't need to disable pre-releases because they are already disabled by default 20:56:28 <prometheanfire> that would make my review not needed 20:56:31 <tonyb> dhellmann: I thought there was more it it than that in that there is a perception that they're more risky 20:56:44 <dhellmann> I guess I don't understand that perception 20:57:01 <tonyb> put perhaps that's linked to pre releases of $major bumps 20:57:02 <dhellmann> if the same package was tagged with a new version number we wouldn't even behaving the conversation, right? 20:57:03 <prometheanfire> doesn't debian have something like that? 20:57:09 <prometheanfire> 1.2.3-2 20:57:15 <prometheanfire> gentoo has 1.2.3-r2 for instance 20:57:22 <prometheanfire> it's the same concept 20:57:40 <tonyb> dhellmann: that's true 20:57:46 <prometheanfire> this is a question of if we allow revision bumps, I can't see a reason why 20:57:53 <prometheanfire> s/why/why not 20:57:53 <dhellmann> perhaps we should treat them like any other update, and let the test jobs evaluate them on a case-by-case basis 20:58:09 <tonyb> I guess some of it came from before we had the cross-project gateing we have now 20:58:31 <dhellmann> hmm 20:58:36 <prometheanfire> so, everyone fine with just allowing them? if so I'll drop my review 20:58:43 <dhellmann> +1 for allowing them 20:58:54 <tonyb> prometheanfire: for varying values of fine ;P 20:59:00 <dhellmann> at least until things blow up in our face, I guess :-) 20:59:06 <tonyb> but yeah I think I'm good with it 20:59:14 <prometheanfire> sgtm 20:59:27 <tonyb> dhellmann: at least a u-c (partial) revert is easy 20:59:33 <dhellmann> yeah 21:00:03 <tonyb> .pre/.post releases for EVERYBODY ;p 21:00:03 <prometheanfire> tonyb: anything else? 21:00:14 <tonyb> prometheanfire: I don't think so 21:00:28 <prometheanfire> tonyb: I don't think pre-releases are good, but those have to be manually proposed anyway 21:00:43 <tonyb> prometheanfire: not all of them 21:00:44 <prometheanfire> ok, going to endmeeting 21:00:54 <prometheanfire> #endmeeting