14:30:57 <fao89> #startmeeting Pulp Triage 2020-09-04 14:30:57 <fao89> #info fao89 has joined triage 14:30:57 <fao89> !start 14:30:57 <pulpbot> Meeting started Fri Sep 4 14:30:57 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:57 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:57 <pulpbot> The meeting name has been set to 'pulp_triage_2020-09-04' 14:30:57 <pulpbot> fao89: fao89 has joined triage 14:31:02 <ggainey> #info ggainey has joined triage 14:31:02 <ggainey> !here 14:31:02 <pulpbot> ggainey: ggainey has joined triage 14:32:45 <ipanova> #info ipanova has joined triage 14:32:45 <ipanova> !here 14:32:45 <pulpbot> ipanova: ipanova has joined triage 14:32:53 <dkliban> have we started? 14:32:59 <dkliban> i joined the channel late 14:33:09 <ipanova> waiting on quorum 14:33:10 <fao89> I'm waiting 3 people to join 14:33:27 <dkliban> #info dkliban has joined triage 14:33:27 <dkliban> !here 14:33:27 <pulpbot> dkliban: dkliban has joined triage 14:33:33 <fao89> !next 14:33:34 <fao89> #topic https://pulp.plan.io/issues/7459 14:33:34 <pulpbot> fao89: 6 issues left to triage: 7459, 7456, 7451, 7450, 7444, 7438 14:33:36 <pulpbot> RM 7459 - paji@redhat.com - NEW - Make the pulp exporter directories rwx for pulp group 14:33:37 <pulpbot> https://pulp.plan.io/issues/7459 14:33:43 <ttereshc> #info ttereshc has joined triage 14:33:43 <ttereshc> !here 14:33:43 <pulpbot> ttereshc: ttereshc has joined triage 14:34:02 <ggainey> partha reported this one this morning - accept and add to sprint pliz 14:34:02 <ppicka> #info ppicka has joined triage 14:34:02 <ppicka> !here 14:34:03 <pulpbot> ppicka: ppicka has joined triage 14:34:13 <x9c4> #info x9c4 has joined triage 14:34:13 <x9c4> !here 14:34:13 <pulpbot> x9c4: x9c4 has joined triage 14:34:14 <fao89> #idea Proposed for #7459: accept and add installer category 14:34:14 <fao89> !propose other accept and add installer category 14:34:14 <pulpbot> fao89: Proposed for #7459: accept and add installer category 14:34:24 <ggainey> whut? 14:34:31 <dkliban> yeah ... this is an installer bug that katello will need to also implement in their installer 14:34:32 <ipanova> this will change affect only exporters directory? 14:34:48 <ggainey> wait, this has nothing to do with installer 14:34:55 <dkliban> ggainey: please elaborate 14:35:15 <ggainey> when you create an exporter, you specify the directory you want it to use (at runtime) 14:35:29 <bmbouter> #info bmbouter has joined triage 14:35:29 <bmbouter> !here 14:35:29 <pulpbot> bmbouter: bmbouter has joined triage 14:35:51 <dkliban> ggainey: does that mean the user needs to set the right perms on the directory? 14:35:59 <ggainey> exporter-create calls os.makedirs() to create it, and it can result in it being mode 755 - which pulp can read/write, but katello can't write to 14:36:11 <ggainey> dkliban: currently yes 14:36:24 <ipanova> ggainey: gotcha 14:36:30 <ggainey> the ask is to have os.makedirs() called with mode 775, so group can write 14:36:47 <ggainey> (which feels reasonable to me) 14:36:58 <bmbouter> what user does katello run as? 14:37:24 <ggainey> I don't know the answer to tha one, I'm afraid 14:37:29 <ggainey> (not 'pulp' tho) 14:37:44 <x9c4> either foreman or apache 14:37:48 <dkliban> ggainey: so should we accept and add to sprint ? 14:37:56 <bmbouter> which solution are we going with? 14:37:57 <ggainey> dkliban: yes please, that's what I proposed 14:38:10 <dkliban> bmbouter: having pulp create the dir with 775 14:38:12 <ggainey> bmbouter: teach exporter to ask for 775 at makedirs() 14:38:22 <ipanova> can this be fixed here? https://github.com/pulp/pulp_installer/blob/master/roles/pulp_common/tasks/install.yml#L80 14:38:36 <fao89> #idea Proposed for #7459: accept and add to sprint 14:38:36 <fao89> !propose other accept and add to sprint 14:38:36 <pulpbot> fao89: Proposed for #7459: accept and add to sprint 14:38:45 <bmbouter> dkliban: ggainey ty 14:38:47 <bmbouter> ipanova: yes it can be 14:38:54 <ggainey> ipanova: you have No Idea where the user wants their exports to go - might be anywhere 14:38:57 <bmbouter> I just don't think we've considered the installation impleications of this 14:39:16 <bmbouter> mainly just FYI to mikedep333 ^ 14:39:27 <bmbouter> having the pulp group writeable I think is safe 14:39:33 <ggainey> aye 14:39:44 <mikedep333> looking now 14:39:58 <bmbouter> can we move on and mikedep333 can comment as needed later 14:40:04 <ggainey> sure 14:40:30 <ipanova> the reason i brought up the fix in the installer is because in pulp2 we also hardcode when os.makedirs, now we have problems that installer sets permissions we need but then pulp2 overrides them when creating dirs 14:40:32 <bmbouter> mikedep333: this would be an installer change to have posix perms include group=7 at that linked to line 14:40:39 <ipanova> this^ creates problems in the migration 14:41:06 <bmbouter> ipanova: I agree the installer is the place to fix this, instead of piecemeal at each makedir 14:41:10 * ipanova thinks far in the future 14:41:14 <mikedep333> That's an ACL though, not al FSs support them. 14:41:22 <mikedep333> I will continue discussion in the ticket. 14:41:32 <ggainey> bmbouter: ipanova : the thing is, we don't know what directory the user will want to use for exports - it can be anything under "ALLOWED_EXPORT/IMPORT_PATHS", which could be '/' 14:41:50 <ggainey> yes please, I think we're talking at cross-purposes 14:41:55 <ttereshc> I agree with ggainey 14:41:59 <ipanova> ggainey: i see 14:42:24 <ipanova> ok lets accept and continue the discussion on the ticket 14:42:25 <ggainey> (this directory isn't guaranteed to be set (or even exist!) at install-time) 14:42:25 <ipanova> +1 14:42:30 <ggainey> +1 14:42:45 <ttereshc> it still might be good to give pulp group write perms but it doesn't fully solve the import/export problem 14:42:50 <fao89> just accept ? or add to sprint? 14:42:56 <ggainey> accept-and-add please 14:43:02 <ttereshc> +1 14:43:02 <fao89> #agreed accept and add to sprint 14:43:02 <fao89> !accept 14:43:02 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:43:04 <fao89> #topic https://pulp.plan.io/issues/7456 14:43:04 <pulpbot> fao89: 5 issues left to triage: 7456, 7451, 7450, 7444, 7438 14:43:06 <pulpbot> RM 7456 - mdepaulo@redhat.com - POST - pulp_installer CI always updates the container to CentOS Stream 14:43:07 <pulpbot> https://pulp.plan.io/issues/7456 14:43:35 <ipanova> it is in post, accept and add to the sprint 14:43:44 <ggainey> +1 14:43:44 <ppicka> +1 14:43:47 <fao89> #idea Proposed for #7456: accept and add to sprint 14:43:47 <fao89> !propose other accept and add to sprint 14:43:47 <pulpbot> fao89: Proposed for #7456: accept and add to sprint 14:43:50 <fao89> #agreed accept and add to sprint 14:43:50 <fao89> !accept 14:43:50 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:43:50 <fao89> #topic https://pulp.plan.io/issues/7451 14:43:51 <pulpbot> fao89: 4 issues left to triage: 7451, 7450, 7444, 7438 14:43:52 <pulpbot> RM 7451 - dkliban@redhat.com - NEW - upgrading from 3.4 single container to 3.6 single container fails 14:43:53 <pulpbot> https://pulp.plan.io/issues/7451 14:43:53 <ttereshc> why not using the stream? 14:44:28 <fao89> #idea Proposed for #7451: Leave the issue as-is, accepting its current state. 14:44:28 <fao89> !propose accept 14:44:28 <pulpbot> fao89: Proposed for #7451: Leave the issue as-is, accepting its current state. 14:44:35 <dkliban> fao89: let's add to sprint 14:44:41 <dkliban> it's an easy fix 14:44:45 <dkliban> i'll comment on it 14:44:57 <ipanova> sounds good 14:45:11 <ggainey> +1 14:45:16 <ttereshc> do we use CentosStream in CI anywhere? just want to understand if we are testing it 14:45:21 <fao89> #idea Proposed for #7451: accept and add to sprint 14:45:21 <fao89> !propose other accept and add to sprint 14:45:22 <pulpbot> fao89: Proposed for #7451: accept and add to sprint 14:45:25 <fao89> #idea Proposed for #7451: Leave the issue as-is, accepting its current state. 14:45:25 <fao89> !propose accept 14:45:25 <pulpbot> fao89: Proposed for #7451: Leave the issue as-is, accepting its current state. 14:45:36 <dkliban> lol 14:45:51 <fao89> #idea Proposed for #7451: accept and add to sprint 14:45:51 <fao89> !propose other accept and add to sprint 14:45:51 <pulpbot> fao89: Proposed for #7451: accept and add to sprint 14:45:54 <fao89> #agreed accept and add to sprint 14:45:54 <fao89> !accept 14:45:54 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:45:54 <fao89> #topic https://pulp.plan.io/issues/7450 14:45:55 <pulpbot> fao89: 3 issues left to triage: 7450, 7444, 7438 14:45:56 <pulpbot> RM 7450 - jsherril@redhat.com - NEW - jinja2 missing from requirements.txt on 3.6.* 14:45:57 <pulpbot> https://pulp.plan.io/issues/7450 14:46:02 <dkliban> this one is arleady modified 14:46:05 <fao89> #idea Proposed for #7450: accept and add to sprint 14:46:05 <fao89> !propose other accept and add to sprint 14:46:05 <pulpbot> fao89: Proposed for #7450: accept and add to sprint 14:46:10 <dkliban> +1 14:46:13 <fao89> #agreed accept and add to sprint 14:46:13 <fao89> !accept 14:46:13 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:46:14 <fao89> #topic https://pulp.plan.io/issues/7444 14:46:14 <pulpbot> fao89: 2 issues left to triage: 7444, 7438 14:46:16 <pulpbot> RM 7444 - mdellweg - NEW - repository creation responds woth 201, while apidocs claim status code 200 14:46:17 <pulpbot> https://pulp.plan.io/issues/7444 14:46:31 <dkliban> we need to fix this one right away 14:46:38 <bmbouter> yup 14:46:41 <ipanova> +1 14:46:43 <ggainey> ah, yeah 14:47:04 <x9c4> I have a workaround for it, but i am wondering the bindings don't choke on this. 14:47:12 <fao89> #idea Proposed for #7444: accept and add to sprint 14:47:12 <fao89> !propose other accept and add to sprint 14:47:12 <pulpbot> fao89: Proposed for #7444: accept and add to sprint 14:47:26 <fao89> #agreed accept and add to sprint 14:47:26 <fao89> !accept 14:47:26 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:47:26 <fao89> #topic https://pulp.plan.io/issues/7438 14:47:27 <pulpbot> fao89: 1 issues left to triage: 7438 14:47:28 <pulpbot> RM 7438 - jsherril@redhat.com - NEW - create and update exporter should be async apis 14:47:29 <pulpbot> https://pulp.plan.io/issues/7438 14:48:28 <ggainey> yeah - justin noticed that deleting an exporter, while it was in the middle of creating an export, has undesireable side-effects - because delete (and update as well) are synchronous calls 14:48:40 <ttereshc> sounds reasonable to make them async 14:48:41 <ggainey> making them async makes them consistent with everything else 14:48:48 <ipanova> agreed 14:48:51 <ggainey> ttereshc: that was my thought, aye 14:48:52 <x9c4> sounds like an easy fix. 14:48:55 <ggainey> yupyup 14:48:59 <fao89> #idea Proposed for #7438: accept and add to sprint 14:48:59 <fao89> !propose other accept and add to sprint 14:48:59 <pulpbot> fao89: Proposed for #7438: accept and add to sprint 14:49:01 <ggainey> accept and add, is my request 14:49:06 <fao89> #agreed accept and add to sprint 14:49:06 <fao89> !accept 14:49:06 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:49:07 <pulpbot> fao89: No issues to triage. 14:49:10 <ttereshc> +1 14:49:12 <ggainey> coolio 14:49:23 <fao89> open floor 14:49:27 <dkliban> CI check ... 14:49:35 <fao89> https://hackmd.io/@pulp/triage/edit 14:49:49 <dkliban> pulp_rpm failed for the performance test https://travis-ci.com/github/pulp/pulp_rpm/jobs/380802656#L2039 14:49:58 <dkliban> the distribution tree did not sync 14:50:06 <fao89> same issue as before 14:50:10 <dkliban> cool 14:50:22 <ttereshc> I think ppicka will get to it after the proxy issue 14:50:24 <fao89> I believe epel 8 does not have distribution tree 14:50:32 <dkliban> and pulplift is failign 14:50:38 <dkliban> and i believe that's because of FIPS not working 14:50:43 <dkliban> which we are working on fixing 14:50:44 <ttereshc> yeah, it should be a simple fix with right constants 14:50:50 <ttereshc> for rpm 14:50:55 <dkliban> ttereshc: agreed 14:50:58 <ggainey> kk 14:51:00 <fao89> next topic: discussion: z-stream migrations allowed or not 14:51:22 <dkliban> After thinking about this I've decided that we should not release migrations as part of a Z stream for now 14:51:40 <dkliban> however, when the need arises in the future, we should be open to doing it with careful planning 14:51:54 <ggainey> dkliban: I've been watchiung the discussions on this, and it def feels like there are a lot of potential edges to get caught on 14:52:12 <ttereshc> I think we need to figure out now what is the way when the need comes 14:52:33 <ttereshc> just to ensure that there is a way to solve it properly 14:52:53 <ttereshc> I don't suggest to be a part of any process to request those 14:52:53 <ppicka> dkliban, ttereshc: didn't catch what is the issue, like perf test failing ? 14:53:04 <ttereshc> ppicka, yes 14:53:12 <dkliban> ppicka: https://travis-ci.com/github/pulp/pulp_rpm/jobs/380802656#L2039 14:53:25 <ppicka> ok thanks 14:53:27 <dkliban> ttereshc: so here are my thoughts on the process ... 14:53:57 <dkliban> when cherry-picking a migration to a Z stream, it may require re-ordering the migration 14:54:12 <dkliban> because each migration declares a 'dependency' migration 14:54:29 <ttereshc> yup 14:54:52 <dkliban> that re-ordering is only OK to do if none of the involved migrations have been released yet 14:55:20 <x9c4> Being on master is a form of "released". 14:55:47 <dkliban> x9c4: i don't agree ... being part of a tag is a form of being released 14:55:48 <ttereshc> ok, what to do downstream when there is a critical issue which needs to be fixed N releases back? 14:56:07 <dkliban> ttereshc: what we did before ... re-order migrations downstream 14:56:09 <ttereshc> a separate dependency tree? 14:56:13 <ttereshc> yeah 14:56:13 <dkliban> exactly 14:56:14 <ttereshc> ok 14:56:22 <bmbouter> I agree 14:56:24 <bmbouter> x9c4: 14:56:40 <ggainey> dkliban: and this will work when the user that applies this migration, then upgrades to the next release? 14:56:40 <dalley> danger will robinson 14:56:57 <dalley> is "separate dependency tree" something that would actually work? 14:57:37 <dalley> I'm not sure django keeps track of which migrations have been applied, they keep track of the last migration to be applied 14:57:47 <x9c4> yes, it does- 14:57:56 <bmbouter> in situations where a migration must be sent out "right away" we have a good alterantive, just release master 14:58:39 <bmbouter> we should not be reordering migrations on master it's complmicated and inefficient 14:58:53 <bmbouter> I'm also concerned that z-streams shouldn't have long upgrade run times in general, it's not what users expect 14:59:05 <x9c4> dalley, A plugin migration can depend on the second to last core migration, so django needs to know this. 14:59:06 <bmbouter> dkliban: how am I doing in my naysayer role? 14:59:21 <ggainey> heh 14:59:32 <ttereshc> dalley, you might be right that just re-ordering won't work 14:59:39 <bmbouter> dalley: I agree 14:59:43 <dalley> x9c4, ok. I remember having some problems with this back in like 2014/2015 but it may have been improved 15:00:00 <ggainey> actually - what I heard at the start here was, "For now we say 'no', and we don't allow it until we've got a good, well-defined process for it", yeah? 15:00:20 <dalley> python manage.py showmigrations wouldn't make a whole lot of sense if django still worked the way I just described 15:01:29 <ipanova> we should have more discussion around well-defined process, maybe on the mailiing list 15:01:36 <ggainey> +1 15:01:45 <dkliban> yep 15:01:57 <dkliban> so for right i suggest that we don't support cherry-picking migrations 15:02:08 <dkliban> and continue the discussion on the mailing list 15:02:13 <ipanova> +1 15:02:14 <ggainey> can we create a Task for this, whose output is a document for how it'll work? and not allow it for now? 15:02:17 <ggainey> dkliban++ 15:02:17 <pulpbot> ggainey: dkliban's karma is now 525 15:02:18 <ggainey> zacly 15:02:59 <dalley> x9c4, fwiw I think you are right, now 15:03:26 <dkliban> bmbouter: you did a great job 15:04:11 <fao89> next topic: 3.6.3 release check-in 15:04:14 <mikedep333> Possible solutions to the exporter write issue: https://pulp.plan.io/issues/7459#note-2 15:04:23 <ttereshc> I don't know if mailing list (pulp-dev) is a good place because the trickiest part is the downstream 15:04:36 * ttereshc is slow today with her comments 15:05:05 <bmbouter> ttereshc: I think that's ok it's not about X release, pulp having downstreams is not off-list to me 15:05:32 <ttereshc> ok 15:05:55 <bmbouter> if the upstream is driven by a downstream requirement I think putting that out there is healthy actually 15:06:32 <dkliban> one of our downstreams is katello 15:06:33 <ttereshc> I don't think upstream shoul do out-of-order migrations 15:06:49 <ttereshc> but it's a reality of downstream 15:07:15 <dkliban> and i think we want to just have the conversation in terms of katello and how we are going to be able to best serve that community 15:07:19 <bmbouter> agreed downstream's with separate source trees can curate patches all they want 15:07:38 <bmbouter> dkliban: I share that goal 15:08:17 <ggainey> works4me 15:08:56 <fao89> next topic: 3.6.3 release check-in 15:09:59 <fao89> next topic: 3.7.0 go/no-go release meeting times 15:10:14 <bmbouter> fao89: who is releasing 3.6.3? 15:10:17 <bmbouter> before we go on 15:10:20 <dkliban> i am doing it after lunch today 15:10:23 <bmbouter> ty! 15:10:34 <bmbouter> and I don't think we need an installer release do we? 15:10:49 <bmbouter> oh unless pulpcore specifies the z-version? 15:10:57 <dkliban> bmbouter: it does 15:11:08 <dkliban> the installer is always released with pulpcore 15:11:24 <dkliban> and either i or fao89 will do the installer release 15:12:26 <fao89> I'm starting to dislike the installer being so tied with pulpcore 15:12:48 <dkliban> fao89: we should discuss that in our installers meeting 15:12:55 <dkliban> fao89: want to add it to next week agenda? 15:12:55 <fao89> 3 collections version for just one variable 15:13:04 <fao89> sure 15:13:40 <bmbouter> dkliban: this plan sounds all good, ty 15:14:13 <fao89> I think go/no-go release meeting should be at pulpcore meeting one week before the release date 15:14:33 <dkliban> that sounds very reasonable to me 15:14:34 <ggainey> fao89: +1 15:15:16 <ttereshc> it will be pulpcon 15:15:36 <ttereshc> so someone needs to make sure that this meeting happens outside of pulpocn hours 15:15:44 <ipanova> yep 15:16:21 <bmbouter> can this be a chat meeting? 15:16:25 <dkliban> yes 15:16:29 <ggainey> absolutely 15:16:33 <ggainey> prob best that way 15:16:35 <bmbouter> here in #pulp-meeting 15:16:37 <dkliban> +1 15:16:41 <dkliban> yes bmbouter 15:16:42 <ggainey> +1 15:17:03 <bmbouter> can we put the details on the checklist ticket also? 15:18:06 <dkliban> thatwould be good 15:18:20 <bmbouter> do we have a 3.7.0 checklist ticket? 15:18:27 <dkliban> not yet 15:18:56 <bmbouter> all this would be good to do in prep, and probably anytime we have a release date identified 15:19:36 <fao89> next topic: will anyone be able to release pulp_rpm with the proxy fix? 15:19:38 <ggainey> bmbouter: yeah, was just thinking that - this could all happen the instant we propose a tentative date 15:20:19 <bmbouter> who can handle this for 3.7.0 specifically? 15:20:27 <bmbouter> and pick the go/no-go meeting time a week out? 15:21:31 <bmbouter> I can do this now actually 15:22:01 <ttereshc> I think it would be good if we identify who will do 3.7 release and they will do all the prep 15:22:27 <fao89> +1 15:23:26 <dkliban> i would volunteer but i feel like someone else should do it 15:23:36 <fao89> +1 15:24:13 <bmbouter> I agree, I can take 3.7.0 I think 15:24:47 <ttereshc> thank you 15:25:51 <ipanova> bmbouter: thanks! 15:26:14 <bmbouter> I'll make the 3.7.0 ticket now and schedule the meeting and advertise on pulp-dev 15:27:03 * ggainey cheers for bmbouter 15:27:08 <ggainey> wildly, even! 15:27:40 <fao89> next topic: remove the test_file_decriptors test from everywhere 15:27:49 <dkliban> let's do this! 15:27:55 <ggainey> yes, concur 15:28:47 <ttereshc> could we agree on rpm release? 15:29:00 <ttereshc> we skipped/ignored this one 15:29:44 <ipanova> when the release should happen? 15:29:48 <fao89> I can do it 15:29:59 <ttereshc> as soon as proxy fix is merged 15:30:04 <fao89> back to: will anyone be able to release pulp_rpm with the proxy fix? 15:30:45 <ttereshc> anyone else with perms on pulp_rpm? I believe fao89 is pretty packed with the tasks and potentially installer release 15:31:01 <fao89> hahaha 15:31:51 <ggainey> I mean, I've got perms now - but I'm also working on three bugs right now, in pulp2 and 3; context-switch will keeelll me :( 15:32:42 <ttereshc> ok, sold to fao89 15:32:53 <fao89> hahaha 15:32:57 <ttereshc> :D 15:33:14 <fao89> back to topic: remove the test_file_decriptors test from everywhere 15:34:01 <bmbouter> yeah so this test does not test pulp functionality and now it's practically failing randomly I believe to how dependencies handle file descriptors 15:34:14 <ttereshc> I think there is an agreement to remove them 15:34:21 <bmbouter> so I'm proposing we bring these 3 stories onto the sprint and email pulp-dev w/ a recommendation to remove from all plugins 15:34:28 <ggainey> yus - can we add the tasks to the sprint? 15:34:31 <bmbouter> and w/ my new free time I can knock them out 15:34:33 <ggainey> yeah, ok 15:35:33 <bmbouter> so shall I move onto sprint and take as assigned? 15:35:50 <ggainey> def move to sprint - you can take 'em as you wish :) 15:35:53 <fao89> I think so 15:35:54 <dkliban> yes 15:35:56 <dkliban> let's do it 15:36:09 * bmbouter clicks the buttons to add to sprint 15:36:32 <fao89> last topic: Docs day - schedule some time during pulpcon week? 15:38:07 <bmbouter> I am really in favor of docs day, it's what we need 15:38:15 <ttereshc> I think we can likely do it on Thursday or Friday that week, a docs 1/2 day 15:38:25 <bmbouter> I think with half-days taken by pulpcon though we need the other half to go to normal business delivery items 15:38:47 <ipanova> if we want to knock out some of them before the 3.7 release it will falls during pulpcon week 15:39:13 <bmbouter> yup but relatively between docs versus other items we already have to deliver if we have to choose, I think docs draws the short straw 15:39:27 <bmbouter> and it's because I love docs day I'm saying this actually 15:39:38 <bmbouter> let's give docs day the dedication it deserves 15:39:51 <bmbouter> a whole day, right after the a week after 3.7 target date 15:40:00 * bmbouter can't type 15:40:08 <ggainey> that's an idea - docs-day happens *early* in a erlease, not late 15:40:18 <ggainey> release even 15:41:21 <ipanova> what about i will schedule this for Thursday, who will have time will fix some docs 15:41:54 <ggainey> ipanova: you mean the 10th? 15:42:09 <ggainey> or the 24th? 15:42:10 <ipanova> bmbouter: the point is to make this a regular thing without exceptions, does not necessarily mean that you will dedicate all 8 hours of your day 15:42:39 <ipanova> ggainey: 17th 15:42:52 <ggainey> oh, during pcon 15:42:58 <ggainey> sorry, was confused 15:43:26 <bmbouter> ipanova: I can agree to that, but I very likely cannot participate. I'm ok w/ that 15:43:46 <ttereshc> my thinking is if we release on 22nd, everything should be more or less done by 17th/18th, otherwise release needs to be postponed anyway 15:44:06 <bmbouter> once again I'm sure it will go down to the wire 15:44:25 <ipanova> bmbouter: that's ok, my goal is to make this day as a *habit* - having docs day several days before release day 15:44:27 <bmbouter> I predict we will delay, and still deliver items moments before 15:44:52 <bmbouter> for example, once all required features are in our stakeholders will need the release. we can't justify holding it back for a baking period 15:45:16 <bmbouter> which structurally means we'll release immediately after the last "go" feature is merged 15:45:37 <ipanova> bmbouter: we need to start somewhere ;) i understand instability does not help and hard to predict delays, etc 15:45:52 <ipanova> bmbouter: it will be before target release, i don't follow your last argument 15:46:04 <ipanova> target release date* 15:46:25 <bmbouter> my reasoning is that as soon as our features are done, galaxy_ng will need us to release pulpcore 3.7 15:46:47 <bmbouter> so there can't be this freeze period 15:47:01 <fao89> last release the docs day happened, I couldn't contribute because I was working on the feature, but the team made a lot of contributions 15:47:18 <bmbouter> are we talking docs day, or a freeze w/ this convo? 15:47:18 <fao89> not everyone will be working on features 15:47:25 <ipanova> bmbouter: docs day 15:47:26 <ipanova> :D 15:47:33 <fao89> so the docs day is totally feasible 15:47:52 <bmbouter> docs day is definitly feasible, happy to have it on the 17th as proposed 15:48:10 <ipanova> bmbouter: sweet, glad we all on the same page how, heh 15:48:22 <ipanova> i will take an AI schedule and advertise 15:48:32 <ipanova> s/how/now 15:48:39 <bmbouter> that sounds great 15:48:54 <fao89> #endmeeting 15:48:54 <fao89> !end