15:00:08 <zbyszek> #startmeeting FESCO (2018-03-02)
15:00:08 <zodbot> Meeting started Fri Mar  2 15:00:08 2018 UTC.  The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:08 <zodbot> The meeting name has been set to 'fesco_(2018-03-02)'
15:00:08 <zbyszek> #meetingname fesco
15:00:08 <zbyszek> #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek
15:00:08 <zodbot> The meeting name has been set to 'fesco'
15:00:08 <zodbot> Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek
15:00:09 <bowlofeggs> .hello2
15:00:11 <zbyszek> #topic init process
15:00:12 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:00:28 <jsmith> .hello2
15:00:29 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
15:00:38 <zbyszek> 
15:00:40 <nirik> morning
15:00:42 <sgallagh> .hello2
15:00:46 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:08 <zbyszek> .hello2
15:01:09 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:44 <zbyszek> That's 5, let's start
15:01:59 <zbyszek> #topic #1846 F28 approved Changes not in MODIFIED status (considered as not testable)
15:02:02 <zbyszek> .fesco 1846
15:02:04 <zodbot> zbyszek: Issue #1846: F28 approved Changes not in MODIFIED status (considered as not testable) - fesco - Pagure - https://pagure.io/fesco/issue/1846
15:02:04 <zbyszek> https://pagure.io/fesco/issue/1846
15:02:27 <zbyszek> Does anyone have additional info on the Modularity change?
15:02:50 <sgallagh> Hello
15:02:51 <jsmith> langdon said that sgallagh was going to join the meeting and give us a status update
15:02:56 <jsmith> And there he is :-)
15:03:00 <nirik> we have branched and rawhide composes... but there are some pungi / config issues to work thru
15:03:26 <sgallagh> Yeah, the short version is that the rel-eng changes are landing later in the cycle than I would have preferred.
15:03:29 * nirik stops, lets sgallagh update as he likely has more up to date info
15:03:56 <sgallagh> We have pretty much everything we need in place on the packager side of things.
15:04:00 <bowlofeggs> there's a patch for bodhi from jkaluza that is probably needed (i'm waiting on a response from him on the PR)
15:04:07 <sgallagh> We can build modules and prep them for inclusion.
15:04:10 <bowlofeggs> (for modularity)
15:04:34 <tyll_> ac.hello till
15:04:34 <sgallagh> bowlofeggs: OK, I wasn't aware of that one. Could you provide a link (in #fedora-modularity is fine)
15:04:37 <tyll_> .hello till
15:04:38 <zodbot> tyll_: till 'Till Maas' <opensource@till.name>
15:04:45 <bowlofeggs> sgallagh: https://github.com/fedora-infra/bodhi/pull/2167
15:05:30 <sgallagh> I think we're in pretty decent shape, but I couldn't mark the BZ as "testable" yet because the repo bits are still being fixed up.
15:05:52 <sgallagh> From my conversation with lsedlar today, that looks *likely* to be resolved by EOB today
15:06:17 <sgallagh> At which point we are probably good to go for Beta
15:06:33 <zbyszek> OK, so I think we can just wait another week for all 4 changes.
15:06:39 <jsmith> zbyszek: Agreed. +1
15:06:54 <bowlofeggs> i'm +1 to another week on all 4
15:06:59 <sgallagh> The major remaining piece is going to be adding module content between Beta and Final
15:07:34 <sgallagh> We will have some representative content available, but we want to grow that out to a better sample before final release
15:07:47 <sgallagh> EOF
15:08:07 <zbyszek> Ack.
15:08:31 <sgallagh> +1 to granting another week to make a final decision
15:08:40 * nirik is fine with another week. +1
15:08:50 <zbyszek> tyll_?
15:09:11 <tyll_> +1 for another week
15:09:45 <zbyszek> OK, so now I need to do the agreed thingy?
15:10:26 <nirik> yep
15:10:36 <sgallagh> zbyszek: Yes. We don't have a formally-agreed format for it, but I usually use (+X, Y, -Z) to indicate +1's, -1's and 0's
15:10:48 <zbyszek> #agreed FESCo will wait another week for the changes not in MODIFIED status (+6, 0, -0)
15:11:14 <zbyszek> #agree FESCo will wait another week for the changes not in MODIFIED status (+6, 0, -0)
15:11:28 <sgallagh> The #agreed is the correct format
15:11:49 <zbyszek> Should I get a reply from zodbot?
15:11:51 <nirik> yeah, it just doesn't ack anything in channel, only logs
15:11:52 <bowlofeggs> no
15:12:01 <zbyszek> Oh, OK. Sorry.
15:12:06 <bowlofeggs> no problema
15:12:07 <zbyszek> #topic #1845 389-ds-base and freeipa on 32 bit arches
15:12:07 <zbyszek> .fesco 1845
15:12:07 <zbyszek> https://pagure.io/fesco/issue/1845
15:12:07 <bowlofeggs> :)
15:12:09 <zodbot> zbyszek: Issue #1845: 389-ds-base and freeipa on 32 bit arches - fesco - Pagure - https://pagure.io/fesco/issue/1845
15:12:41 <bowlofeggs> i dont' feel like we got a lot of feedback abotu this one
15:12:56 * nirik hasn't been following the bugs
15:13:03 <zbyszek> It's a mess...
15:13:04 <bowlofeggs> it does kinda sound like it's not a toolchain bug
15:13:11 <bowlofeggs> but a bug in 389
15:13:14 <jsmith> I asked again earlier today for feedback
15:13:20 <jsmith> bowlofeggs: Agreed -- but I'd still like more information
15:13:52 <sgallagh> What exactly is the question before us, though?
15:13:57 <jsmith> Anybody have any friends/contacts on the 389 team?
15:14:05 <bowlofeggs> i think they want to remove 389-ds from i686
15:14:12 <bowlofeggs> or was it from all 32-bit?
15:14:19 <bowlofeggs> that's even kinda unclear to me
15:14:19 <jsmith> bowlofeggs: It was all 32-bit
15:14:20 <bowlofeggs> haha
15:14:21 <sgallagh> Are we being asked to force 389/FreeIPA to ship i686 even though it's known to have memory corruption issues?
15:14:25 <zbyszek> sgallagh: whether to reject the removal of support for i686 and require the maintainers to provide it for F28.
15:14:30 <sgallagh> I feel like that's a bad precedent
15:14:32 <jsmith> And I was trying to figure out "Is this an i686 problem, or a 32-bit problem"
15:14:47 <jsmith> sgallagh: Exactly :-)
15:15:06 <bowlofeggs> it does seem like it would be bad for us to force them to ship a corrupting build
15:15:18 <sgallagh> So, here's my thought process
15:15:19 <bowlofeggs> but i do think they should try to fix it
15:15:29 <sgallagh> If this was happening on x86_64, we'd be blocking the release for this.
15:15:44 <bowlofeggs> true
15:15:48 <jsmith> sgallagh: There are some hints that it *might* be happening on x86_64, but "much less often"
15:15:56 <sgallagh> By Blocker/FE process rules, that means a *fix* for this is a guaranteed Freeze Exception.
15:15:58 <bowlofeggs> are any 32-bit arches "primary"?
15:15:59 <jsmith> sgallagh: Hence the reason I'm trying to get more info
15:16:14 <sgallagh> bowlofeggs: ARMv7 is primary for XFCE spin
15:16:17 <jsmith> bowlofeggs: Yes, armv7
15:16:25 <bowlofeggs> oh man
15:16:28 <sgallagh> But it's not a blocking deliverable for Server
15:16:46 <sgallagh> And 389/FreeIPA are only blocking for Server installs
15:16:55 <bowlofeggs> ah that's good to note
15:17:41 <bowlofeggs> so basically, this is not a blocking package for any 32-bit arch
15:17:54 <sgallagh> My feeling on this is that since there is significant evidence that this is going to cause issues for i686 users, dropping it from that architecture until it's figured out is a sane and reasonable answer.
15:18:20 <zbyszek> sgallagh: but it's not entirely clear that it is corrupting or actually causing any issues. Instead some tests are failing and they are used as convenient excuse to drop support.
15:18:31 <sgallagh> bowlofeggs: Right, if it was blocking there would be no debate here.
15:18:52 <nirik> yeah, it's unclear to me too. lots of the toolchain people are looking into it too...
15:18:55 <bowlofeggs> zbyszek: that's a good point too
15:19:12 <nirik> "If this is a bug in our tools, let us fix it"
15:19:18 <sgallagh> zbyszek: That is kind of the entire purpose of tests, though
15:19:27 <sgallagh> To identify issues *before* the end-users get hosed :)
15:19:28 <bowlofeggs> it sounds like the toolchain people dont' think this is a toolchain issue
15:19:29 <zbyszek> I don't think we can force support if maintainers don't want it, but there's a time in the cycle to drop an architecture, and it's very late to do it now.
15:20:02 <sgallagh> zbyszek: I don't think it's too late. It's a reasonable thing to put in the Beta Release Notes, of course
15:20:06 <bowlofeggs> the title of the bug does specifically say i686 and not 32-bit in general
15:20:16 <sgallagh> If we were past Beta, I'd be more hesitant
15:20:17 <bowlofeggs> (just a note)
15:21:12 <bowlofeggs> we have had talks about dropping i686 all together before
15:21:16 <nirik> bowlofeggs: yeah, but they note "This was a mistake on my part, as I didn't realize arm was 32bit.  So arm will also be excluded in f28.  So the original bug description was correct. "
15:21:17 <bowlofeggs> there is the sig for it and what not
15:21:20 * sgallagh is attempting to summon some of the 389 folks
15:21:37 <bowlofeggs> nirik: oh, so maybe the bug title should be updated
15:22:02 <bowlofeggs> i'm inclined to ask some questions on the bug report to try to get more info
15:22:18 <bowlofeggs> 1) should we update the bug title to say "32 bit" instead of i686?
15:22:19 <zbyszek> bowlofeggs: it's "389-ds-base and freeipa on 32 bit arches
15:22:21 <zbyszek> "
15:22:24 <sgallagh> So, I think I'm fine with killing off 32-bit support in F28. I wish it had been done more intentionally as a planned Change, but I think we have time to do it.
15:22:36 <jsmith> bowlofeggs: Please do -- my email to the devel list didn't seem to trigger a response.
15:22:37 <bowlofeggs> 2) Do we know real world use cases that cause problems, vs. test harnesses causing problems?
15:23:06 <bowlofeggs> sgallagh: yeah that's an option - we could just grant a real late change request to this
15:23:17 <sgallagh> Let me ask the question differently: what does it cost us to drop it?
15:23:41 <nirik> sgallagh: a cascade of lost support for lots of things?
15:23:52 <sgallagh> nirik: Sorry, explain?
15:23:54 <bowlofeggs> yeah i think this does kill a tree of packages
15:23:56 <nirik> or shipping other things on 32 bit with a serious bug other packages don't know about?
15:24:01 <bowlofeggs> sgallagh: this is a dependency of other things
15:24:10 <nirik> well, 389 goes, freeipa goes, N goes, etc
15:24:18 <bowlofeggs> this is a dammed if you do, dammed if you don't situation haha
15:24:21 <sgallagh> bowlofeggs: Pretty much only the FreeIPA stack which doesn't need to be run on the same hardware as its clients.
15:25:16 <bowlofeggs> so do we want to proceed with asking them to file a change to drop this stuff, or do we want to ask question of them and wait another week?
15:25:17 * jsmith has to drop offline for a few minutes, but has voted on the tickets in Pagure
15:25:28 <jsmith> +1 for ask questions, wait a week
15:25:33 <nirik> I'd prefer to have more info...
15:25:33 <zbyszek> +1 too
15:25:39 <sgallagh> bowlofeggs: Both?
15:25:46 <bowlofeggs> if questions, do people want ot add more questions to the 2 i listed above?
15:25:54 * bowlofeggs volunteers to write them on the bz
15:25:56 <sgallagh> If they feel strongly that this should be dropped, I think asking them to write up a Change Proposal for us is reasonable
15:26:05 <bowlofeggs> sgallagh: sure
15:26:05 <nirik> sgallagh: +1
15:26:28 <zbyszek> sgallagh: +1
15:26:30 <sgallagh> bowlofeggs: 3) Can you provide evidence that the issue is not also present on supported architectures?
15:26:41 <bowlofeggs> cool
15:27:07 <tyll_> +1 for a proper change proposal
15:27:26 <bowlofeggs> #action bowlofeggs will post questions from FESCo to the 389-ds BZ and ask for a change proposal if they feel strongly it should be dropped
15:27:46 <zbyszek> FTR: dnf -C repoquery --whatrequires 389-ds-base --alldeps --qf %{name}|sort -u
15:27:49 <zbyszek> 389-admin
15:27:52 <zbyszek> 389-ds
15:27:54 <zbyszek> 389-ds-base-snmp
15:27:57 <zbyszek> freeipa-server
15:27:59 <zbyszek> migrationtools
15:28:02 <zbyszek> slapi-nis
15:28:26 <zbyszek> OK, can we move on?
15:28:29 <bowlofeggs> engineering is hard
15:28:29 <bowlofeggs> haha
15:28:32 <bowlofeggs> sure
15:28:32 <sgallagh> That's the FreeIPA stack and nothing else
15:28:41 <bowlofeggs> if anyone thinks of more questions, let me know
15:28:49 <zbyszek> So, another messy thing:
15:28:51 <zbyszek> #topic #1820 Adjust/Drop/Document batched updates policy
15:28:51 <zbyszek> .fesco 1820
15:28:51 <zbyszek> https://pagure.io/fesco/issue/1820
15:28:53 <zodbot> zbyszek: Issue #1820: Adjust/Drop/Document batched updates policy - fesco - Pagure - https://pagure.io/fesco/issue/1820
15:29:09 <bowlofeggs> this one is pretty contentious
15:29:22 * nirik nods.
15:29:30 <bowlofeggs> i do agree that adding one more repo would make the angry people happier, but i don't know if we have the resources to do that
15:29:34 <bowlofeggs> nirik: do we have the resources to do that?
15:29:35 <sgallagh> I'm still pretty much firm on my comment https://pagure.io/fesco/issue/1820#comment-488614
15:30:09 <bowlofeggs> it wouldn't be hard to make bodhi enforce it i dont' think
15:30:10 <nirik> we could possibly do it, but I wonder if it would be used by like the 10 people who want it on devel list and no one else.
15:30:37 <bowlofeggs> nirik: haha yeah, and it would be a lot of resources for 10 people
15:30:46 <nirik> yeah.
15:31:03 <bowlofeggs> i do still think that jdieter's proposal could make things nicer too
15:31:08 <bowlofeggs> (the delta repo files)
15:31:16 <bowlofeggs> though i don't know how long that would take to implement
15:31:21 <bowlofeggs> he seems pretty devoted to it so far
15:31:37 <sgallagh> Most of the arguments right now amount to  "Since I don't push to batched, there are updates every day anyway. Therefore batched is useless"
15:31:45 <sgallagh> I really think batched needs to be *mandatory*
15:31:50 <nirik> sgallagh: we could try a 'soft' version of that... just have releng not push stable branches unless there's a urgent update... for a week and see if anyone cares/notices.
15:32:01 <bowlofeggs> nirik: yeah that would be easy
15:32:07 <sgallagh> nirik: Hmmm, that's an interesting idea
15:32:08 <zbyszek> That's cool
15:32:37 <nirik> well, it would be more work for whoever is on push duty to check... but otherwise yeah
15:32:55 <sgallagh> nirik: That feels to me like something that could be scripted
15:32:55 <bowlofeggs> nirik: i could add a flag to bodhi-push to do taht automagically without too much trouble
15:33:09 <tyll_> I am pretty sure that people notice delays, because they already notice shorter delays when there are bugs
15:33:43 <bowlofeggs> nirik: bodhi-push --severity urgent
15:33:52 <bowlofeggs> (doesn't exist yet, but wouldn't be hard)
15:34:42 <nirik> yeah, dunno. I guess we could try it next week and see what feedback we get...
15:34:59 <bowlofeggs> that sounds fine to me. i'm also amenable to sgallagh's proposal
15:35:36 <bowlofeggs> it hink i agree that adding another repo might have an undesirable effort/reward ratio
15:35:37 <zbyszek> That doesn't solve all the issues, in particular it doesn't answer the question of how to test those batched updates, but it'll give us more information, so I'm a cautious +1
15:35:53 <nirik> well, just trying it might give more data to decide if we should enforce it or not
15:36:02 <zbyszek> Exactly.
15:36:07 <nirik> zbyszek: well, updates-testing... like any others
15:36:11 <bowlofeggs> zbyszek: the batched updates stay in the testing repo, so they get tested just like normal testing updates
15:36:51 <sgallagh> nirik: Well, the plan around batched was that we'd run a battery of automated tests against the stuff we were about to push as a complete unit
15:36:55 <bowlofeggs> jsmith, tyll_: you have thoughts on this?
15:36:56 <sgallagh> Which we can't do in the "soft" version
15:37:07 <sgallagh> But I agree, this approach would at least get us some useful information.
15:37:42 <bowlofeggs> sgallagh: yeah we don't have what we need to test them as a batch now, though i think mostly that would come down to creating a new koji tag and getting taskotron to use it
15:37:43 <tyll_> instead of an extra repo I would love to see an option in dnf so people can just filter on urgent updates for daily updates and other updates when they are ready
15:37:44 <nirik> sure, we might want to involve QA and see how hard it would be to do that testing...
15:37:47 <sgallagh> +1 to nirik's soft solution
15:38:01 <tyll_> it is there for security issues already
15:38:07 <sgallagh> tyll_: That's already present in PackageKit, actually
15:38:31 <bowlofeggs> i'm +1 to nirik's suggestion
15:38:38 <sgallagh> Oh, urgent but not security?
15:38:41 <sgallagh> Eh, whatever.
15:38:52 <bowlofeggs> yeah urgent is what is used today
15:38:54 <bowlofeggs> oh, and newpackage
15:39:07 <bowlofeggs> which causes metadata to change too
15:39:25 <bowlofeggs> at the time that was suggested, saving metadata downloads wasn't a goal in mind for me
15:39:40 <bowlofeggs> so that's why newpackage updates are also sent straight to stable
15:40:07 <bowlofeggs> not all security updates are really important
15:40:17 <bowlofeggs> and not all bug fixes are "unimportant"
15:40:21 * nirik wonders how many urgent updates we even have
15:40:31 <bowlofeggs> so that's why we used the severity instead of security to choose stable vs. batched
15:40:49 <zbyszek> nirik, me, sgallagh, bowlofeggs voted. tyll_, jsmith ?
15:41:13 <tyll_> not sure if maintainers even change the severity for updates, since it did not really matter in the past
15:41:35 <bowlofeggs> nirik: there have been 503 ever
15:41:36 * sgallagh always has, on the grounds that it might one day matter :)
15:41:37 <nirik> yes, you can set it to whichever you like
15:42:04 <tyll_> zbyszek: the proposal is to delay all updates for a week unless there are urgent ones?
15:42:31 <sgallagh> tyll_: Not for a week: until Tuesday
15:42:57 <bowlofeggs> nirik: 62 urgent updates have happened in f27 so far
15:43:13 <zbyszek> tyll_: Up to a week. If there is anything urgent, everything goes out. At least that's how I understood nirik's proposal.
15:43:17 <tyll_> since it is always good to get some data, +1 to try it
15:43:34 <nirik> stable branches only push out when there is an urgent update pending on them or it's tuesday.
15:43:58 <tyll_> but IMHO it is not a good final solution
15:44:20 <bowlofeggs> i think it's a social experiement
15:44:24 <nirik> yeah, I was just wanting to get more data.
15:44:32 <tyll_> but if it pushes maintainers to better categorize their updates, it would be a win
15:44:38 <bowlofeggs> we can use it to help us make a decision about what to do
15:44:44 <sgallagh> tyll_: Right. Assuming this passes with little content, the final solution (in my mind) is just enforcing batched.
15:46:07 <Southern_Gentlem> (better patch wednesday than on tuesday)
15:46:09 <tyll_> sgallagh: im my mind batched would be better implemented in the client
15:46:29 <tyll_> it would allow more flexibility to decide when to get the updates
15:46:50 <sgallagh> tyll_: There are pros and cons there, but we should probably move to the next topic
15:46:57 <zbyszek> Sorry, I dropped off for a moment. We had 5 +1 to nirik's proposal.
15:47:09 <nirik> yeah, barring the metadata issues client side might indeed be a lot better
15:47:14 <zbyszek> nirik: can you type up an #action item? I'm not sure about the exact wording.
15:48:06 <nirik> #action next week updates will only be pushed to stable when there is an urgent pending stable update or tuesday after batched promotion. Feedback will be gathered and we will revist next meeting.
15:48:14 <zbyszek> Thanks.
15:48:19 <zbyszek> = New business =
15:48:19 <zbyszek> self contained changes:
15:48:19 <zbyszek> #topic #1856 F29 Self Contained Change: FedoraScientific VagrantBox
15:48:19 <zbyszek> .fesco 1856
15:48:19 <zbyszek> https://pagure.io/fesco/issue/1856
15:48:21 <zodbot> zbyszek: Issue #1856: F29 Self Contained Change: FedoraScientific VagrantBox - fesco - Pagure - https://pagure.io/fesco/issue/1856
15:48:45 <nirik> +1
15:48:51 <sgallagh> +1
15:49:03 <zbyszek> +1
15:49:07 <sgallagh> Oh, hang on
15:49:16 <sgallagh> Did they get rel-eng approval? That's required for new spins
15:49:22 <sgallagh> err, new media
15:50:22 <zbyszek> https://pagure.io/releng/issue/7324
15:50:23 <sgallagh> OK, they have requested it
15:50:24 <sgallagh> We're good
15:50:27 <zbyszek> No answer so far.
15:50:37 <bowlofeggs> do we need to wait for releng?
15:50:43 <bowlofeggs> or just make sure they filed the ticket?
15:50:45 <sgallagh> zbyszek: I'm comfortable with the fact the ticket exists
15:50:46 <zbyszek> I think we need to wait.
15:50:55 <Southern_Gentlem> https://labs.fedoraproject.org/en/scientific/
15:51:14 <sgallagh> Nah, we can approve it and if rel-eng says no we activate the Contingency Plan
15:51:20 <tyll_> +1
15:51:32 <zbyszek> sgallagh: OK, if you say so
15:51:47 <bowlofeggs> shouldn't this change have a deliverables section?
15:51:56 <zbyszek> We had had more votes in the ticket, let me count them
15:52:33 <bowlofeggs> oh it does have a list of deliverables
15:52:37 <bowlofeggs> under the releng ticket
15:52:43 <puiterwijk> bowlofeggs: it's also on the change page
15:52:52 <zbyszek> ausil, jwb, jsmith were +1
15:52:56 <bowlofeggs> +1
15:53:11 <zbyszek> #agree F29 Self Contained Change: FedoraScientific  VagrantBox
15:53:29 <zbyszek> #undo
15:53:29 <zodbot> Removing item from minutes: AGREED by zbyszek at 15:53:11 : F29 Self Contained Change: FedoraScientific  VagrantBox
15:53:53 <zbyszek> #agree F29 Self Contained Change: FedoraScientific VagrantBox is accepted (+8, 0, -0)
15:53:54 <bowlofeggs> i guess that means #agree works too
15:54:11 <zbyszek> #topic #1854 F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark
15:54:15 <zbyszek> .fesco 1854
15:54:17 <zodbot> zbyszek: Issue #1854: F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark - fesco - Pagure - https://pagure.io/fesco/issue/1854
15:54:17 <zbyszek> https://pagure.io/fesco/issue/1854
15:54:44 <zbyszek> jwb, jsmith voted +1 in the ticket
15:54:48 <bowlofeggs> +1
15:54:52 <nirik> +1
15:54:53 <sgallagh> +1
15:54:55 <zbyszek> +1 ftr
15:55:13 <zbyszek> tyll_?
15:55:27 <tyll_> +1
15:56:00 <zbyszek> #agree F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark is accepted (+7, 0, 0)
15:56:20 <zbyszek> #topic #1852 F29 Self Contained Change: No more automagic Python bytecompilation
15:56:24 <zbyszek> .fesco 1852
15:56:25 <zodbot> zbyszek: Issue #1852: F29 Self Contained Change: No more automagic Python bytecompilation - fesco - Pagure - https://pagure.io/fesco/issue/1852
15:56:26 <zbyszek> https://pagure.io/fesco/issue/1852
15:56:33 * mhroncok is here
15:56:44 <zbyszek> jwb, jsmith voted +1, +1
15:56:51 <sgallagh> Seems reasonable to me. +1
15:56:54 <zbyszek> +1
15:57:03 <sgallagh> Automatic byte-compilation in random places has bit me in the past
15:57:27 <bowlofeggs> this is a really nice write up
15:57:30 <bowlofeggs> +1
15:57:37 <nirik> +1
15:58:11 <zbyszek> tyll_?
15:58:14 <tyll_> +1
15:58:32 * jsmith is back
15:58:34 <jsmith> (at least for a minute -- on mobile connection)
15:58:45 <zbyszek> #agree F29 Self Contained Change: No more automagic Python bytecompilation is accepted (+7, 0, 0)
15:58:49 <mhroncok> thanks
15:58:54 <zbyszek> jsmith: go away, you voted already ;)
15:59:04 <zbyszek> #topic #1851 F29 System Wide Change: Remove GCC from BuildRoot
15:59:04 <zbyszek> .fesco 1851
15:59:05 <zbyszek> https://pagure.io/fesco/issue/1851
15:59:06 <zodbot> zbyszek: Issue #1851: F29 System Wide Change: Remove GCC from BuildRoot - fesco - Pagure - https://pagure.io/fesco/issue/1851
15:59:16 <jsmith> zbyszek: You can't get rid of me that easily :-p
15:59:33 <bowlofeggs> +1 to gcc
15:59:37 <tyll_> +1
15:59:43 <zbyszek> jwb voted +1 in the ticket
15:59:47 <sgallagh> jsmith: You voted on this one twice :-P
15:59:51 <zbyszek> +1 from me
15:59:57 <sgallagh> I was +1 in the ticket, so +1 here also
16:00:13 <jsmith> sgallagh: Then this one makes three :-)
16:00:18 <jsmith> sgallagh: Vote early, vote often :-)
16:00:43 <nirik> +1
16:01:44 <zbyszek> #agree F29 System Wide Change: Remove GCC from BuildRoot is accepted (+7, 0, 0)
16:01:52 <zbyszek> #topic #1850 F29 Self Contained Change: True Noarch Erlang Packages
16:01:52 <zbyszek> .fesco 1850
16:01:52 <zbyszek> https://pagure.io/fesco/issue/1850
16:01:53 <zodbot> zbyszek: Issue #1850: F29 Self Contained Change: True Noarch Erlang Packages - fesco - Pagure - https://pagure.io/fesco/issue/1850
16:02:26 <zbyszek> jwb voted +1 in the ticket
16:02:29 <tyll_> +1
16:02:33 <jsmith> jsmith voted +1 in the ticket
16:02:44 <zbyszek> +1
16:02:46 <nirik> +1
16:03:11 <sgallagh> +1
16:03:23 <bowlofeggs> +1 to my own proposal :)
16:03:34 <zbyszek> #agree F29 Self Contained Change: True Noarch Erlang Packages is accepted (+7, 0, 0)
16:03:41 <zbyszek> #topic #1855 F29 Self Contained Change: BINUTILS 2.30
16:03:42 <zbyszek> .fesco 1855
16:03:42 <zbyszek> https://pagure.io/fesco/issue/1855
16:03:42 <jsmith> bowlofeggs: Way to go :-)
16:03:44 <zodbot> zbyszek: Issue #1855: F29 Self Contained Change: BINUTILS 2.30 - fesco - Pagure - https://pagure.io/fesco/issue/1855
16:03:46 <bowlofeggs> (and i finally have working code for it!) (it had to be delayed on f27 and f28 :( )
16:04:09 <bowlofeggs> +1 to binutils
16:04:10 <jsmith> I think this *might* need to be a system-wide change
16:04:18 <jsmith> but either way, I'm +1
16:04:46 <nirik> +1 here, sorry it didn't make 28, but there was already a full plate there.
16:05:03 <zbyszek> +1 to the change
16:05:06 <tyll_> +1
16:05:11 <zbyszek> jwb voted +1 in the ticket
16:05:16 <sgallagh> +1
16:05:25 <bowlofeggs> i support making it system-wide
16:05:36 <zbyszek> +1 to making in system wide
16:05:55 <sgallagh> Yeah, +1 system-wide
16:05:59 <puiterwijk> It's already broken at least one systemd build, so yeah, not entirely self contained :)
16:06:42 <sgallagh> Well, at least it didn't break anything *important*...
16:06:59 * sgallagh can feel zbyszek's glare through the screen
16:07:14 <zbyszek> ;)
16:08:12 <zbyszek> tyll_: , jsmith
16:08:36 <tyll_> +1
16:08:43 <jsmith> +1
16:08:50 <jsmith> (again)
16:09:17 <zbyszek> #agree F29 Self Contained Change: BINUTILS 2.30 should be made a System-Wide Change (+6, 0, 0)
16:09:36 <zbyszek> #agree F29 Self Contained Change: BINUTILS 2.30 is accepted (+7, 0, 0)
16:09:56 <zbyszek> jwb is not here, so the count is different
16:10:03 <zbyszek> #topic #1853 F29 System Wide Change: Enable dbus-broker
16:10:03 <zbyszek> .fesco 1853
16:10:03 <zbyszek> https://pagure.io/fesco/issue/1853
16:10:06 <zodbot> zbyszek: Issue #1853: F29 System Wide Change: Enable dbus-broker - fesco - Pagure - https://pagure.io/fesco/issue/1853
16:10:19 <zbyszek> I suggest that we table this for another week
16:10:40 <sgallagh> That seems reasonable
16:10:42 <bowlofeggs> yeah i agree to wait
16:10:53 <jsmith> +1 to waiting
16:10:54 <bowlofeggs> i also think the wording should be changed as suggested by jsmith
16:11:46 * nirik is ok waiting
16:11:52 <zbyszek> #info F29 System Wide Change: Enable dbus-broker will be discussed next week
16:11:55 <tyll_> +1 to wait and reword
16:12:20 <zbyszek> jsmith: I typed a reply to your comment in the ticket twice already, but I lost the connection at the crucial moment twice
16:12:31 <zbyszek> and somehow the comment got lost. I'll try once more ;)
16:12:38 <zbyszek> #topic #1848 Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository
16:12:42 <zbyszek> .fesco 1848
16:12:44 <zodbot> zbyszek: Issue #1848: Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository - fesco - Pagure - https://pagure.io/fesco/issue/1848
16:12:44 <zbyszek> https://pagure.io/fesco/issue/1848
16:13:43 <bowlofeggs> i'm +1 as long as we archive the old repo
16:14:09 <zbyszek> +1 to the same
16:14:10 <sgallagh> Perhaps a better solution here would be for us to rename the git repo and make a shallow copy of the HEAD without the tarballs in it
16:14:18 <puiterwijk> Just a random idea: we can just rename the current refs to something that does not live in refs/heads, so won't be cloned automatically
16:14:19 <jsmith> I'm +1
16:14:29 <sgallagh> Essentially, restart the repo history from today.
16:14:39 <puiterwijk> Which means that we don't have to remove anything, and people can still "git fetch <commithash>" from the same location
16:14:51 <zbyszek> sgallagh: That'd have the same issue, that you cannot use an old commit hash
16:14:55 <nirik> I guess I'm a weak +1 if we archive the old repo and document where we archive such things and have a SOP for this process.
16:14:59 <puiterwijk> So basically set tags for the current state of things, and then rewrite the branches.
16:15:17 <bowlofeggs> puiterwijk: that's a good idea - i didn't realize git clone didn't pull down things not referenced by HEAD
16:15:18 <zbyszek> puiterwijk: I checked that, but if we make a tag, tags are clone dby default
16:15:22 <sgallagh> Wouldn't they still get everything in a clone
16:15:28 <puiterwijk> zbyszek: right. I meant a tag outside of refs/heads
16:15:28 <sgallagh> So a ridiculously-large checkout?
16:15:35 <puiterwijk> sgallagh: not if you stuff it in refs/archive/
16:15:41 <sgallagh> interesting...
16:15:46 <puiterwijk> git has a clone default of refs/heads/* and refs/tags/* if I recall correctly
16:15:47 <tyll_> +1 to puiterwijk's idea
16:15:56 <puiterwijk> That's how Github does their automagic refs/pull/$somenumber
16:16:03 <tyll_> also sounds like a good idea for all old branches IMHO
16:16:05 <puiterwijk> (and for those who didn't know: that even works with Pagure!)
16:16:14 <tyll_> or at least ancient branches
16:16:16 <jsmith> I'm +1 for puiterwijk's suggestion
16:16:37 <zbyszek> That's also acceptable
16:16:40 <bowlofeggs> yeah i'm +1 to puiterwijk's suggestion (and educated by it too!)
16:16:54 <puiterwijk> bowlofeggs: it doesn't depend on HEAD, it depends on refs/heads/ and refs/tags/ being the default clone refs :)
16:16:56 <nirik> I don't think we want to do it for all old branches tho
16:17:16 <bowlofeggs> yeah i think we just need it for this case
16:17:18 <puiterwijk> Yeah, I don't know about all old branches, I'd keep that for another discussion.
16:17:36 <tyll_> yes, it should be another discussion
16:18:18 <zbyszek> So the nice thing is that if we decide to drop the old history, we can always still do that, this time by dropping the ref in refs/archive/.
16:18:32 <zbyszek> So, I'm moving my +1 to puiterwijk's proposal
16:19:13 <jkosciel> a
16:19:46 <sgallagh> +1 puiterwijk
16:20:19 <zbyszek> nirik: ?
16:20:40 <nirik> +1 yes for this case
16:20:52 <nirik> and we should document this (releng sops? wiki?)
16:23:18 <puiterwijk> For those who want to learn more: git refspec is the term you're looking for (https://git-scm.com/book/en/v2/Git-Internals-The-Refspec), which defaults to "refs/heads/*:refs/remotes/origin/*"
16:23:25 <zbyszek> #agree Move branches with huge commits to refs/archive/ and create new sanitized branches (+6, 0, 0)
16:23:56 <zbyszek> OK?
16:24:41 <bowlofeggs> yeah
16:24:50 <nirik> yep
16:24:56 <zbyszek> #topic #1843 FAS bot account sponsoring
16:24:56 <zbyszek> .fesco 1843
16:24:58 <zodbot> zbyszek: Issue #1843: FAS bot account sponsoring - fesco - Pagure - https://pagure.io/fesco/issue/1843
16:24:58 <zbyszek> https://pagure.io/fesco/issue/1843
16:25:08 <zbyszek> jwb voted +1 in the ticket
16:25:19 <zbyszek> +1 to creating the account
16:25:40 <sgallagh> +1 to creating the account
16:25:59 <tyll_> +1
16:26:04 <jsmith> +1 (with comments on the ticket)
16:26:28 <bowlofeggs> i'm +1 to the idea, but i want to see sign off from infra in general, and from patrick for security
16:26:33 <puiterwijk> I think that the main thing that fesco needs to vote on is whether or not it gets sponsored as a packager.
16:26:35 <bowlofeggs> if the bot gets compromised that will be bad
16:27:10 <zbyszek> bowlofeggs: yeah, the code should be reviewed...
16:27:12 <nirik> we have done this before for the cockpit user I think...
16:27:13 <puiterwijk> bowlofeggs: well, so far the policy has been that since it's their responsibility, they're personally responsible if it gets compromised, just like any random packagers' machine
16:27:35 <puiterwijk> well, "policy".... What I've regard things as so far
16:28:04 <bowlofeggs> yeah if you are ok with that then i'm +1
16:28:37 <puiterwijk> Since it won't have any "special" permissions (i.e. just "packager"), I think that the security part of this should be handled as any random packager, since I can't audit packagers' machines either (nor would I want to.... That's a loooot of work)
16:28:50 <puiterwijk> And any random packager can write a script that does $randomstuff with their credentials
16:28:58 <puiterwijk> It just means they are solely personally responsible
16:29:15 <mhroncok> github has a policy that bot users has to have their owner in bio
16:29:34 <puiterwijk> mhroncok: we have a request by them to create the bot, we can track down the owner :)
16:29:44 <bowlofeggs> yeah that's a reasonable argument
16:29:49 <puiterwijk> Also, as with all packagers: the person who sponsors them is also partially responsible
16:29:56 <mhroncok> puiterwijk: sure, I mean it might be good idea to ahve the information visible in FAS somehow
16:30:31 <tyll_> +1 to make the info visible
16:30:37 <tyll_> maybe even in the name?
16:30:48 <zbyszek> nirik?
16:30:53 <tyll_> like usercont-bot
16:31:18 <nirik> +1 to it...
16:31:29 <bowlofeggs> how can any of you tell that i'm not a bot after all
16:31:42 * jsmith is now known as "botofeggs"
16:31:48 <bowlofeggs> hahaha
16:31:48 <sgallagh> bowlofeggs: You make more mistakes than most bots? ;-)
16:31:50 <puiterwijk> bowlofeggs: people have found out my "secret" long ago as well :)
16:31:50 <tyll_> also makes sense if the sponsor is from the user-cont team to make the relationship obvious?
16:31:57 <bowlofeggs> sgallagh: haha
16:32:07 <puiterwijk> tyll_: I'm not sure that they are sponsors. But yeah, if they are, that'd be great
16:33:10 <zbyszek> OK, so do we change the name from usercont to usercont-bot?
16:33:26 <bowlofeggs> sure
16:33:28 <nirik> there's no way to rename in fas.
16:33:32 <nirik> you would have to make a new account
16:33:54 <puiterwijk> .fasinfo usercont
16:34:02 <zodbot> puiterwijk: User: usercont, Name: None, email: the.conu.bot@gmail.com, Creation: 2018-02-13, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
16:34:05 <zodbot> puiterwijk: Approved Groups: cla_done cla_fpca
16:34:32 <puiterwijk> I'd personally say that I'd like the privacy flag removed and the email updated to their team email or something, and then the info added to its name. That should be enough
16:34:47 <zbyszek> puiterwijk: exactly
16:35:24 <bowlofeggs> i don't mind it not having bot in the name, but that would be nice
16:35:27 <bowlofeggs> i'm +1 either way
16:35:33 * tyll_ wonders how the bot signed the fpca
16:35:45 <bowlofeggs> i hadn't realized the account was already made
16:36:04 <bowlofeggs> the bot might also be violating google TOS, but that's not my problem :)
16:36:07 <puiterwijk> tyll_: by virtue of a human pressing the button. So again: on their personal name/term I'd say (legally)
16:36:36 <zbyszek> OK, it seems we are in agreemment.
16:36:49 <zbyszek> #agree FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot (+7, 0, 0)
16:37:13 <zbyszek> Almost there
16:37:14 <zbyszek> #topic The time of the next meeting.
16:37:14 <zbyszek> Fesco members, please respond to the whenisgood poll!
16:37:18 <puiterwijk> zbyszek: and also, provided that the owners accept they're personally responsible (I'd say)
16:37:34 <zbyszek> #undo
16:37:34 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x571091d0>
16:37:45 <zbyszek> #undo
16:37:45 <zodbot> Removing item from minutes: AGREED by zbyszek at 16:36:49 : FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot (+7, 0, 0)
16:37:47 <puiterwijk> (I think that goes automatically in my mind, but would like to make it explicit)
16:38:34 <zbyszek> what about this: FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot and that owners are responsible for any actions it takes the same as for their own actions
16:38:44 <bowlofeggs> +1
16:39:08 <puiterwijk> +1 (non-counting obviously)
16:39:15 <nirik> +1 sounds good
16:39:35 <zbyszek> #agree FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot and that owners are responsible for any actions it takes the same as for their own actions (+7, 0, 0)
16:39:38 <tyll_> +1
16:40:05 <zbyszek> I assume that everybody is fine with the slightly stricter provision.
16:40:07 <zbyszek> Let's move on.
16:40:09 <zbyszek> #topic The time of the next meeting
16:40:10 <mhroncok> did I miss https://pagure.io/fesco/issue/1857 or is that scheduled for nex meeting?
16:40:36 <zbyszek> #undo
16:40:36 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2fbd84d0>
16:41:12 <zbyszek> #topic #1857 Retiring Django packages
16:41:12 <zbyszek> .fesco 1857
16:41:14 <zodbot> zbyszek: Issue #1857: Retiring Django packages - fesco - Pagure - https://pagure.io/fesco/issue/1857
16:41:33 <zbyszek> Sorry, Idon' must have dropped it from the schedule
16:41:57 <mhroncok> np
16:42:13 <bowlofeggs> i had a thought on this: isn't there going to be an LTS django that does support python 2? if so, should we just get these packages to use that?
16:42:16 <zbyszek> +1 to the retiring
16:42:39 <bowlofeggs> or are they all so dead that it's better to retire anyway?
16:42:40 <nirik> bowlofeggs: it ends support soon. ;)
16:43:25 <bowlofeggs> it is telling that the maintainers have not responded on any of the BZs
16:43:33 <mhroncok> bowlofeggs: we only have that tls version as a compat package for apps
16:43:41 <mhroncok> not for packaged libaries nothing depends on
16:43:55 <tyll_> +1, I can also retire them
16:44:14 <bowlofeggs> yeah i'm +1 to retire, especially since these tickets have no responses from their maintainers
16:44:15 * mhroncok can retire them if agreed
16:44:16 <nirik> +1 here
16:44:17 <sgallagh> If they need to come back to life... we have modules
16:44:21 <bowlofeggs> they've been open for more than a month
16:47:16 <zbyszek> jsmith, vote?
16:47:40 <sgallagh> +1 retire, BTW
16:47:43 <jsmith> +1 retire
16:48:02 <zbyszek> #agree Retiring of Django packages is accepted (+6, 0, 0)
16:48:02 <zbyszek> #action mhroncok to do the retirement
16:48:09 <zbyszek> #topic The time of the next meeting.
16:48:22 <zbyszek> There hasn't been much movement on this...
16:48:56 <mhroncok> thanks
16:48:57 <zbyszek> I guess everybody who is here find the existing time feasible ;)
16:49:22 <bowlofeggs> yeah we got only 1 more response since last week, for a total of 6 responses
16:49:31 <bowlofeggs> and now we have only 3 30 minute slots available :/
16:49:46 <nirik> I don't like the current time, but I can live with it if it works for everyone else.
16:50:09 <bowlofeggs> should we ask people to see if they can reschedule some things to open up a more agreeable time slot?
16:50:14 <puiterwijk> bowlofeggs: so 3 meetings a week then?
16:50:18 <bowlofeggs> haha
16:50:33 <zbyszek> http://whenisgood.net/fesco2018roundtwo/results/ss5khfp
16:50:46 <nirik> sure, worth asking.
16:51:58 <tyll_> uh, I have actually more time, I thought this would be starting times
16:53:01 <bowlofeggs> oh i interpreted it as meaning that you are available for all the 30 minute blocks you select
16:53:19 <zbyszek> sgallagh dgilmore maxamilliohaven't repsonded
16:53:57 <zbyszek> *maxamillioon
16:54:06 <zbyszek> *maxamillioon
16:54:07 <puiterwijk> maxamillion ?
16:54:10 <zbyszek> *maxamillion
16:54:13 <zbyszek> Pff.
16:54:36 <sgallagh> I think I missed the email
16:54:55 <zbyszek> I'll resend to the three people.
16:55:00 <nirik> he is out spending time with his newborn...
16:55:00 <zbyszek> OK, let's move on.
16:55:15 <zbyszek> #topic Opne floor
16:55:33 * jsmith has nothing for the open floor
16:56:12 <zbyszek> Anyone?
16:56:18 * tyll_ will miss next meeting due to NHO
16:56:30 <nirik> tyll_: congrats! :)
16:56:37 <tyll_> nirik: thank you
16:56:39 <puiterwijk> tyll_: enjoy :)
16:56:42 <sgallagh> tyll_: \o/
16:56:44 <puiterwijk> and welcome!
16:56:49 <zbyszek> tyll_: nice!
16:56:50 <bowlofeggs> tyll_: congratskis!
16:56:55 <tyll_> thank you all!
16:57:27 <zbyszek> #topic Next week's chair
16:58:00 <zbyszek> I can do it again, I think I'm getting the hang of it. Unless somebody wants to.
16:58:50 <bowlofeggs> i did it last week, not it!
16:59:24 <zbyszek> OK, let's keep this under 2h.
16:59:53 <zbyszek> #action zbyszek will chair next meeting
16:59:53 <zbyszek> #action zbyszek will send a reminder e-mail about the meeting voting time
17:00:18 <zbyszek> Anything else? If not, I'll close in 30s.
17:00:46 <puiterwijk> zbyszek: note that 30s is already >2h, so "under 2h" is not possible anymore :)
17:01:02 <mhroncok> :D
17:01:04 <zbyszek> I'm ona slow connectoin. It was still <2h when I was typoing.
17:01:18 <zbyszek> Anyway…
17:01:21 <zbyszek> …
17:01:27 <zbyszek> Thank you all.
17:01:28 <zbyszek> #endmeeting