14:31:07 <fao89> #startmeeting Pulp Triage 2020-10-02
14:31:07 <fao89> !start
14:31:07 <pulpbot> Meeting started Fri Oct  2 14:31:07 2020 UTC.  The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:31:07 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:31:07 <pulpbot> The meeting name has been set to 'pulp_triage_2020-10-02'
14:31:07 <fao89> #info fao89 has joined triage
14:31:07 <pulpbot> fao89: fao89 has joined triage
14:31:21 <fao89> Open floor - https://hackmd.io/@pulp/triage/edit
14:31:44 <bmbouter> #info bmbouter has joined triage
14:31:44 <bmbouter> !here
14:31:44 <pulpbot> bmbouter: bmbouter has joined triage
14:31:46 <ppicka> #info ppicka has joined triage
14:31:46 <ppicka> !here
14:31:46 <pulpbot> ppicka: ppicka has joined triage
14:32:33 <ttereshc> #info ttereshc has joined triage
14:32:33 <ttereshc> !here
14:32:34 <pulpbot> ttereshc: ttereshc has joined triage
14:32:48 <fao89> topic: pulpcore 3.8 release date?
14:33:19 <bmbouter> I think it would be useful to call one
14:34:05 <ttereshc> do we have any must-have features for it? or would it be pure time-based release?
14:34:52 <dkliban> #info dkliban has joined triage
14:34:52 <dkliban> !here
14:34:52 <pulpbot> dkliban: dkliban has joined triage
14:35:20 <bmbouter> right now I believ eit would be just time based
14:35:49 <bmbouter> but it's probable also that once we call a date, someone puts a feature on the gotta-go-into-it-list and then it becomes a mix of time/feature
14:36:05 <bmbouter> I don't know of anything big though, probably biggest for pulpcore would be the django model build=out
14:36:07 <bmbouter> build-out
14:36:18 <fao89> purely time based :heart:
14:36:47 <dkliban> i would like to have auto publish for pulp_file that is released around the pulpcore 3.8 time
14:37:10 <bmbouter> oh this is important I share: pulp_file will not be released with pulpcore anymore
14:37:15 <dkliban> yep
14:37:27 <dkliban> and that is why i said around pulpcore 3.8
14:37:59 <dkliban> time
14:38:01 <bmbouter> if there's nothing in pulpcore that changes it could even happen in 3.7 compat
14:38:12 <fao89> purely time based, no pulp_file, I'm liking more and more
14:38:29 <ttereshc> I think I have no preference for Oct 20th vs Oct 27th
14:39:11 <ttereshc> the upcoming sprint seems to be thin, so maybe 27th? (just to pick the date)
14:39:16 <bmbouter> given that releasing took so much effort I kind of think the 27th (5 weeks release to release)
14:40:38 <dkliban> let's do the 27th
14:41:00 <bmbouter> and typically we pick a release lead now also
14:41:02 <ttereshc> next question, who'll be shepherding it?
14:41:06 <ttereshc> ha
14:41:22 <bmbouter> we can defer until more folks are here to decide on tues if we want
14:41:31 <fao89> I pick daviddavis #kidding
14:41:36 <bmbouter> I don't mind volunteering again my goal is to improve the release process between now and then anyway
14:41:43 <ttereshc> no no :)
14:41:46 <bmbouter> unless someone else volunteers who is involved with pulpcore
14:41:50 <ttereshc> let's give you some rest
14:41:57 <bmbouter> sounds good to me
14:41:58 <ttereshc> I can do the release
14:42:06 <ttereshc> just 28th is a holiday in cz
14:42:12 <fao89> this is important to rotate to get different points of view
14:42:16 <bmbouter> then maybe we go with 20th?
14:42:19 <ttereshc> in case a release is delayed
14:42:22 <bmbouter> 20th is probably equally good
14:42:26 <bmbouter> it always takes 2 days ...
14:42:39 <bmbouter> also there are no instructions on the installer release process
14:42:57 <fao89> I think this one will be different due to deprecation cycle
14:43:09 <bmbouter> I am hoping also
14:43:24 <ttereshc> cool, I've never released the installer, I can learn while doing it and document it if needed
14:43:36 <bmbouter> ttereshc: want to start by filing a 3.8.0 task and add the y-stream checklist ?
14:43:46 <ttereshc> sure, that's my IA
14:43:48 <ttereshc> AI
14:43:53 <fao89> ttereshc++
14:43:53 <pulpbot> fao89: ttereshc's karma is now 231
14:45:16 <fao89> so it will be 20th or 27th?
14:45:29 <fao89> just to add to open floor agenda
14:45:50 <ttereshc> https://pulp.plan.io/issues/7645
14:45:57 <dkliban> fao89: the 20th
14:46:00 <ttereshc> 20th
14:46:30 <ttereshc> I'll send an email to pulp-dev with the tentative release date for 3.8.0
14:47:14 <dkliban> sounds good
14:47:36 <fao89> next topic? or do we need to pick a date for go/no-go?
14:47:55 <dkliban> on the 13th i think
14:48:19 <dkliban> what do folks think aobut having a 3.8.0 go/no-go meeting on the 13th?
14:48:36 <ttereshc> +1
14:49:14 <fao89> next topic: new pulp org for pulp tooling (to balance Travis)
14:49:28 <ttereshc> it will be go/no-go for both pulpcore and installer, correct?
14:49:39 <fao89> I think so
14:49:45 <ttereshc> (last time there was some confusion around it)
14:49:47 <ttereshc> ok
14:50:09 <fao89> first time confusion - now we learned
14:50:16 <ttereshc> haha
14:50:18 <bmbouter> correct
14:50:26 <fao89> topic: new pulp org for pulp tooling (to balance Travis)
14:50:47 <fao89> so, we are introducing vagrant tests (that can only be done with Travis)
14:51:11 <dkliban> and those tests run for a long time
14:51:13 <fao89> our installer has lot of jobs that takes a lot of time
14:51:37 <fao89> which would increase a lot the Travis queue
14:52:16 <fao89> the easiest alternative to address the queue issue, is having another org for installers repos
14:52:16 <bmbouter> this is a good way to solve the problem
14:52:22 <bmbouter> but I am concerned with having two orgs
14:52:39 <fao89> so I want to share this idea and see what people think
14:53:10 <fao89> maybe this is a subject for the mailing list
14:53:35 <bmbouter> it would also be good to look at which jobs and how long they are taking, how backed up is it getting, etc
14:53:44 <bmbouter> some numbers to go off articulating the problem statement
14:54:25 <bmbouter> other ideas also are to move more to nightlies, or spread the load on more CI's ci.centos.org, GH actions, circle CI, etc
14:54:33 <fao89> I send an email at pulp-dev mailing list
14:54:55 <ttereshc> what are the downsides to have 2 orgs? I can see a lot of duplication with teams, access and other configuration, search across orgs.
14:56:14 <bmbouter> well it splits the whole organization conceptually
14:56:34 <bmbouter> this is not exactly a downside perhaps
14:56:47 <fao89> if we only move the installers repo, basically the installer team would be the owner of the new org
14:56:52 <bmbouter> but it's also a very unusual thing to do, there are waaaaay bigger projects out there and I've never seen an org split
14:57:02 <bmbouter> apache has I think hundreds of sub-projects in its org
14:57:09 <bmbouter> ansible also
14:58:04 <ttereshc> I'm not in favor or against this approach, just curious, what are the downsides
14:58:19 <fao89> I'll gather some data and send the email, so we can discuss more in other open floors
14:58:20 <bmbouter> ^ are the ones I see
14:58:26 <ttereshc> fao89, +1 for the pulp-dev thread
14:58:32 <bmbouter> yup that sounds good
14:58:42 <ttereshc> bmbouter, yeah, thanks
14:58:50 <fao89> next topic: is there a way to test packaging? (MANIFEST.in issues)
14:59:11 <fao89> for 2 times we had to run for a z-stream
14:59:15 <bmbouter> yeah so I think the initiative daviddavis and dkliban were working on is the best way to get this
14:59:37 <bmbouter> with that change, the packaging would occur nightly instead of post-release
15:00:02 <dkliban> yes, i believe Zhenech had an idea for testing in this area
15:00:16 <dkliban> there is a python package that can be used to check if we are including all the needed files
15:01:03 <dkliban> https://pypi.org/project/check-manifest/
15:01:08 <fao89> nice!
15:01:08 <dkliban> i told him to open an issue
15:01:14 <bmbouter> that sounds great
15:02:14 <fao89> that's all folks!
15:02:18 <fao89> #endmeeting
15:02:18 <fao89> !end