16:01:43 <maxamillion> #startmeeting FESCO (2017-10-13)
16:01:43 <zodbot> Meeting started Fri Oct 13 16:01:43 2017 UTC.  The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:43 <zodbot> The meeting name has been set to 'fesco_(2017-10-13)'
16:01:44 <maxamillion> #meetingname fesco
16:01:44 <zodbot> The meeting name has been set to 'fesco'
16:01:44 <maxamillion> #chair maxamillion dgilmore nirik jforbes jsmith kalev sgallagh bowlofeggs tyll
16:01:44 <zodbot> Current chairs: bowlofeggs dgilmore jforbes jsmith kalev maxamillion nirik sgallagh tyll
16:01:46 <maxamillion> #topic init process
16:01:50 <jsmith> .hello jsmith
16:01:50 <maxamillion> .hello maxamillion
16:01:50 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:01:53 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:01:55 <nirik> morning
16:02:06 <jsmith> afternoon :-)
16:02:18 <jforbes> .hello jforbes
16:02:19 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:02:19 <maxamillion> jsmith: morning ;)
16:02:45 <jforbes> I thought sgallagh was hosting today
16:03:13 <maxamillion> jforbes: something came up and he needed someone else to step in, I don't belive he will be in with us today
16:03:23 <bowlofeggs> .hello2
16:03:24 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
16:03:37 <jforbes> maxamillion: thanks for stepping in then
16:03:39 <tyll> .hello till
16:03:41 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
16:03:43 <maxamillion> jforbes: certainly :)
16:04:00 <maxamillion> alright, we have quorum and a long agenda so lets get rolling
16:04:04 <dgilmore> hola
16:04:23 <maxamillion> #topic Follow Ups
16:04:28 <maxamillion> #topic #1779 Consider fedora-* initscript units
16:04:28 <maxamillion> .fesco 1779
16:04:28 <maxamillion> https://pagure.io/fesco/issue/1779
16:04:30 <zodbot> maxamillion: Issue #1779: Consider fedora-* initscript units - fesco - Pagure - https://pagure.io/fesco/issue/1779
16:05:22 <tyll> are the any known technical rrasons the units cannot be disabled by default?
16:05:24 <sgallagh> I’m sort of semi-here. Home with a sick kid.
16:05:26 <nirik> note that the bug was updated very recently
16:05:48 <nirik> "leave fedora-load-modules.service disabled by default, and keep the other two enabled."
16:05:50 <bowlofeggs> the bug sounds like they might have reached some agreement? if so, do we need to step in still?
16:06:12 <maxamillion> ah ok
16:06:21 <nirik> https://pagure.io/fork/zbyszek/fedora-release/c/c0dbaabb816ac181e79f07244dc461f4ef65d86d
16:06:26 <bowlofeggs> i suggest we ping the fesco ticket to ask if they still need a decision from us
16:06:27 <nirik> there is the PR with some more info
16:07:03 <maxamillion> Proposal: Based on latest BZ update, ask if FESCo is still needed in the process and defer to next week if needed
16:07:11 <jforbes> sgallagh: sorry to hear that, I have a sick on here too, but he is old enough that I just have to check on him and make sure he takes his medicine when needed
16:07:12 <jsmith> maxamillion: Sounds good to me.  +1
16:07:25 <bowlofeggs> maxamillion: +1
16:07:26 <jforbes> maxamillion: +1
16:07:35 <dgilmore> I will merge the PR when it is rebased
16:07:37 <nirik> well, doesn't fesco need to approve the presets?
16:07:38 * maxamillion is +1 also, for clarity
16:07:59 <sgallagh> nirik: we set guidelines for when we do not need to
16:08:11 <dgilmore> I think the PR is reasonable and adresses everything
16:08:17 <maxamillion> nirik: do we? I was under the impression these are things that are already preset, they are just being moved into units instead of statically being set
16:08:28 <sgallagh> I think the current understanding fits those guidelines
16:08:33 <sgallagh> It was unclear originally
16:08:34 <nirik> well, they are static and moving to presets, but sure, +1 if everyone is happy
16:08:38 <maxamillion> sgallagh: welcome!
16:09:46 <maxamillion> dgilmore: sgallagh: tyll: what say you?
16:10:05 <sgallagh> In other words, I don’t think FESCo needs to rule on it, but +1 anyway
16:11:35 <tyll> I do not yet understand why they should be enabled by default, afaiu they are only needed for systems with remote FS?
16:12:44 <tyll> so if this is required for a system it sounds reasonable for me to just enable the services then on their image, isn't it?
16:13:13 <dgilmore> given they are enabled today it does not hurt anything
16:14:34 <nirik> well, they were enabled by iniscripts manually... they are moving to be enabled by presets
16:14:52 <nirik> they couldn't be enabled/disabled before, they were always enabled by initscripts
16:15:18 <nirik> and the idea is to not enable them by default in later releases, but that needs more work
16:15:47 <nirik> (I guess you could always mess with the links to enable/disable manually)
16:15:48 <bowlofeggs> yeah this seems like a step towards disabling by default without disabling them yet
16:15:54 <nirik> right
16:16:17 <bowlofeggs> and since they seemed to reach agreement, i don't think we need to do anything at this point
16:16:36 <maxamillion> agreed, I just want to clarify that is the case
16:16:43 <tyll> I understood that they could be removed in the future instead of just being disabled
16:16:57 <tyll> and the changes are required to get rid of them
16:19:24 <nirik> They would still be enabled by default because some things still use them... there was mention of fcoe... so if you wanted to boot/install a fedora media on a fcoe setup, you would need it to be enabled.
16:19:51 <nirik> you could make your own image, but that seems like a pretty high bar for something that worked before out of the box
16:20:01 <dgilmore> right
16:20:55 <jsmith> Anyway, we've spent 20 minutes on this topic... can we move on?
16:21:06 <bowlofeggs> +1 to move on
16:21:17 <bowlofeggs> and i'm still +1 to ask if fesco needs to do anything
16:21:33 <tyll> ok +1
16:21:41 <maxamillion> #agreed Proposal: Based on latest BZ update, ask if FESCo is still needed in the process and defer to next week if needed (+1:8, -1:0, +0:0)
16:21:48 <maxamillion> #topic #1780 F28 System Wide Change: Annobin
16:21:48 <maxamillion> .fesco 1780
16:21:49 <maxamillion> https://pagure.io/fesco/issue/1780
16:21:50 <zodbot> maxamillion: Issue #1780: F28 System Wide Change: Annobin - fesco - Pagure - https://pagure.io/fesco/issue/1780
16:23:13 <nirik> +1 here.
16:23:14 <bowlofeggs> the linked PR sounds unrelated
16:23:18 <jsmith> +1 from me
16:23:22 <maxamillion> +1 here as well
16:23:35 <jforbes> +1
16:23:37 <tyll> +1
16:24:24 <bowlofeggs> do we know how much larger this will make fedora's repos?
16:24:53 <bowlofeggs> sometimes mirrors dont' like if we suddenly get significantly larger
16:25:29 <maxamillion> bowlofeggs: fair point
16:25:32 <bowlofeggs> it does say "slightly larger"
16:25:38 <bowlofeggs> so maybe it's not "significant"
16:25:52 <bowlofeggs> and it does sound really useful
16:25:56 <jsmith> I doubt it's that much, but I don't have any concrete answers.
16:26:00 <nirik> someone asked that on the list and hasn't gotten an answer...
16:26:12 <nirik> "Nick should be able to provide some statistics. It's designed to be very small."
16:26:47 <sgallagh> +1
16:26:52 <bowlofeggs> https://pagure.io/releng/issue/7069 doesn'thave comments from releng yet either
16:27:42 <sgallagh> Unless we are talking >10%, the benefits are probably outweighing the increase.
16:27:49 <jsmith> "Note - the rawhide version of the binutils package includes the objcopy tool which could be used to reduce the size of the information recorded in executable by removing redundant, duplicate entries. The use of objcopy in this way is not currently enabled when linking programs, but it could be added if needed."
16:27:58 <jsmith> (from the Change page on the Wiki)
16:28:03 <maxamillion> bowlofeggs: looks like 32bytes per binary for 64-bit platforms if I'm readind this right -> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00000.html
16:28:04 <bowlofeggs> sure, i think i'm a +1
16:28:15 <maxamillion> reading*
16:28:30 <maxamillion> and 16bytes for 32-bit platforms
16:28:42 <maxamillion> 8 and 4-byte alignment on the struct respectively
16:29:00 <maxamillion> oh wait, no ... there's more properties
16:29:20 <maxamillion> 144 bytes?
16:29:36 <jsmith> I'm still +1
16:29:39 <maxamillion> anyhoo, not much
16:30:20 <bowlofeggs> +1
16:30:39 <maxamillion> bowlofeggs: if my estimate is right, across 50k binaries it would be a total of 6G of space
16:30:48 <maxamillion> so ... not nothing
16:30:54 <dgilmore> I am mostly +1 I would like to see some work done with QA to put tests in taskotron based on it
16:31:11 <maxamillion> #agreed APPROVED: F28 System Wide Change: Annobin (+1:8, -1:0, +0:0)
16:31:24 <nirik> dgilmore: excellent idea
16:31:40 <maxamillion> #topic New Business
16:31:42 <maxamillion> #topic #1767 F28 Self Contained Changes - Facter 3
16:31:42 <maxamillion> .fesco 1767
16:31:42 <maxamillion> https://pagure.io/fesco/issue/1767#comment-471878
16:31:43 <zodbot> maxamillion: Issue #1767: F28 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1767
16:32:13 <jsmith> On this one, I'm still not convinced about how much work it will be for people currently using Facter 2
16:32:46 <nirik> it's supposed to be compatible I thought
16:33:19 <nirik> oh I see... puppet moves to using ruby-factor...
16:33:21 <bowlofeggs> it switched from ruby to C++, but the change claims there are bindings
16:33:31 <jsmith> "The breaking changes occur at the 3.0 boundary:
16:33:31 <jsmith> https://docs.puppet.com/facter/3.0/release_notes.html "
16:33:35 <nirik> right.
16:33:44 <jforbes> There are bindings, it will be a dep change for puppet
16:33:50 <maxamillion> jsmith: +1
16:33:52 <nirik> sure, +1 here... moving forward
16:34:15 <tyll> +1
16:34:23 <jforbes> +1 here, there is only one dep and time to get that fixed
16:34:34 <maxamillion> +1
16:34:35 <bowlofeggs> +1
16:34:49 <jsmith> I guess I'm +1, but would like more information/documentation about breaking changes
16:34:58 * nirik will check the ansible facter module, but I would image it can handle the newer version
16:35:21 <maxamillion> nirik: +1
16:35:35 <maxamillion> sgallagh: what say you?
16:36:50 <sgallagh> maxamillion: 0 (I don't consider myself sufficiently well-versed in the problem)
16:37:06 <maxamillion> #agreed Self Contained Changes - Facter 3 (+1:7, -1:0, +0:1)
16:37:18 <maxamillion> #topic #1775 f27 modular server release planning
16:37:18 <maxamillion> .fesco 1775
16:37:18 <maxamillion> https://pagure.io/fesco/issue/1775
16:37:19 <zodbot> maxamillion: Issue #1775: f27 modular server release planning - fesco - Pagure - https://pagure.io/fesco/issue/1775
16:37:58 <langdon> My connection has been super flaky.. I'm here though
16:38:04 <maxamillion> langdon: o/
16:38:15 <langdon> I would like to defer this topic til next meeting
16:38:24 <sgallagh> tl;dr: We missed Go/No-Go and forgot to have a rain date scheduled. However, it seems like we can handle a one-week slip without pushing out final.
16:38:37 <sgallagh> langdon: That's... bold
16:38:43 <langdon> We coukdnt get our "release issues list" together in time and have it scheduled for monday
16:39:08 <maxamillion> langdon: alright
16:39:24 <langdon> Well.. We could ask for a 1 wk delay.. But I don't have good data to prove we have a chance
16:39:26 <nirik> me thinks a one week beta slip and staying on schedule sounds good for the plan now.
16:39:29 <sgallagh> langdon: I propose we just add the Rain Date based on a presumed single-week slip and if we don't make that, we look at slipping Final
16:39:30 <maxamillion> Proposal: Defer to next week's meeting to allow Modular WG to gather "Release Issues List"
16:39:48 <tyll> +1
16:39:50 <jsmith> maxamillion: +1
16:39:51 <langdon> I can definitely +1 sgallagh
16:39:57 <bowlofeggs> +1
16:39:58 <maxamillion> wait
16:39:59 <sgallagh> maxamillion: -1
16:40:02 <maxamillion> there's two proposals
16:40:09 <bowlofeggs> haha
16:40:19 <maxamillion> sgallagh: let's go with yours
16:40:29 <sgallagh> +1 ;-)
16:40:33 <nirik> +1 sgallagh
16:40:36 <bowlofeggs> sgallagh: what would the rain date be?
16:40:46 <bowlofeggs> (+1 to the idea of adding a rain date)
16:40:49 <maxamillion> Proposal: Add a presumed one-week slip to the Rain Date, flip Final if needed
16:40:49 <langdon> Tues after next
16:41:00 <langdon> To follow a 1 wk
16:41:10 <maxamillion> (don't need to re +1 ... I'll count them, just wanted to restate for posterity
16:41:10 <bowlofeggs> maxamillion: +1
16:41:10 <langdon> With go/no go next Thurs
16:41:14 <sgallagh> 10-24
16:41:16 <nirik> 24th.
16:41:17 <maxamillion> +1
16:41:19 <jforbes> +1
16:41:56 <jsmith> Still +1
16:41:58 <dgilmore> sgallagh: thats what I was thinking
16:42:21 <sgallagh> maxamillion: Patch for the #agreed: "Add a presumed one-week slip to be the Rain Date; slip Final if that isn't achieved."
16:42:30 <dgilmore> sgallagh: otherwise as it stands we have to push it all out a week given the miss of a green light to ship on Tuesday
16:42:35 <maxamillion> sgallagh: will do
16:42:47 * sgallagh nods
16:42:52 <dgilmore> +1 with the patch
16:43:24 <maxamillion> #agreed: Add a presumed one-week slip to be the Rain Date; slip Final if that isn't achieved. (+1:8, -1:0, +0:0)
16:43:36 <maxamillion> #topic #1781 qt5-qtwebengine maintainership, kde-sig access rights
16:43:36 <maxamillion> .fesco 1781
16:43:36 <maxamillion> https://pagure.io/fesco/issue/1781
16:43:39 <zodbot> maxamillion: Issue #1781: qt5-qtwebengine maintainership, kde-sig access rights - fesco - Pagure - https://pagure.io/fesco/issue/1781
16:44:00 <sgallagh> ugh, what a mess this one is
16:44:49 <bowlofeggs> i do feel like the new ability to send PRs to spec files might be the answer here
16:45:25 <sgallagh> I'm mostly in agreement with the final few comments
16:45:44 <nirik> I'd like to say for the record (I meant to mention this in ticket, but ran low on time), that I object strongly to "it is now my package." This is precisely why we moved away from the term 'owner'. Its a communty, you are managing a package for fedora, you don't own it.
16:46:02 <sgallagh> Though I also find Kevin's unwillingness to accept comaintainership (even by way of mentoring such a person) to be toxic to the long-term health of the package
16:46:06 <dgilmore> nirik: indeed
16:46:14 <jsmith> nirik: I tend to agree -- the package maintainer is a "steward" of the package, not an "owner" of the package.
16:46:38 <sgallagh> jsmith: Ooh, that would be a *much* better term than Point-of-Contact.
16:47:09 <maxamillion> sgallagh: agreed
16:47:11 <nirik> well, they arent quite the same.
16:47:31 <nirik> rdieter: you happen to be around?
16:47:47 <sgallagh> nirik: Well, point-of-contact isn't really appropriate either, IMHO. That's what foo-owner@ is for, really.
16:48:03 <jsmith> I'm not saying that what was done to the package by provenpackagers was 100% OK either, but I do think we need to be clear what "owning/stewarding/being PoC" for a package means
16:48:04 <rdieter> here, hi
16:48:06 <nirik> point of contact --> the address/account in bugzilla that the bug is assigned to.
16:48:09 <nirik> thats it
16:48:19 * sgallagh nods
16:49:02 <sgallagh> (Of course, we really *should* consider getting package-level issues out of BZ and onto dist-git Pagure...)
16:49:05 <nirik> rdieter: so I am not clear, how integral to the kf5 setup is this package? do you have to change it everytime you upgrade the stack?
16:49:05 <bowlofeggs> s/point of contact/person who receives emails from angry users/ ☺
16:49:26 <rdieter> nirik: we do not have to change it often
16:49:49 <sgallagh> bowlofeggs: Bad example; sending angry users to Kevin Kofler is a good way to convert them to "former users"
16:50:02 <rdieter> but I would like to be able to make changes the kde-sig has a consensus on, without worrying about the single veto (Kevin)
16:50:32 <sgallagh> rdieter: Would you settle for having FESCo override him when necessary? Or is the time overhead too great?
16:50:38 <maxamillion> which is fair, however Kevin does seem to have some valid concerns about patches and peer-review
16:51:37 <rdieter> sgallagh: *I* probably would begrudlingly.  Even though I would strongly prefer to not have to treat this single Qt5 module differently than all others
16:52:23 <maxamillion> which is also fair
16:52:25 <jsmith> Proposal: Ask Kevin to add a co-maintainer (or the KDE SIG), and strongly encourage all involved to communicate better about the package, to avoid the current concerns with patches and peer-review
16:52:31 <sgallagh> rdieter: As a different compromise, perhaps the KDE community could establish a mandatory, *public* code-review process?
16:52:34 <bowlofeggs> rdieter: has the kde-sig tried out the new pull request system with him? maybe it would be worth trying that approach?
16:52:49 <maxamillion> jsmith: Kevin has already been asked this and refused, why would FESCo asking be any different?
16:53:05 <jsmith> maxamillion: Because we're FESCO?
16:53:06 <rdieter> bowlofeggs: no
16:53:42 <rdieter> bowlofeggs: I do, however, have concerns about features being veto'd
16:54:09 <nirik> features? more than just updating/appliying bugfixes?
16:54:38 <rdieter> There are several packaging improvements that have been reverted already, simply because Kevin dislikes them personally
16:54:44 <bowlofeggs> in general i do think it's much more in the spirit of fedora to be "friends" and welcome co-maintainership of packages, but i don't know of a policy that requires maintainers to accept co-maintainers. is there such a policy?
16:55:17 <nirik> bowlofeggs: not that I know of. we encourage co-maintainers... we could of course make such a policy
16:55:34 <rdieter> nirik: I have in mind one workaround for nouveau crahes, Kevin will certainly object.  He strongly feels since it's a driver bug, it should be fixed in the driver (even though it's been unfixed now for 6+ mos)
16:55:44 <tyll> could the festures become packaging guidelines?
16:55:47 <bowlofeggs> i do recall some text somewhere on the wiki that *recommends* having 2-3 co-maintainers
16:55:50 <jforbes> No such policy exists that I am aware of. But the real question here is what is in the long term best interest for the Fedora community
16:56:13 <jsmith> jforbes: +1
16:56:47 <bowlofeggs> jforbes: +1 from me too
16:57:26 <jforbes> rdieter: That's all well and good on principal, but the reality is nouveau is fighting an uphill battle with walls being thrown up all of the time. Waiting for a nouveau fix in the driver and not applying a bandaid is ill advised
16:58:20 <maxamillion> jforbes: which rdieter seems to be in agreement with but Kevin is not
16:58:22 <rdieter> jforbes: indeed, why I'm here
16:58:38 <maxamillion> I'm super conflicted about this one
16:58:50 <bowlofeggs> yeah i feel the same
16:59:16 <bowlofeggs> kkofler isn't violating an established policy (though i agree we could make one, of course)
16:59:48 <sgallagh> On the one hand, taken in a vacuum I agree with Kevin that there is validity in not overriding a long-term maintainer's decision without a strong reason.
16:59:56 <bowlofeggs> on one hand, we finally have tech to help a little (pull requests), though that wouldn't help the noveau issue (though FESCo could make a ruling on that particular disagreement?)
17:00:35 <sgallagh> On the other hand, we have a maintainer who is not appearing willing to entertain any external input, and that's not healthy for the Project as a whole.
17:00:41 <bowlofeggs> true
17:01:21 <nirik> and is a single point of failure... (not that we don't have those on other packages too)
17:01:45 <tyll> sgallagh: he has agreed/proposed to review prs
17:01:57 <sgallagh> Yeah, I was excluding single-point-of-failure on the grounds that it's not unique to this package
17:02:28 <maxamillion> nirik: right, but those other single point of failures don't actively attempt to remain as such (at least not that I know of)
17:02:30 <sgallagh> tyll: But he's refusing to ack ones that fix actual problems; that's a failure in the process
17:03:43 <bowlofeggs> would it be too burdensome if we invited all disagreements between the sig and kevin to be raised to FESCo? like, would there be so many that that just wouldn't do?
17:04:05 <sgallagh> I was just writing a proposal to that effect, with a catch at the end.
17:04:22 <rdieter> .bug 1376107
17:04:23 <zodbot> rdieter: Bug 1376107 – kmail etc crash with 16.08.1 using nouveau - https://bugzilla.redhat.com/1376107
17:04:24 <rdieter> if it matters ^^
17:04:34 <tyll> rdieter: thx
17:04:36 <jforbes> I am afraid it would be a short lived arrangement, but I am willing to give it a try
17:04:40 <sgallagh> Basically, if this becomes frequent (subjectively), we will reserve the right to take the package away
17:04:51 <maxamillion> rdieter: thanks
17:05:17 <rdieter> would fesco be ok too to not allow the desktop team to be able to commit to some lowlevel gtk library ?
17:05:41 <sgallagh> rdieter: With respect, it's unlikely that situation would arise :-/
17:05:50 <rdieter> sgallagh: does it matter?
17:06:29 <rdieter> the only reason this is happening is because Kevin swooped in to help a stalled package review
17:06:51 <sgallagh> rdieter: I think we'd be in the same situation we are today if, hypothetically, a desktop member decided to establish a fiefdom.
17:06:55 <bowlofeggs> what if we granted kde-sig commit access, but also asked disagreements to be arbitrated by fesco, with sgallagh's terms that we reserve the rights to take packages away if too much toxicity arises??
17:07:00 <rdieter> which would really nice at the time, yay help!  but now I very much regret allowing it to happen that way
17:07:08 * sgallagh nods
17:07:24 <sgallagh> bowlofeggs: Kevin has explicitly stated that if we do that, he'll revoke the privileges.
17:07:38 <bowlofeggs> sgallagh: well, we can tell him not to, and that if he does we take it away?
17:07:39 <rdieter> bowlofeggs: you really don't think that level of toxicity has been reached yet?
17:07:41 <maxamillion> bowlofeggs: I like that, I'm not sure how well it would play out but I like it ... it promotes collaboration
17:08:01 <bowlofeggs> rdieter: i didn't mean to imply it isn't toxic today, sorry
17:08:34 <maxamillion> rdieter has a fair point
17:08:58 <bowlofeggs> basically, i'm sure there must be *some* changes that wouldn't be controversial (like upgrading to a bugfix release or something)
17:09:12 * lupinix agrees with rdieter @toxicity, we (kde sig) lost one member due to kevin koflers behaviour
17:09:23 <bowlofeggs> and for controversial changes, we can decide on them case-by-case?
17:09:24 <lupinix> with respect to qtwebengine
17:09:45 <lupinix> hi all btw :)
17:09:57 <maxamillion> hello lupinix
17:10:09 <sgallagh> I still think that we might get further by asking KDE SIG to establish a well-documented pull request policy and getting Kevin to agree to it.
17:10:23 <sgallagh> Then we can add KDE-SIG as a comaintainer under the provision that they abide by the policy.
17:10:27 <CRCinAU> I'm just here to see what's going on - because it seems I'm saying "For fucks sake, we're not going over this shit again" every week or so ;)
17:10:53 <bowlofeggs> i like the policy idea
17:10:58 <tyll> sgallagh: +1
17:11:04 <sgallagh> rdieter: Is that something that might work?
17:11:32 <nirik> I'm not sure he would agree to any such policy, but we could try it...
17:11:37 <maxamillion> the toxicity thing concerns me honestly, if there's a history of lost contributors due to a community members actions, they are not upholding the mantra of inclusivity for the community
17:11:38 <bowlofeggs> but would the policy address controversy?
17:11:47 <bowlofeggs> maxamillion: +1
17:11:54 <rdieter> sgallagh: it's better, but I don't have to like it.
17:12:11 <CRCinAU> From someone who is sick of hearing it all the time - I'm not sure 'agreement' is viable for anything other than "Leave me with MY package"
17:13:06 <sgallagh> nirik: I'd be willing to add "failure to come to an agreement on a policy will result in loss of maintainership of the package"
17:13:10 <sgallagh> As an incentive :)
17:13:29 <lupinix> sgallagh: +1
17:13:31 <CRCinAU> rdieter: remember the time I spent ~1-2 hours trying to explain the whole deal with him? I'm still not sure I achieved anything long term :(
17:13:55 * lupinix remembers, he also tried that…
17:14:16 <rdieter> sgallagh: as long as such policy includes that changes agreed-upon by kde-sig cannot be vetoed
17:14:17 <jforbes> Something to think about, kde-sig has provenpackagers.   Would "co-maintainer" status really change anything?
17:14:30 <CRCinAU> sgallagh: I can tell you what that will get: "You're stealing my packages from me."
17:15:09 <jsmith> Time check -- we've got a lot on the agenda today...
17:15:11 <nirik> they are not his packages. :)
17:15:11 <sgallagh> It sounds to me like the conversation is changing from "we have a problem with this package" to "we have a problem with Kevin". Which is a different (but equally important) problem.
17:15:17 <jforbes> It isn't like there are people wanting things fixed and don't have commit rights, it is higher level than that.
17:15:24 <jsmith> Are we ready to make a proposal / vote / move on?
17:15:31 <rdieter> sgallagh: it's a little of both, honestly
17:15:42 <sgallagh> Sure, but they might have different results.
17:15:46 * nirik tries to form a proposal.
17:16:09 <sgallagh> If the problem is presented as "Kevin is toxic", then the solution might be to strip him of his packager status. (I am not advocating this at this time)
17:16:18 <rdieter> sgallagh: if keven wasn't a problem, I wouldn't be here
17:16:35 <CRCinAU> sgallagh: sadly its inter-twined - so one ends up turning into the other....
17:16:47 <lupinix> jforbes: when a provenpackager makes commits where kevin thinks they are wrong, kevin just reverts them, so we need a clear ownership here
17:17:00 <lupinix> rdieter just made that experience some days agi afair
17:17:03 <lupinix> *ago
17:17:10 <dgilmore> do we need to have someone supervise kevin for awhile?
17:17:17 <jforbes> lupinix: that was my point, adding a co-maintainer wouldn't change the outcome there
17:17:23 <rdieter> sgallagh: I would strongly prefer he remain as a package maintainer here, he's done very good work with it.  It's just that there's no collaboration
17:17:31 <CRCinAU> my best summary would be: Kevin does do some great work, but does not play well with others.
17:17:32 <nirik> proposal: FESCo will add kde-sig to committers. kde-sig will use the PR workflow for their changes. When 2 kde sig members approve a PR it can be merged. Reverts/conflicts go to fesco for further action.
17:17:48 <lupinix> CRCinAU: exactly
17:17:54 <sgallagh> rdieter: Well, if he's reverting changes without consultation, then there's little we can do about that short of stripping his packager privileges.
17:17:54 <bowlofeggs> nirik: +1
17:18:06 <sgallagh> Putting him in a position where he can only contribute via PR
17:18:07 <jsmith> nirik: I think that proposal sounds like a fair balance
17:18:20 <jsmith> sgallagh: I don't read it that way
17:18:33 <tyll> imho tgere should also be reasonable time for kevin to give feedback on prs
17:18:34 <sgallagh> jsmith: Read what which way?
17:19:05 <rdieter> sgallagh: true, good point.
17:19:13 <jsmith> sgallagh: Never mind -- I misread your comment
17:19:31 <jsmith> Anyhoo -- I'm +1 to nirik's proposal
17:19:34 <nirik> tyll: good point
17:20:09 <jsmith> One other open source community I'm in uses a "two +1s and 48 hours" rule...
17:20:18 <jforbes> he is typically not one to ignore things. I expect feedback won't be an issue
17:20:26 <nirik> I'm not sure a set time makes sense, but a day? or at least time enough for them to comment
17:20:27 <CRCinAU> nirik: +1 (even though I'm not sure my vote counts for squat) ;)
17:20:30 <jforbes> well, lack of feedback
17:20:32 * maxamillion is +1 to nirik's proposal
17:20:35 <jsmith> jforbes: I agreej
17:20:39 <jsmith> Agree, that is
17:20:43 * jsmith can't type today
17:20:51 <sgallagh> How about 2 +1s with an option for an additional +2 to overrule him (for a total of +4 when he disagrees)?
17:20:54 <maxamillion> CRCinAU: not for the FESCo count, but it's good to get perspective from the KDE SIG so it's appreciated
17:20:56 <lupinix> with one exception: rebuilds without any changes (required for qt rebuilds) should be possible without delay by kdesig members
17:21:21 <CRCinAU> hey - I'm just an end user that annoys the hell out of people with bug reports ;)
17:21:39 <maxamillion> CRCinAU: that has so much value, you don't even know
17:21:49 <maxamillion> CRCinAU: can't fix what we don't know about :)
17:21:54 <nirik> sgallagh: how many active members does the kde sig have?
17:22:05 <CRCinAU> maxamillion: don't worry, I let you know about it ;) LOL
17:22:05 <sgallagh> nirik: Good question.
17:22:09 <sgallagh> rdieter: ^^
17:22:38 <rdieter> nirik: officially 9, but active?  probably closer to 5-6
17:22:59 <sgallagh> rdieter: So would +4 to override Kevin's veto be reasonable?
17:23:00 <jforbes> Then that would work
17:23:03 <lupinix> i guess the same
17:23:07 <jforbes> +1 sgallagh
17:23:45 <nirik> we could make it more and more complex, but I think simple is better...
17:23:59 <maxamillion> nirik: +1
17:24:11 <CRCinAU> I think the "but everyone has to do it now" will probably be easier to swallow to.... its not action against an individual then...
17:24:41 <rdieter> sgallagh: yes
17:26:08 <nirik> so, new proposal?
17:26:18 <rdieter> sgallagh: unfortunately, kevin likes to game the system, the pessimist in me expects to need +4 every time :-/
17:26:18 <tyll> CRCinAU: +1
17:26:44 <sgallagh> Proposal: We add KDE SIG as a comaintainer. In general, it will require 2 KDE SIG members to approve a Pull Request. In the event that Kevin still refuses, an additional 2 may overrule him.
17:26:58 <bowlofeggs> sgallagh: +1
17:27:08 <maxamillion> sgallagh: +1
17:27:12 <sgallagh> rdieter: If that happens more than once in a month, come back to FESCo and we'll reconsider his status
17:27:13 <dgilmore> +1
17:27:13 <tyll> rdieter: we can still revisit this if it does not work
17:27:13 <jforbes> sgallagh: +1
17:27:15 <bowlofeggs> sgallagh: don't forget the bit about how he can't drop them as co-maintainer
17:27:32 <maxamillion> oh right
17:27:35 <tyll> sgallagh: +1
17:28:34 <nirik> +1
17:28:38 <sgallagh> But yeah, if he drops the SIG as a comaintainer in defiance of FESCo, there will be consequences.
17:28:42 <bowlofeggs> and i'm also +1 to revisiting if this doesn't work
17:28:43 <jforbes> bowlofeggs: seems if that happens he would be in violation of FESCo's mandate on the matter and the next FESCo conversation would be on taking away the package
17:28:51 <bowlofeggs> jforbes: true
17:29:28 <jsmith> I'm +1
17:29:33 <jsmith> (and I'll be back in a few minutes)
17:31:26 <maxamillion> alright, who we missing? I'm counting 7 votes
17:33:00 <maxamillion> eh, we have the votes ... we'll move on
17:33:03 <bowlofeggs> maxamillion: did you count sgallagh ?
17:33:08 <bowlofeggs> (since he proposed it)
17:33:14 <maxamillion> bowlofeggs: I did not
17:33:19 <sgallagh> Right, I'm +1 to myself. Sorry I forgot to say it explicitly
17:33:26 <maxamillion> #agreed Proposal: We add KDE SIG as a comaintainer. In general, it will require 2 KDE SIG members to approve a Pull Request. In the event that Kevin still refuses, an additional 2 may overrule him. (+1:8, -1:0, +0:0)
17:33:40 <bowlofeggs> i think we can generally assume that if someone proposes something, they are a +1 wihtout having to explicitly say so
17:34:03 <maxamillion> right
17:34:03 * nirik can add them now
17:34:06 <maxamillion> I just missed it
17:34:18 <maxamillion> #topic #1782 use of updates-testing for testing of non-update software
17:34:19 <maxamillion> .fesco 1782
17:34:19 <maxamillion> https://pagure.io/fesco/issue/1782
17:34:21 <zodbot> maxamillion: Issue #1782: use of updates-testing for testing of non-update software - fesco - Pagure - https://pagure.io/fesco/issue/1782
17:34:23 <rdieter> thanks everyone
17:34:24 <puiterwijk> nirik: maybe first write it in the ticket, so he knows what's agreed on?
17:34:35 <nirik> sure, fair enough. will wait for that
17:34:58 <lupinix> thanks everyone
17:35:56 <maxamillion> puiterwijk: done
17:36:03 <bowlofeggs> i stand by the comment i made here yesterday - updates-testing should only have things that are intended to be released to stable
17:36:12 <sgallagh> bowlofeggs++
17:36:12 <bowlofeggs> and copr should be used for experiments
17:36:17 <maxamillion> bowlofeggs++
17:36:17 <zodbot> maxamillion: Karma for bowlofeggs changed to 15 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:36:21 <bowlofeggs> copr is perfect for this
17:36:26 <bowlofeggs> heyo!
17:36:28 <bowlofeggs> haha
17:36:31 <bowlofeggs> thanks ☺
17:36:35 <jforbes> I am definitely in agreement there, plenty of places for long term testing
17:37:11 <jforbes> And we certainly do not want to discourage people from actually testing updates-testing because it turns into rawhide 2
17:37:38 <maxamillion> jforbes: +1
17:37:44 <nirik> yep
17:38:31 <bowlofeggs> i also appreciate mattdm's point about how rawhide shouldn't even be used for experiments
17:38:56 <jsmith> jforbes: I agree...
17:38:57 <jforbes> bowlofeggs: Agreed, though this doesn't really seem like an experiment, more of a long term testing of what's coming
17:39:08 <bowlofeggs> true
17:39:10 <jsmith> We have copr and scratch-builds for that :-)
17:39:25 <maxamillion> yeah
17:39:36 <maxamillion> alright, so do we have a policy proposal somewhere in all this?
17:39:59 <nirik> we need to update the updates_policy wiki page
17:40:17 <nirik> perhaps someone would be willing to draft something and we could vote on it next week?
17:40:32 <jforbes> I can do that
17:40:35 <sgallagh> bowlofeggs: Did mattdm say that too? I think that was my oroginal reply as well
17:40:41 <sgallagh> (Which is to say, I agree)
17:41:06 <maxamillion> nirik: +1
17:41:29 <tyll> thx jforbes
17:41:34 <nirik> thanks jforbes
17:41:53 <maxamillion> #info jforbes will create a Policy change proposal to be voted on next week
17:42:16 <bowlofeggs> sgallagh: yeah the last comment
17:42:41 <maxamillion> I think this is basically the same ticket coming up next
17:42:42 <maxamillion> #topic #1783 Firefox 57 and the Updates Policy
17:42:42 <maxamillion> .fesco 1783
17:42:43 <maxamillion> https://pagure.io/fesco/issue/1783
17:42:44 <zodbot> maxamillion: Issue #1783: Firefox 57 and the Updates Policy - fesco - Pagure - https://pagure.io/fesco/issue/1783
17:42:56 <jforbes> Well, this is a slightly different ticket
17:43:01 <nirik> well, this is this specific case.
17:43:03 <sgallagh> Sorry folks, I need to drop.
17:43:18 <jforbes> sgallagh: thanks, hope your kid feels better soon
17:43:29 <sgallagh> Thanks
17:43:48 <maxamillion> sgallagh: have a good one, hope the kiddo is doing better soon
17:44:09 <nirik> I have a straw man proposal to try: proposal: firefox 57beta is removed from f25/f26 updates-testing... but stays in f27/rawhide. When final is out maintainer is encouraged to allow extra time in f25/f26 for testing.
17:44:45 <maxamillion> nirik: +1
17:44:47 <dgilmore> nirik: sure
17:45:28 <tyll> nirik: +1
17:45:42 <nirik> that allows f27 to ship with something close to final firefox 57 (it releases a week later)
17:45:46 <jforbes> Right, so this goes similar to the kernel rebase, we let rebases sit in updates-testing for a while longer than usual before pushing. But from the way I read this, FF57 is pretty much going to need to be pushed
17:46:08 <jforbes> +1 nirik
17:46:17 <nirik> and at upgrade points people are more aware of looking for what broke in their workflow.
17:46:27 <nirik> instead of a week after they have upgraded
17:46:41 <bowlofeggs> nirik: +1
17:46:46 <nirik> but ff57 really should have been/should be a change.
17:46:55 <bowlofeggs> also +1 to that ☺
17:47:18 <nirik> perhaps we should ask for a late one now?
17:47:30 <bowlofeggs> i guess there's no possibility to downgrade to the ESR release, because that'd probably be a regression
17:47:44 <nirik> it breaks users profiles
17:47:46 <jforbes> Agreed because of the compatibility issues, it should be communicated as a change, but I don't think it could be turned down
17:47:50 <bowlofeggs> that might be jsut as problematic as upgrading to 57 would be
17:48:09 <nirik> jforbes: yeah, just more for the 'hey, this is happening and you need to be aware'
17:48:22 <jsmith> Agreed
17:48:36 <nirik> perhaps a magazine article or two before release would be good too.
17:48:50 <jforbes> nirik: +!
17:48:54 <jforbes> +1 even
17:48:59 <tyll> +1
17:50:55 <nirik> so, should I add all that in a new proposal? or are we good...
17:51:11 <maxamillion> I'm good
17:51:17 <maxamillion> #agreed firefox 57beta is removed from f25/f26 updates-testing but stays in f27/rawhide. When final it out, maintainer is encouraged to allow extra time in f25/f26 for testing (+1:7, -1:0, +0:0)
17:51:58 <maxamillion> #topic Next Week's Chair
17:52:02 <maxamillion> who's up?
17:52:42 <jforbes> I can take it
17:53:04 <maxamillion> #info jforbes to chair next week's meeting
17:53:12 <maxamillion> #topic Open Floor
17:53:18 <maxamillion> anything here?
17:53:39 * dgilmore will not be here next week
17:54:00 * nirik will not be here week after next.
17:54:49 <jforbes> If there is no quorum I will grab the week after then
17:56:32 <maxamillion> I'll be here I think
17:56:34 <maxamillion> fwiw
17:56:55 * jsmith will not be here next week
17:56:58 <jforbes> Well, I expect enough will, but just stating so we know there is coverage
17:57:17 <maxamillion> +1
17:57:33 <maxamillion> alright, I'll give it a few minutes and close up shop
17:58:06 <jsmith> Thanks maxamillion :-)
17:58:29 <maxamillion> certainly
17:58:32 <maxamillion> was a long one :)
18:01:13 <jforbes> thanks maxamillion
18:01:24 <jforbes> maxamillion++
18:01:25 <zodbot> jforbes: Karma for maxamillion changed to 9 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:04:09 <maxamillion> #endmeeting