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