14:03:44 #startmeeting FESCO (2020-08-05) 14:03:44 Meeting started Wed Aug 5 14:03:44 2020 UTC. 14:03:44 This meeting is logged and archived in a public location. 14:03:44 The chair is King_InuYasha. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:44 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:03:44 The meeting name has been set to 'fesco_(2020-08-05)' 14:04:00 #meetingname fesco 14:04:00 The meeting name has been set to 'fesco' 14:04:12 #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 14:04:12 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek 14:04:13 hye hou 14:04:22 .hello2 14:04:23 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 14:04:26 .hello2 14:04:26 morning. 14:04:26 decathorpe: decathorpe 'Fabio Valentini' 14:04:28 hello 14:04:30 .hello kevin 14:04:31 nirik: kevin 'Kevin Fenzi' 14:04:33 .hello ngompa 14:04:34 huelluouo 14:04:34 King_InuYasha: ngompa 'Neal Gompa' 14:04:40 .hello2 14:04:41 dcantrell: dcantrell 'David Cantrell' 14:04:54 .hello2 14:04:54 ignatenkobrain: ignatenkobrain 'Igor Raits' 14:05:10 I am still busy with some day work, so ping me when I need to vote :) 14:05:49 .hello2 14:05:50 sgallagh: sgallagh 'Stephen Gallagher' 14:06:21 #topic init process 14:06:47 So, uhh, I failed miserably to remember to send the email agenda yesterday 14:07:08 I did just send it a few minutes ago, though 14:07:13 that's ok, I got other email :) 14:07:42 sorry folks :( 14:07:50 no worries. 14:08:01 I forgive you, though this will be noted in your permanent Fedora record 14:08:11 and then I nearly forgot about *this* because of juggling Flock sponsorship setup stuff :o 14:08:18 That's what meeting notes are for! 14:08:21 thanks zbyszek for reminding me :D 14:08:46 bah, I mean Nest :D 14:08:50 anyway, here we are 14:09:27 so... on with the agenda 14:09:43 #topic #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs 14:09:54 .fesco 2440 14:09:55 King_InuYasha: Issue #2440: F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs - fesco - Pagure.io - https://pagure.io/fesco/issue/2440 14:10:13 so this is the only real "followup" we have today, and it's a bit of a doozy 14:10:49 I'm not going to say this is a hot topic, but I'm pretty sure I just saw two hobbits throw a ring at it. 14:10:49 I also got some angry messages on IRC but those aren't on record 14:11:49 decathorpe: you mean about this topic? 14:11:57 * nirik isn't sure what to do here... I do want those areas of packages to get more automation... 14:12:37 Any sufficiently advanced technology is indistinguishable from magic 14:13:06 so there's a lot to unwrap here during review and this proposal really presents a problem where "if you can't explain an idea in about a paragraph, it's probably a bad idea" 14:13:20 there's no indication of the risks associated with this change 14:13:25 zbyszek: yes, about this topic :( 14:13:49 zbyszek: as did I... 14:13:53 I do not think it is unreasonable to ask for this proposal to be broken down in to more manageable chunks 14:14:00 for the sake of review 14:14:20 King_InuYasha: ironically, the one part I am most comfortable with in it is the detached RPM changelogs 14:14:27 dcantrell: haha 14:14:58 mhroncok: https://twitter.com/sgallagh_redhat/status/689139391344816130 14:14:59 my experience with detached changelogs that you have to update yourself manually is that they're not worth the trouble 14:15:02 dcantrell: If you said that a month ago, that'd be OK. But this ticket has been under discussion and review on multiple meetings, and I think it's too late to ask the author for this kind of change now. 14:15:56 zbyszek: yeah, no, I don't buy that. nothing is blocked by this change 14:16:10 what are the risks associated with this proposal and who owns the fallout from it 14:16:25 dcantrell: Go module support is blocked on it now 14:17:03 the Go packaging stuff is built on top of this framework he built 14:17:20 and he's rebuilt the font macros on top of it too 14:17:28 dcantrell: nim said that the changes are done in copr, so the change seems pretty safe. 14:17:32 yeah, ok, but neither of those things are urgent 14:17:51 are we all agreeing there are no risks with this change? 14:17:55 Not urgent, but we shouldn't block work. 14:18:25 I'm not deliberately trying to block work. Our job is to understand the changes from a technical standpoint and the risks to the project. 14:18:31 we're not here to just rubber stamp everything through 14:18:34 I guess I don't really understand the other side of it: will this impact existing users of "forge" macros, and if so: how? 14:18:43 I do agree there are risks, since he's going to be reworking all the forge macros as part of it 14:19:18 I guess we should ask eclipseo about this? he's been doing most of the Go packaging lately, as far as I can see. 14:19:20 but the "damage" is limited since only Go is using them at scale, and he's already going to fix everything he breaks there (I think?) 14:19:25 Can we just ask nim to create entirely new macros (%forge2, maybe?) first? 14:19:31 sgallagh: there's a compat layer in place. I think there's risk, there is always risk, but nim seems pretty determined to get this done. 14:20:00 are Go modules the only thing really impacted by this change? 14:20:18 we should probably avoid unexpected surprises to other packagers 14:20:27 dcantrell: "i18n, fonts and Go Changes that are/were envisioned for F33 or F34" (from the Change page) 14:20:28 fonts? 14:21:22 yeah, most fonts and go packages and everything that uses forge macros directly is impacted by this 14:21:55 are those package maintainers on board with this change or is this change owner agreeing to make all changes in impacted packages? 14:22:21 decathorpe: Do we know what else uses forge macros? 14:22:24 (Rust?) 14:22:38 Rust: no 14:22:55 * sgallagh looks for the tarball of all specs to grep through 14:23:10 the forge macros provide "generic" support for all sources hosted on GitHub / GitLab / pagure / bitbucket 14:23:12 sgallagh: various random packages. I used it a couple of newer packages myself. 14:23:20 https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz 14:23:34 Python and Rust do not use forge macros by default out of policy 14:23:35 nirik: thanks 14:23:52 for Rust, it's because they are unavailable in other distros, and Fedora Rust is a cross-distro effort 14:24:00 I'd feel more comfortable here if the impacted package owners were aware of and ok with the change. At least the major impacted package groups. And if this was documented in the change proposal 14:24:07 for Python, we're emphasizing fetching from PyPI, so it's less needed 14:24:48 https://paste.centos.org/view/f4ffc88f 14:25:57 sgallagh: that's useful. 140/2 ~= 70 looks managable, even if some manual adjustments are needed. 14:26:08 " Other developers: the way current forge macros call forge macros will need a little patching once the change lands. For other packagers, there should be no change except a warning in rpm build logs to switch to the new syntax before the compatibility layer is removed." 14:26:57 so, far less breakage than cmake 14:27:02 heh 14:27:04 * mhroncok hides 14:27:04 ha 14:27:18 :) 14:27:37 * King_InuYasha dies 14:28:06 ignatenkobrain and I are a third of way through on that... 14:29:04 in other words, let's not apply double standards here 14:29:14 if the impact is bad, it will be fixed 14:29:32 at this point, the only thing I don't want to permit is detached changelogs 14:29:55 Yeah, I think I'm coming down on the side of +1 at this point. 14:29:57 my questions have been answered 14:30:04 I'll vote +1 14:30:13 The list of packages don't seem to contain much in the way of critical bits. 14:30:22 (Other than redhat-rpm-macros, of course) 14:30:27 right 14:30:38 at this point, I think the stuff is too magical and I fail to understand it. I've been in the middle of discussing the forge macros with the chnage owner, rpm maintainers and FPC and I am not happy baout the way this has been communicated 14:30:43 hence, I vote 0 14:31:09 * zbyszek voted +1 in the ticket 14:31:31 I'm +1 because I'd prefer breakage and fixes to stagnation and stop-energy. 14:31:41 meh. how many + votes do proposals need? 14:31:48 decathorpe: +5 14:32:00 I'm +1... also leary of the detached changelog, but I dont' want to block progress with go/fonts 14:32:19 I am more on the +0 too with similar reasoning as mhroncok . I am bit worried about long term maintenance 14:32:26 (I don't disagree with what mhroncok said, but I also agree with what sgallagh said) 14:32:38 I'm still -1 14:32:47 (call me old grumpy man) 14:32:57 #proposal accept #2440 with the proviso that detached changelogs are not allowed for Fedora 14:33:13 King_InuYasha: 0 14:33:37 Maybe we can break the proposal up differently? 14:33:37 King_InuYasha: -1, I don't mind detached changelogs 14:34:09 King_InuYasha: yeah, this proviso seems completely out of the blue 14:34:09 dcantrell: if we were going to detach changelogs, I don't want a separate file to be managed on an ongoing basis 14:34:19 I want us to use our Git log instead 14:34:29 Proposal 1: Accept the parts of 2440 except for detatched changelogs 14:34:29 Proposal 2: Accept the detatched changelogs portion 14:34:50 King_InuYasha: Write a git hook that generates the separate file on commit? 14:34:54 not to mention, all the tools that work on changelogs will need adapting 14:34:55 * nirik has considered a setup like ansible uses... basically a dir with changelog fragments that are gathered for the changelog. 14:35:01 King_InuYasha: I agree with the git log approach, but despite that I think it's OK to allow people to experiment with other approaches. 14:35:14 If we implement something based on 'git log', it's going to be opt-in at first too. 14:35:15 zbyszek: additionally, detached changelogs has releng impact 14:35:18 King_InuYasha: the git log doesn't capture everything, certainly for package maintenance where you have a combination of patches to the package and rebases to new versions. a detached log is easier to maintain and if you make it a separate commit in git, then you can cherry pick patches to the spec file across branches without collisions 14:35:31 King_InuYasha: mass rebuild imact 14:35:52 a lot of scripts and tools will need adapting for detached changelogs 14:35:57 a format needs to be figured out, etc. 14:36:06 Before we get too far on debating this, could we vote on the split proposals I suggested? 14:36:13 I want to make sure we at least have agreement on P1 14:36:24 P1: +1 14:36:27 P2: -1 14:36:27 my vote is 0, 0 14:36:32 sgallagh: I am +1 on the original proposal, which includes the detached changelogs. is that proposal 2? 14:36:33 sgallagh: P1: +1 14:36:38 -1 on both 14:36:41 sgallagh: P2: I need to think about this 14:36:43 dcantrell: That would be +1/+1 14:36:59 -1 on both 14:37:00 +1/-1 14:37:06 sgallagh: I think -1/+1 for me? 14:37:12 dcantrell: P1 is just "accept the subset without changelogs and then discuss changelogs" 14:37:13 as in, I want the detached changelogs 14:37:32 Sorry if that was unclear. 14:37:35 dcantrell: in genereal? i would not mix that here 14:37:53 I want to make sure we have +5 for the macro changes *at all* before we argue over the changelog portion of it 14:38:18 dcantrell: note that nim was unwilling to commit to implementing any support for his detached changelog feature in tooling and infra 14:38:36 do we have all the votes? 14:38:39 P1 is... 14:38:46 I am unwilling to make all the rest of us figure it out as people randomly adopt it... 14:39:08 +3? 14:39:15 I do not understand what infra changes are required for detached changelogs. I say this as I currently use a detached changelog in at least two packages. I am -1/+1 14:39:16 If I'm counting right, we have +3, 2, -2 14:39:31 rpmdev-bumpspec won't work anymore... 14:39:40 dcantrell: That means you're voting against the forge macros? 14:39:47 dcantrell: releng scripts for mass builds, rpmdevtools, various parsing things for koji and friends, etc. will not work 14:39:58 at least, not right now 14:40:25 dcantrell: The proposals I put out are basically meant to treat this as two separate Change requests, one for the forge macros and one for the detached changelogs 14:40:26 sgallagh: I have no idea what format you're expecting here. I am +1 on the proposal as written, I don't want to exclude the detached changelogs 14:40:39 dcantrell: Then say +1/+1. 14:41:00 I will say +1/+1 but that does not map to what you wrote earlier 14:41:42 it does 14:41:52 that still makes it +4 14:42:13 (not checking the ticket for votes) 14:42:31 mhroncok: all the people who voted in the ticket also voted here 14:42:40 zbyszek: yes, I've checked that now 14:42:59 I am +1/0; I'm not sure if that's captured. 14:44:00 10:34 < sgallagh> Proposal 1: Accept the parts of 2440 except for detatched changelogs 14:44:02 10:34 < sgallagh> Proposal 2: Accept the detatched changelogs portion 14:44:05 I read P1 as "accept the proposal excluding the detached changelogs", which I do not want. I read P2 as "accept the proposal as written". Parse error on my end possibly. 14:44:17 +1 for proposal (disregarding chnagelogs) was King_InuYasha, zbyszek, nirik, sgallagh, dcantrell 14:44:25 dcantrell: Which is why I attempted to clarify that P2 was *additive*, not in conflict 14:44:28 is that correct? 14:44:40 that makes it +5 and we can figt about changlogs 14:44:46 ok 14:44:54 King_InuYasha: those are all reasonable things, but since it's not a required change for all packages, I think it's ok to include with this proposal since the rest of this isn't forced on everyone 14:45:11 -1 to changlogs withotu infra/releng buy-in 14:45:22 dcantrell: the problem is that if it's permitted, it *will* be used by nim for Go and fonts 14:45:30 and then everything will break 14:45:47 sgallagh: clarification not received earlier, we need to work on ircsed(1) 14:45:52 * nirik agrees with mhroncok there. 14:45:52 mhroncok: yeah, I didn't think abou the mass-rebuild/releng angle. 14:46:04 dcantrell: The concern is that this portion of the proposal requires tooling changes for releng to adapt if anyone is using it 14:46:05 nim doesn't write things to not use them 14:46:07 King_InuYasha: but where there are breaks, didn't nim state he would fix all problems? 14:46:11 no 14:46:17 he said he *won't* fix those things 14:46:18 And the proposal does not seem to indicate that nim will be doingt hat work 14:46:50 this is fun 14:46:52 I am +1 to all the stuff nim said he'd be willing to fix 14:47:07 he explicitly stated to me he will not fix infra software 14:47:12 Q: with those detached changelogs, does 'rpmspec -P' in the dist-git checkout show the spec file with the changelog? 14:47:12 On further reflection, I'm going to go with -1 on the changelog portion and ask nim to come back in F34 with a separate change proposal that includes buy-in from releng 14:47:29 I'll go back to my earlier statement that this proposal is too large. *sigh* 14:47:30 that 14:47:30 he did answer that in his faq... 14:47:43 something like "interested folks will fix it when they want it" or something like that 14:47:43 but his answer was the follow-on proposal 14:47:53 yeah, move me to a +1 on the proposal *except* the changelog part 14:48:04 if he isn't going to own fixing that fallout, then that is a problem 14:48:16 Third party bumpspec tools will break. "This is dealt with in the follow-up change" 14:49:37 nirik: well, by making people use his autobump stuff I think? 14:49:49 so we've got chain-build now for change proposals? 14:51:08 I think so 14:51:14 that's why I was so confused last week about this 14:51:24 they are effectively one extremely large proposal 14:51:29 decathorpe: yeah 14:51:31 * sgallagh wonders if we can just put people who submit propsals like this *in* chains... 14:51:36 so this proposal is a trojan horse? 14:51:51 to get the F34 proposal in because without it stuff is broken? 14:51:53 OK, so I'm ready to vote P2:-1 too. I don't think it makes sense to the detached changelogs in a way that breaks releng integration for at least one release. 14:52:17 If there's a change, it needs to be done together. 14:52:26 having looked at the effort to implement such things before, I am extremely wary of doing it for F33 14:52:47 f33 is already borked enough :( 14:52:54 * King_InuYasha sobs 14:52:56 we already have a ton of changes approved. the boat is rocking 14:53:08 Yeah, the time for any major changes in F33 is gone. 14:53:13 if he comes up with a concrete plan for F34 to implement this functionality and scopes it to include fixing infra software, I'm fine with it then 14:53:26 I think this is a F34 change tho 14:53:55 no, this is the F33 portion of the change 14:53:56 cverna: no, the followon one was 14:54:32 ah ok I assumed everything was F34 14:54:32 so where are we on votes? approve, but ask for no detached changelog? 14:54:42 more confusion :) 14:55:01 We're +6 on P1. 14:55:54 * cyberpear (a bystander) likes the change except the detached changelog part 14:56:05 (and I note we don't know if the change owner is ok with that or can remove the changelog part cleanly) 14:56:17 I modified my vote in the ticket. +1 for the proposal with the exclusion of detached changelogs 14:58:17 poke me when something happens :D 14:59:30 Maybe King_InuYasha hit quadratic behaviour when trying to tally the votes ;) 15:00:12 hah 15:00:19 do we have the votes for P2? 15:00:21 let's see... 15:00:28 P1: +6 15:00:46 P1: +6, 2, -1 15:01:20 that's not right. we have at least -2 15:01:42 revote? 15:01:52 yeah, I'm having trouble counting all this 15:01:55 -1 15:02:06 King_InuYasha: serial or parallel? 15:02:08 P1: +1, P2: -1 15:02:14 mhroncok: both :D 15:02:14 King_InuYasha: revote: P1: +1, P2: -1 15:02:17 P1: 0, P2: -1 15:02:23 -1 / -1 15:02:24 P1: +1, P2: -1 15:03:20 -1 / +1 (I think) 15:03:30 nirik: no, the other way around 15:03:42 nirik: that is not what you've been saying before :D 15:03:43 right, scrooled back up... +1 / -1 15:04:04 nirik: which is understandable at this hour :P 15:04:06 P1: +1, P2: -1 15:04:12 cverna? 15:04:22 zbyszek: abstained on the ticket just now 15:04:50 well, 6 minutes ago, but OK. 15:04:58 * nirik is also on another meeting. 15:05:13 nirik++ 15:05:28 nirik: I would die just being on this one 15:05:35 :) 15:05:37 #info proposal 1: accept #2440 sans detached changelogs (+5, 1, -2) 15:06:03 King_InuYasha: #agree? 15:06:14 zbyszek: i'm tallying 15:07:01 #info proposal 2: accept #2440 with detached changelogs (+0, 1, -7) 15:07:50 #agreed: accept #2440 sans detached changelogs, that is detached changelogs are not allowed for Fedora 15:08:05 King_InuYasha: I count mhroncok and cverna as 0, decathorpe and ignatenkobrain as -1, so it's (+5, 2, -2) 15:08:11 whoops 15:08:45 #info proposal 1: accept #2440 sans detached changelogs (+5, 2, -2) 15:09:05 #agree: accept #2440 sans detached changelogs, that is detached changelogs are not allowed for Fedora 15:09:08 blech 15:09:11 #agree: accept #2440 sans detached changelogs, that is detached changelogs are not allowed for Fedora 15:09:45 nevermind 15:09:48 onward 15:09:50 #topic Next week's chair 15:10:10 * mhroncok can 15:10:29 #action mhroncok will chair next meeting 15:10:36 #topic Open Floor 15:10:44 so clearly I fail at this :) 15:10:52 but any other business? 15:11:38 King_InuYasha: you'll do better next time. practice makes perfect 15:12:04 I have one item 15:12:09 sure 15:12:15 I wanted to ask ... is there anything we can do to make future mass rebuilds less painful than this one? :( 15:12:21 Can I get a clear set of goalposts for the damned ELN Modularity Policy Change? 15:12:26 Because I'm getting tired of them moving. 15:12:34 sgallagh: from my perspective, you're set 15:12:54 sgallagh: I've been saying from the start: discuss this with the wider community 15:13:02 sgallagh: you've volunteered to do a change proposal 15:13:04 decathorpe: if you have a few spare million you could buy us a mainframe. ;) 15:13:13 sgallagh: as soon as it was done, I've pointed out there is no ELN stuff in it 15:13:27 And I've been trying to figure out what you mean by that, because there is a VERY limited set of people who will run ELN. 15:13:36 sgallagh: you were on PTO, now you've edited the proposal, my stand is still the same 15:13:39 It's a prototyping environment 15:13:42 nirik: wait, let me see look the couch pillows 15:14:17 from my perspective, ELN is a side-along thing run by a SIG 15:14:36 and yes, it has substantial releng resource requirement, so that means I expect ELN to request scaling of releng resources as needed 15:14:49 but from the wider Fedora perspective, I think everything was done correctly 15:14:58 I disagree 15:14:59 mhroncok: My question for you is "what information do you think the wider community needs to provide?" 15:15:19 What output from such a discussion would affect FESCo's decision? 15:15:47 how does this impact the everyday java packager for example? 15:16:10 but that is juts one specific thing 15:16:19 by concern is general. we have chnage porcess for a reason 15:16:37 mhroncok: the idea is that it wouldn't impact them at all 15:16:43 King_InuYasha: haha 15:16:49 yeah, yeah 15:16:50 we clearly disagree 15:16:57 but that's not the point 15:17:02 approaching fesco directly with this is a no go for me 15:17:18 if you think this is stop energy, feel free to think so 15:17:19 The whole point of ELN is to try these things out without impacting anyone who hasn't opted in. 15:17:39 uh, as far as I can tell, Java modules are dead. so they're not going to be a problem for now 15:17:47 my view on this has however been very consistent, so don't tell me the goalposts are moving 15:17:53 Think of it as a RHEL-focused expansion of the "Fedora Playground" idea from years past 15:18:12 Fine, I'd like to call for a vote today, please. 15:18:38 -1 15:19:28 hold the horses, one sec 15:19:33 Note that in my opinion, allowing this will hurt Fedora, I simply wanted to hear other packagers' opinion on the topic to see if I am paranoid or if this is a common opinion. Without that, I am abviously biased. 15:19:47 *obviously 15:20:09 as a fesco memebr I try to represent our contributors, but without their input, I cannot do that 15:20:13 mhroncok: I acknowledge your opinion and your concerns. I am *trying* to do everything possible to *not* have that be the outcome. 15:20:16 #topic #2452 F33 Self-Contained Change: Policy for Modules in Fedora and Fedora ELN 15:20:47 sgallagh: form my stand point, it seem you are trying to do everything possible not to discuss this with the wider community, sorry :/ 15:20:55 Proposal: Accept the Change with the proviso that the Policy must clearly state that it currently applies only to ELN 15:21:04 that fact that you consider it not needed does not chnage my opinion on the subject 15:21:07 (I need to update the PR, but I haven't had the spare cycles lately) 15:21:12 sgallagh: +1 15:21:15 sgallagh: -1 15:21:27 sgallagh: -1, sorry, I don't believe in approving a TBD policy 15:21:35 sgallagh: +1 15:21:53 sgallagh: -1 15:22:00 sgallagh: ±0 15:22:14 We wouldn't do it for other changes, and here it seems particularly inappropriate, considering the history of this. 15:22:27 nirik, ignatenkobrain: ping for vote 15:22:29 What does "TBD Policy" mean here? 15:22:46 +1 15:22:47 zbyszek: the policy seems to be quite clearly defined at this point? 15:23:14 the acceptance of the Change would trigger merging the PR 15:23:17 -1 15:23:30 With one modification to add a clear statement that it only means ELN 15:23:37 yes 15:23:51 and I'm comfortable with permitting this with that proviso 15:24:44 King_InuYasha: no, it's not clear. The text states in various places that this is about Fedora, in other places that it's not about Fedora or EPEL. 15:25:09 zbyszek: mhroncok asked sgallagh to write it as if it would apply to Fedora globally 15:25:26 then afterward he had to go back and change things to indicate the ELN only-ness 15:25:57 I'd rather accept this with the condition so that we have a goal to clear rather than jerking around sgallagh more forever 15:26:21 +1 to that ^^ 15:26:30 King_InuYasha: iiuc, the goal was to have the policy describe what it means for Fedora clearly. 15:27:01 zbyszek: that was not how it was worded/requested from my recollection 15:27:32 well, it says "Policy for Modules in Fedora and Fedora ELN" so that implies it covers both 15:27:57 King_InuYasha: My ask was to clearly say what applies to Fedora and what applies to ELN 15:28:16 mhroncok: so what would 'discuss this with the wider community' be? devel list? wasnt it discussed there? 15:28:19 King_InuYasha: for now this is still open to interpretation 15:28:27 nirik: yes, no 15:28:42 The Change Proposal was announced there. 15:28:44 nirik: the chnage was proposed without specifing the impact on allowing defualt streams in Fedora or ELN 15:29:00 hence I've asked for clarification rigth away 15:29:16 now the clarification was added to the summary (but not the actual policy) 15:29:25 but this has since not been discussed with the community at all 15:29:53 I haven't updated the policy because I just haven't had the time lately, but I will correct that tdoday. 15:30:24 proposal: ask change owners to update the policy and/or respond to questions in the PR, announce again on fedora-devel that the final version is ready, and we'll vote again 15:30:26 I didn't want to keep making policy changes until I knew what exactly they needed to be, because every time I update it we apparently have to have another month of discussion... 15:31:01 no we don't 15:31:41 zbyszek: +1 15:32:27 sgallagh: we have a similar situation with something much simpler: the 3rd party repo policy. I have been editing the document over and over in response to comments. Writing policies is hard. I'll prepare another update today... 15:33:12 I suppose I must confess that I've been waiting for the churn on that one to slow down before I jump in and read it 15:33:29 Which I am forced to concede makes mhroncok's point about devel list 15:34:24 * decathorpe comes back from closing ~150 FTBFS bugs, did I miss anything important? 15:34:39 To me it feels incredibly too difficult to make any policy changes, we should be happy to iterate instead of wanting to have a perfect version 15:35:10 cverna: sure, but shouldn't vote when there are clear inconsistencies and unaswered questions. 15:35:44 And some of those questions are biggies like "what does this policy apply to". 15:36:07 decathorpe: there was a proposal a few lines up 15:37:34 zbyszek: thanks. I like your proposal 15:38:35 sure, +1 for the proposal, but perhaps to shorten the loop, one of you with objections could look at it and ack before the devel list post that it answers your concerns? 15:39:05 I think the current proposal is good enough to unblock sgallagh . Let's iterate from there 15:39:25 If the continuation of this policy is getting approval from the two people most vehemently opposed to the technology at all, we may as well just abandon it... 15:40:22 I don't mind tweaking the text to make it clearer. I will do that after this meeting. 15:40:34 I'm just concerned that this is just "running out the clock" 15:41:40 But whatever. I'll keep pushing this stone a while longer 15:41:45 FWIW, if the scope is clarified (default stream stuff does not apply to fedora, since currently not allowed there at all), then you'll get my +1 vote 15:42:04 decathorpe: that's what sgallagh and my proposal was earlier up 15:42:05 sgallagh: if you discuss this with the wider community and I relaize my concerns are pure paranoia, I will gladly ack it for you 15:42:15 sgallagh: if you refuse to do that, be prepared to hit a brick wall 15:42:17 I know 15:42:19 sgallagh: I looked at the latest version again, and I'm in the same position as decathorpe 15:42:42 Sorry if my frustration is coming through. 15:42:54 * mhroncok has been saying the same stuff for ages about this 15:43:01 I'd rather ack this with the requirement that it is updated accordingly rather than doing this over and over 15:43:02 (and by "clarified" I mean in the PR text and the change page.) 15:43:28 it's a waste of everyone's time and it's hugely demotivating 15:44:43