15:00:00 <bowlofeggs> #startmeeting FESCO (2019-04-29)
15:00:00 <zodbot> Meeting started Fri Apr 26 15:00:00 2019 UTC.
15:00:00 <zodbot> This meeting is logged and archived in a public location.
15:00:00 <zodbot> The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'fesco_(2019-04-29)'
15:00:02 <bowlofeggs> #meetingname fesco
15:00:02 <zodbot> The meeting name has been set to 'fesco'
15:00:04 <bowlofeggs> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:04 <zodbot> Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:06 <bowlofeggs> #topic init process
15:00:15 <mhroncok> hey hou
15:00:22 <jforbes> .hello2
15:00:23 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:38 <sgallagh> I'm kind of here, but also quite sick and medicating this morning.
15:00:51 <bowlofeggs> sgallagh: oh bummer - hope you feel better
15:01:03 <bcotton> .hello2
15:01:04 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:28 <zbyszek> .hello2
15:01:29 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:29 <bookwar> .hello2
15:01:30 <nirik> morning
15:01:32 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:02:02 <nirik> .hello kevin
15:02:06 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:03:34 <bowlofeggs> suhweeet suhweeet quorum
15:03:47 <bowlofeggs> #topic #2088 F31 Change – “dnf --best” as default behavior
15:03:49 <bowlofeggs> .fesco 2088
15:03:51 <zodbot> bowlofeggs: Issue #2088: F31 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088
15:04:13 <zbyszek> After some consideration, I'm still strongly -1 on this.
15:04:50 <zbyszek> This will be another case where we degrade user experience to solve an issue which is better handled through automatic checks.
15:05:17 <mhroncok> I think that jmracek haven't answered all the questions.
15:05:35 * nirik tries to swap back in this thing
15:05:36 <zbyszek> If dnf output is not easy to parse, then please output a warning at the end of the transaction in bold red letters.
15:05:59 <bowlofeggs> i worry a bit that a third party repo being broken could cause users to miss important updates from our repos
15:06:36 <zbyszek> Or a broken modular package could do the same, see the mail mhroncok posted today.
15:06:38 <jforbes> Yeah, that is a problem
15:06:52 <zbyszek> Or some obscure python2 package that nobody cares about would have the same effect.
15:07:07 <mhroncok> "maybe dnf could default to --best only for security updates?"
15:07:14 <mhroncok> that i think is a possible way to go
15:07:25 <mhroncok> I'm not saying it's easy
15:07:30 <nirik> that makes things even more complex tho... ;(
15:07:49 <jforbes> much more complex
15:07:50 <zbyszek> Yeah, I'd amend that proposal:
15:08:29 <zbyszek> if security updates are involved, print a warning at the end of transaction in red saying: some updates were skipped, INCLUDING SECURITY UPDATES. Try ...
15:09:07 <nirik> BTW, there is likely no way this would be possible to do for f30 ga. ;)
15:09:12 <zbyszek> This will keep things working for users, while solving the problem of missed updates being hard to notice.
15:09:12 <bookwar> mhroncok: i wouldn't make such a difference, it will confuse people a lot. Better to have clear messages as zbyszek suggests
15:09:23 <bowlofeggs> yeah if dnf told the users that security updates were skipped because of this, and if it also told them how to get the updates, that would assuage my concerns
15:09:36 <nirik> I guess their thought is that failing is a better way to get users attention...
15:09:46 <bowlofeggs> i think we should also consider otaylor's concerns about differing behavior between gnome software and dnf as well
15:10:03 <zbyszek> nirik: the change is marked for F31
15:10:23 <nirik> ah, I read the Note: at the top...
15:10:29 <nirik> Note: We are aware of the fact that this is a late proposal for Fedora 30, however, we think it is very important from the security standpoint.
15:10:32 <bowlofeggs> yeah it used to be for F30
15:10:52 <bowlofeggs> during one of our previous meetings we voted that it couldn't go for F30 because it was too late
15:10:59 <nirik> right, it is.
15:12:00 <bowlofeggs> i think i could be ok with zbyszek's amendment to this change
15:12:11 <bowlofeggs> but, i would like to hear what otaylor thinks too
15:12:44 * nirik wonders if we are getting too much into telling developers what to do. But dnf is a very important package for fedora.
15:12:47 <mhroncok> I would also like to see some answers to our questions provided by the change owner
15:13:06 <mhroncok> until that, we can but speculate and have ideas...
15:13:28 <jforbes> So punt until we get that clarification?
15:13:33 <bowlofeggs> yeah jmarek hasn't responded in a long time
15:14:18 <mhroncok> sometimes I get a feeling, that we are approached by teams in an urgent matter, we say "but what about X" and later there is no response. I guess that means it was not urgent after all, or it no longer is
15:14:22 <bowlofeggs> proposal: ask for a response from jmracek and punt till next week
15:14:39 <bowlofeggs> mhroncok: yeah i had a similar thought
15:14:42 <mhroncok> bowlofeggs: +1
15:14:54 <jforbes> bowlofeggs: +1
15:15:06 <zbyszek> mhroncok: which questions (sorry, it's a long thread)?
15:15:30 <mhroncok> not sure if there is one specific question to answer
15:15:52 <mhroncok> more like "get a consensus between dnf team and fesco"
15:16:02 <mhroncok> clearly, there were proposals, concerns, no reply
15:16:15 <bcotton> it would probably help jmarek et al if there was an updated list of unanswered questions
15:16:17 <bowlofeggs> there have been a lot of comments from people with no reply from the change owner
15:16:33 <zbyszek> OK.
15:16:46 <nirik> bowlofeggs: +1
15:17:04 <mhroncok> bcotton: that would probably help, but I don't consider it a must
15:17:05 <zbyszek> bowlofeggs: +1, I guess
15:17:36 <bowlofeggs> bookwar: ?
15:18:39 <bookwar> +1
15:19:05 <bowlofeggs> #agree ask for a response from jmracek and punt till next week (+6, 0, -0)
15:19:14 <bowlofeggs> #topic #2096 F31 System-Wide Change: BuildRequires generators
15:19:16 <bowlofeggs> .fesco 2096
15:19:20 <zodbot> bowlofeggs: Issue #2096: F31 System-Wide Change: BuildRequires generators - fesco - Pagure.io - https://pagure.io/fesco/issue/2096
15:19:32 <zbyszek> we're at +4 in the ticket
15:19:47 <bowlofeggs> i'll +1 as well
15:20:05 <nirik> I guess I am +1.
15:20:22 <bowlofeggs> ignatenkobrain: we're on your topic ☺
15:21:06 <ignatenkobrain> .hrllo2
15:21:09 <ignatenkobrain> .hello2
15:21:10 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:21:49 <bowlofeggs> i think that makes us +6
15:21:53 <bowlofeggs> bookwar: ?
15:22:07 <bookwar> i am +1 for a change in general, but i'd wish it be a bit friendlier, meaning add certain nice to haves (docs, info pagaes, etc) into the scope, not just bare minimum
15:22:34 <bowlofeggs> cool
15:22:44 <bowlofeggs> #agree APPROVED (+7, 0, -0)
15:23:01 <bowlofeggs> alright, is everyone ready for some easy topics?
15:23:07 <bowlofeggs> #topic #2114 What is the scope of Modularity?
15:23:09 <bowlofeggs> .fesco 2114
15:23:11 <zodbot> bowlofeggs: Issue #2114: What is the scope of Modularity? - fesco - Pagure.io - https://pagure.io/fesco/issue/2114
15:23:22 <bookwar> how is that easy? )
15:23:34 <mhroncok> bookwar: that's the point
15:23:49 <bowlofeggs> ignatenkobrain: i wouldn't mind some feedback form you if you want to stick around for this topic too ☺ - you seem to know a lot about modularity
15:25:09 <mhroncok> I tend to agree with sgallagh's "if rules are set today, without the modular-buildroot changes, then I think the answer can be drawn pretty simply: Until we revise this policy, do not move a package from the non-modular set to a default module stream if you (or the appropriate SIG) are not the owners of every package known to depend on it and are moving them all to one or more module streams at the same time."
15:25:19 <bowlofeggs> ignatenkobrain: do you agree with eclipseo's response to me as well? https://pagure.io/fesco/issue/2114#comment-565336
15:25:34 <ignatenkobrain> bowlofeggs: let me check
15:25:53 <nirik> yeah, except you also cant know the future there. ;( ie, someone may come along with a new package that depends on that set?
15:26:41 <sgallagh> nirik: I think we can only reasonably be expected to work from present knowledge
15:26:44 <ignatenkobrain> bowlofeggs: generally yes. Java is to some extent very similar
15:26:46 <bowlofeggs> nirik: for new packages it seems more reasonable to say "well you have to make it a module" than for existing packaes, imo
15:27:01 <ignatenkobrain> That's why he has moved to modules
15:27:02 <nirik> I suppose, but thats a possibly big hurdle for a new person...
15:27:24 <bowlofeggs> ignatenkobrain: cool, so i guess it's more about the rapid rate of change that is common among some languages, and less common among others
15:28:08 <ignatenkobrain> bowlofeggs: well, when you want multiple versions, you would rather move completely to modules
15:28:22 <bowlofeggs> yeah
15:28:29 <ignatenkobrain> Instead of mainting standard branches and modules
15:28:38 <mhroncok> I am all for moving "additional" versions to module
15:28:52 <bowlofeggs> yeah i think i can understand why you might not want to maintain both kinds of packages
15:28:52 <mhroncok> as long as we keep the "integrated" version in Fedora
15:29:30 <sgallagh> mhroncok: To reiterate, we don't *need* the "integrated" version, once the buildroot situation is resolved.
15:29:31 <bookwar> mhroncok: i think it oversimplifies things, and setting such a simple formal rule will be a problem, because people start to follow it and then we will realize that we haven't covered complex cases
15:29:31 <ignatenkobrain> mhroncok: we just need modules in buildroot which sgallagh is working on IIRC
15:29:37 <mhroncok> and when i say in Fedora, I mean it - this is how this thing is perceived by our packagers
15:29:51 <sgallagh> The problem here is that we did not give good guidance about not making this change before that happens
15:30:08 <bookwar> this kind of make it look like it is an easy question with an easy answer, so you go forward without thinkind
15:30:21 <ignatenkobrain> I'm sorry folks, I need to continue my bike ride.
15:30:40 <mhroncok> ignatenkobrain: don't IRC and drive
15:30:44 <sgallagh> FWIW, I currently do exactly what mhroncok is proposing for Node.js
15:31:00 <sgallagh> I have the non-modular version and alternatives as modules.
15:31:19 <jforbes> That seems like the most sane implementation TBH
15:31:23 <mhroncok> there are two tiny little problems with modules in buildroot
15:31:24 <sgallagh> It's extra work on my part as the packager, but it's the right experience for the user while the buildroot doesn't work right
15:31:45 <sgallagh> As soon as that becomes available, I intend to drop the non-modular builds entirely
15:31:48 <bowlofeggs> thanks ignatenkobrain!
15:31:52 <sgallagh> mhroncok: Go on
15:31:53 <mhroncok> sgallagh: totally agree - and this is what I always had in mind when we talked about modularity past f28
15:32:14 <mhroncok> well, tiny problem 1: it is not ready and there is no real estimate other than maybe in a year
15:33:08 <mhroncok> tiny problem 2: it's not just about availability in the buildroot, but also about ease of understanding (and contributing)
15:33:11 * nirik is pretty sure it will be sooner than that
15:33:34 <sgallagh> mhroncok: I can't get the Koji people to give me an estimate, but I've finally gotten through to them that it's urgent.
15:33:35 <jforbes> I would like to see your definition of a big problem if problem 1 is tiny.
15:33:48 <sgallagh> "Within a year" is definitely exaggerated
15:33:52 <mhroncok> aka Alice, the Friday packager, is confused by all those packages being created in alien way
15:34:14 <mhroncok> where is this coming from, why can't I just see the spec file "here" as I'm used to?
15:34:27 <zbyszek> mhroncok: re the rule stated by sgallagh that you quoted: it looks OK to me. Do you want to propose it for acceptance?
15:34:48 <mhroncok> I might be stupid, byt see my Python 3.8 modular e-mail on devel from today: this is overcomplicated for me. it must be horrible for others
15:35:29 <zbyszek> I think the Alice Friday problem is something that'll just have to live with for now. Some people want Modularity a lot, and unless we completely forbid it in Fedora, we must have it.
15:35:34 <mhroncok> zbyszek: bookwar seemed not to agree with that, I'd like to hear more
15:35:58 <mhroncok> zbyszek: I'm OK for modularity that they don't need to care about
15:36:29 <sgallagh> Alice Friday?
15:36:43 <mhroncok> was "user who don't want to care about modularity, don't need to care about it" one of the ideas about modularity 2.0?
15:37:01 <mhroncok> sgallagh: the Friday packager who doesn't do it as dayjob
15:37:03 <sgallagh> mhroncok: End-users, yes.
15:37:04 <zbyszek> sgallagh: "mhroncok> aka Alice, the Friday packager, is confused by a..."
15:37:14 <mhroncok> sgallagh: end users
15:37:29 <mhroncok> and I just fail to udnerstand why our packagers are not treated the same
15:38:10 <zbyszek> mhroncok: well, I think that ship has long sailed. Everybody needs to care about Modularity because it breaks many things.
15:38:26 <mhroncok> zbyszek: that is the wrong way to think about this
15:38:34 <sgallagh> "I want to have our software do all sorts of new things, but I don't want anyone to have to do any work to enable those new things" sounds like a mutually-exclusive requirement to me.
15:38:38 <nirik> if we made/make modularity transparent to non modular packages, I don't know that that would make them worth doing even would it?
15:38:39 <mhroncok> because it breaks many things, we need to protect the innocent and fix those things
15:38:47 <bookwar> mhroncok: i agree with this to be a necessary requirement, but it is not enough. If you are not a leaf - you can not be moved to a module - OK. But if you own a leaf, it still doesn't mean you can/should move to a module. There are more requirements then this one
15:39:18 <mhroncok> bookwar: sure
15:39:25 <jforbes> I don't think it  needs to be transparent to end users, but it should be simple to use.  Both as an end user and as a packager
15:39:41 <zbyszek> mhroncok: I'm not happy with status quo, quote the opposite. I'm just saying that things are as they are, so this requirement, even if initially stated, is impossible to satisfy.
15:39:55 <zbyszek> nirik: I completely disagree
15:40:09 <mhroncok> zbyszek: it is impossible to go back and undo things
15:40:20 <mhroncok> zbyszek: however it is possible to put an end to this
15:40:25 <jforbes> And it should absolutely not leave people without security updates
15:40:41 <nirik> jforbes: it's already pretty transparent to end users, it's maintainers we are talking about here. :)
15:40:58 <zbyszek> nirik: consider the change that we approved earlier today. It's very likely that soon all of ignatenkobrain's packages will use autogenerated BRs, and I sincerely hope this will not be noticable to users of those packages or even other packagers which depend on them.
15:41:07 <bowlofeggs> yeah i think the maintainers are the primary audience i am concerned about
15:41:18 <bowlofeggs> especially the volunteer maintainers
15:41:18 <nirik> zbyszek: I am talking about packagers/maintainers. not end users.
15:42:00 <jforbes> nirik: sorry meant end users and packagers.  It might actually be a bit too transparent to end users, who don't know how to leverage them at all
15:42:43 <bookwar> nirik: in my comment to the issue i tried to explain that the transparency doesn't solve it. We make modular packages mimic non-modular packages on the surface, but by that we hide the necessary information, that these are actually different kinds of packages
15:42:51 <bookwar> which user should treat differently
15:42:59 <nirik> so, where are we? thinking of rules we want to add to modularity? I think we may be going into the weeds here...
15:43:08 <bowlofeggs> would it be useful to think about this ticket in two stages: 0) what do/can we do immediately to stop the emergency at hand, 1) what do we do long term?
15:43:24 <jforbes> bowlofeggs: I think very much so
15:43:29 <zbyszek> bowlofeggs: very much so
15:43:54 <bowlofeggs> ok, so why don't we focus on just solving the current emergency first
15:44:12 <mhroncok> bowlofeggs: totally. but how? :D
15:44:13 <bookwar> nirik: see the non-api modular packages in default stream - they _look_like_ these are proper packages, but they are not. And this is not the proper transparency
15:44:44 <bowlofeggs> would it work if we just said "no non-leaf packages can move to modules without continuing to ship an ursine version" until we have a better solution in place for buildroot?
15:44:58 <bookwar> don't move package to modules at all, _add_ modules instead?
15:45:13 <bowlofeggs> imo, it's ok to move if they don't have deps
15:45:25 <bowlofeggs> i mean, if others dont' depend on them
15:45:38 <bowlofeggs> and it's ok to *add* modules too
15:45:50 <bowlofeggs> basically, i'm thinking about what sgallagh said he did with his node packages
15:46:02 <jforbes> bowlofeggs: right, not just have deps, are deps. And what about 3rd party repo deps?  We don't want to hurt the ecosystem as a whole
15:46:22 <mhroncok> what sgallagh did with nodejs is what we aim for
15:46:24 <bowlofeggs> yeah i meant "are deps" just bad wording on my part ☺
15:46:35 * nirik wonders how we can enforce that.
15:46:46 <bowlofeggs> jforbes: good point re third party - we can't know about those really
15:46:49 <mhroncok> but technically, all that happened with java packages it that the maintainer orphaned them. we cannot possibly forbid orphanning
15:47:00 * nirik agrees with mhroncok
15:47:26 <bowlofeggs> nirik: yeah i agree to an extent, but we also have other policies that we have similar limitation on enforcement
15:47:29 <nirik> we can urge or ask not to do it... but I'm not sure how we can enforce it
15:47:55 <mhroncok> if I want to create a module and add some packages to it and have it with defaults stream, what do I technically need to do today?
15:47:58 <bowlofeggs> i think almost all our policies have that problem
15:48:01 <mhroncok> is there a module review request?
15:48:12 <mhroncok> is there a gatekeeper?
15:48:15 <sgallagh> Right, as I said earlier, I'd be fine with a stated policy of "do not drop your non-modular packages until the buildroot fix is available"
15:48:25 <bowlofeggs> mhroncok: i think you can make a modular without review
15:48:30 <bowlofeggs> or at least, i was able to with rpick
15:48:32 <sgallagh> mhroncok: No, modules no longer require review.
15:48:45 <sgallagh> Because there's no content in them that wasn't already reviewed by package review
15:48:50 <nirik> yes
15:48:51 <jforbes> sgallagh: Yes, and we can even make it clear that the fix is "coming soon"
15:48:52 <bowlofeggs> yeah i think it's ok that we are "weak" on enforcement
15:49:00 <mhroncok> except the fact that they are new modules
15:49:04 <nirik> ha, we dropped that? nice. ;(
15:49:17 <sgallagh> mhroncok: There's a review process for making a default module stream, though.
15:49:24 <nirik> https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/ still mentions it.
15:49:31 <sgallagh> nirik: File a bug please
15:49:43 <mhroncok> sgallagh: and who reviews that? sorry for not knowing those things
15:49:44 <nirik> sure
15:49:49 <sgallagh> Wait, no it doesn't
15:49:57 <sgallagh> nirik: It just tells you that the packages need review
15:50:11 <sgallagh> Not the module
15:50:22 <sgallagh> mhroncok: mboddu and myself at the moment.
15:50:26 <bookwar> sgallagh: "do not drop your non-modular packages until further notice" the possibility to have modules in a buildroot doesn't solve it completely, we still need a part b) - the proper policy on fedault, builrott and so on modules
15:50:30 <bowlofeggs> there's a --exception flag (or something similar) on fedpkg request-repo that you can use to skip review
15:50:43 <sgallagh> I think the Java stuff slipped in before we had that process though
15:51:00 <bookwar> default* and buildroot* (sorry, my typing is weird)
15:51:07 <bowlofeggs> bookwar: true, but for now let's see if we can come up with a short term policy
15:51:43 <bowlofeggs> is anyone opposed to just saying "no further packages can migrate from ursine to modular only" as a short term measure?
15:52:05 <sgallagh> I'm fine with that.
15:52:10 <zbyszek> I'm fine with that.
15:52:10 <bowlofeggs> note: i left the leaf part out due to jforbes' concern about 3rd party repos
15:52:35 <mhroncok> proposal: default module streams packages can only be introduced if they are "new" or if there is a coordinated effort to move a group of packages from nonmodular fedora to a module (all dependent package owners must be on board with this). sgallagh and mboddu to review that this really happens when new modules and/or new default streams are created
15:53:12 <bowlofeggs> mhroncok: should we worry about the 3rd party repo concern that jforbes raised though?
15:53:36 <mhroncok> I trust sgallagh to sue common sense when reviewing this
15:53:39 <mhroncok> *use
15:53:58 <mhroncok> this doesn't say that anything that is leaf is automatically approved
15:53:59 <sgallagh> Looking at the history, I think I am at least partly to blame for the situation.
15:54:30 * mboddu is in a meeting, will take a look later
15:54:31 <sgallagh> I approved the ant and maven default streams without realizing at the time what problems would arise.
15:54:38 <nirik> I think especially since it's only a delay until we figure out the buildroot issue, we should try and get people to not drop normal packages at all when making modules.
15:54:43 <sgallagh> I am more aware of this now, certainly
15:55:03 <jforbes> agreed nirik
15:55:56 <bowlofeggs> counter proposal: "no further packages can migrate from ursine to modular only"
15:56:00 <mhroncok> as said we cannot prevent people from orphaning
15:56:14 <bookwar> i think we should use the default module approval process as a leverage for this, as miro suggested
15:56:23 <mhroncok> but we can prevent them to have the modular default thing to use as their internal rationale to oprhan
15:56:39 <mhroncok> I mean, somebody can still say: ...
15:56:57 <mhroncok> if you donẗ let me have my default module of glibc, I'm going to orphan all my packages and switch to ubuntu... but
15:57:04 <bowlofeggs> mhroncok: i don't think it's bad that we have weak enforcement powers - we are elected representatives to lead the community, and i think most packagers will respect that and follow our guidance. if people don't respect it, well, that will happen sometimes
15:57:11 <bowlofeggs> but most people i think will follow our leadership
15:57:37 <bookwar> we can not forbid orphaning, but it will be the orphaning, for real, not a "move to modules", and people who do this need to understand that
15:57:44 <nirik> bowlofeggs: ...for now?
15:58:19 <bowlofeggs> nirik: sure we can add for now - we are currently just trying ot find an immediate solution, and then we can try to think about how we want it to be in the future
15:58:37 <bowlofeggs> obvs, all fesco policies can be changed at any time with a vote ☺
15:58:38 <zbyszek> I think I like mhroncok proposal a bit more than bowlofeggs. There *are* leaf package sets which we can reasonably allow to move to be modular only without much loss for anyone else.
15:58:40 <nirik> I just wanted it to note that this is only right now, and may be changed.
15:58:51 <bowlofeggs> nirik: sure
15:58:59 <bowlofeggs> i don't oppose mhroncok's proposal
15:59:15 <zbyszek> But either proposal is better than status quo.
15:59:16 <bowlofeggs> jforbes: what do you think, given your concerns about 3rd party repos?
15:59:22 <nirik> zbyszek: well, two cases: 3rd party somewhere... and new packager... "hey, I want to join the community and package foo" "oh, that has to be a module now"
15:59:25 <mhroncok> (somebody with better understanding of proper terms should probably rephrase my proposal if we want to vote on it)
15:59:29 <sgallagh> Strawman proposal: FESCo forbids the addition of new default stream settings until further notice while we work out the buildroot problems.
15:59:45 <sgallagh> Just ban them all. Avoid setting rules on which are "okay" for now.
15:59:59 <jforbes> as long as the reviewers keep the major 3rd party in mind when reviewing, I am okay with that.
16:00:10 <mhroncok> sgallagh: while this "works" it just moves this problem further
16:00:12 <bowlofeggs> sgallagh: that seems effective to me
16:00:20 <zbyszek> sgallagh: is this different than bowlofeggs's proposal?
16:00:22 <nirik> well, that's another thing, no? not saying anything about moving non modular packages...
16:00:44 <sgallagh> zbyszek: Yes, it also removes adding new module-only content.
16:01:06 <bowlofeggs> i like that it's simple to state
16:01:08 <sgallagh> I'm just suggesting we make a blanket ban to avoid making the problem worse while we fix things
16:01:14 <bookwar> nirik: "moving" is replacing package with default modular stream, so it is the same mostly
16:01:32 <nirik> ah, I see what you are saying. Sure +1, and we can enforce this. :)
16:01:36 <bowlofeggs> and it is also easily enforceable since default stream requires action from releng
16:01:50 <mhroncok> I guess sgallagh's proposal works for me as long as we have a course of action
16:01:52 <jforbes> sgallagh: +1
16:02:05 <bookwar> sgallagh: i actually like that, but we need to come up with understanding and ETA when we plan to resolve this
16:02:09 <bowlofeggs> sgallagh: +1
16:02:32 <mhroncok> I also see that this mind bring frusration to modular friendly people - such as the rust packagers
16:03:10 <sgallagh> mhroncok: I can amend it to say "without FESCo approval" if you want.
16:03:11 <mhroncok> but TBH I'd rather see frustration in modular people, as those are experts and can deal with it, than in "regular" packagers
16:03:17 <sgallagh> That'll give them a workaround
16:03:30 <mhroncok> sgallagh: +1 with "without FESCo approval"
16:03:33 <bookwar> mhroncok: there is a still a possibility to ask FESCo directly for exception, which they use quite easily, so i wouldn't worry that much
16:03:44 <zbyszek> sgallagh: +1 with "wihtout FESCo approval"
16:03:59 <bowlofeggs> i'm also +1 to the fesco approval amendment
16:04:04 <nirik> sure, +1
16:04:05 <bookwar> +1
16:04:10 <jforbes> +1
16:04:18 * bowlofeggs tries to parse the count with his soft, human brain
16:04:37 <mhroncok> sgallagh: also, what is the next course of action? get modules to buildroot? and what happens after? we lift the ban entirely, or create rules?
16:04:37 <sgallagh> Restated for the agreement: "FESCo forbids the addition of new default stream settings until further notice while we work out the buildroot problems. Exceptions may be granted by FESCo vote."
16:04:51 <sgallagh> mhroncok: We need to create rules before we lift the ban.
16:04:53 <bowlofeggs> i think i count +7 to the amended proposal
16:04:58 <bookwar> mhroncok: create rules
16:05:04 <mhroncok> good
16:05:08 <zbyszek> ack
16:05:15 <bookwar> so we shouldn't close the ticket yet
16:05:21 <bowlofeggs> i'll mark that as an agreement for the short term, and then we can talk about longer term ☺
16:05:22 <mhroncok> bowlofeggs: this was easy, after all :D
16:06:04 <bowlofeggs> #agree FESCo forbids the addition of new default stream settings without FESCo approval until further notice while we work out the buildroot problems. (+7, 0, -0)
16:06:08 <zbyszek> Dunno, I think it's better to close the ticket for now. When the situation changes, let's restart discussion with a clean slate.
16:06:12 <sgallagh> mhroncok: Would you be willing to file a bug on the modularity Taiga describing the use cases we need to keep in mind when writing those rules?
16:06:19 <bookwar> i;d start work on a policy assuming buildroot modules are there
16:06:22 <bowlofeggs> should we continue on this today, or do we want to move on and talk more in ticket or a future meeting?
16:06:24 <bookwar> there is no need to wait for it
16:06:28 <sgallagh> I'll then ask my team to put together a proposal for them and present them to FESCo
16:06:42 <sgallagh> bookwar: Exactly what I was just asking.
16:06:44 <bowlofeggs> oh ok, yeah we could close this ticket too
16:06:48 <mhroncok> I see one problem
16:06:58 <sgallagh> I would like FESCo to provide the use cases/requirements though
16:07:04 <mhroncok> can packagers add more packages to existing default module streams?
16:07:51 <zbyszek> mhroncok: I think so. Let's trust our pakcagers not to abuse this.
16:08:01 <sgallagh> zbyszek: I was just typing the same answer
16:08:05 <mhroncok> #action mhroncok to file a bug on the modularity Taiga describing the use cases we need to keep in mind when writing those (modularity default streams) rules
16:08:06 <bowlofeggs> yeah i'm +1 to trust
16:08:18 <sgallagh> thank you
16:08:26 <bowlofeggs> i think FESCo largely relies on trust anyway ☺
16:08:47 <jforbes> You haven't been visited by "The Enforcer" yet then?
16:08:51 <sgallagh> bowlofeggs: Only because I secretly implanted you each with private keys.
16:08:51 <bowlofeggs> hahaha
16:08:58 <bowlofeggs> lol
16:09:21 <bowlofeggs> cool, well do we want to close this ticket as resolved, and have future tickets opened when we are ready to alter this new policy?
16:09:33 * zbyszek is
16:09:38 <jforbes> I would prefer that
16:09:39 <bowlofeggs> i.e., shall we move to next topic?
16:09:46 <bowlofeggs> cool
16:09:51 <nirik> +1
16:10:07 <bowlofeggs> you have 15 s to object!
16:10:17 <sgallagh> Agreed
16:10:24 <bowlofeggs> #topic #2115 Missing PkgDB features should be implemented
16:10:25 <bowlofeggs> .fesco 2115
16:10:27 <zodbot> bowlofeggs: Issue #2115: Missing PkgDB features should be implemented - fesco - Pagure.io - https://pagure.io/fesco/issue/2115
16:11:25 <mhroncok> I don't know how to handle this
16:11:41 * nirik still thinks this is not a worthwhile endevor, but +1 to just appove it and move on. ;)
16:11:41 <mhroncok> I still think that doing a statement can be worth it
16:11:49 <bowlofeggs> so this is just a statement from fesco to the council
16:11:54 <jforbes> nirik: +1
16:12:05 <mhroncok> we could then approach the council or FPL or whatever and say: please urge RH to fund this
16:12:24 <jforbes> hold a bake sale and fund someone to do this?
16:12:29 <bowlofeggs> haha
16:12:29 <mhroncok> nirik: thank you
16:12:34 <zbyszek> mhroncok: I see it the same way, so I'm still +1 to the proposal
16:12:38 * nirik notes some things are on the way to being done
16:12:50 <sgallagh> Sorry folks, I'm going to drop and try to get some rest before Go/No-Go. Feeling like crap at the moment.
16:12:55 <mhroncok> nirik: anything you can elaborate on?
16:12:59 <nirik> there's a proof of concept at least for a pagure plugin to handle monitoring
16:13:07 <mhroncok> sgallagh: get better and thanks
16:13:12 <bowlofeggs> i think i see +4 in ticket
16:13:16 <nirik> and possibly bugzilla overrides
16:13:27 <bowlofeggs> feel better sgallagh!
16:13:39 <nirik> sorry to hear it sgallagh.
16:13:56 <jforbes> feel better sgallagh
16:14:17 <bookwar> jforbes: actually we have Outreacy and GSoC for exactly this
16:14:20 <bowlofeggs> i think i count a total of +6?
16:14:25 <bowlofeggs> including ticket and irc
16:14:56 <bowlofeggs> #agree APPROVED (+6, 0, -0)
16:15:08 <jforbes> bookwar: this might actually be good projects for those, as there is a definite scope
16:15:10 <bowlofeggs> mhroncok: would you like to file a council ticket for this?
16:15:36 <mhroncok> bowlofeggs: sure. however is there a specific action we ask form council?
16:15:53 <mhroncok> is it "talk to RH about funding" or somehting else?
16:16:10 <mhroncok> or is it "please figure out how to make this happen"?
16:16:23 <bowlofeggs> mhroncok: i think the ticket probably speaks for itself - we are stating that we see this as a big problem and we'd like the council to solve it
16:16:28 <jforbes> I think the latter, and bookwar might be on to something there
16:16:41 <bowlofeggs> yeah bookwar's idea is solid
16:16:50 <bookwar> jforbes: unfortunately my attempt to mentor Outreachy project showed that it consumes much more time than I was able to spend, but if someone is interested, i can help as co-mentor, participating at least partially
16:16:52 <bowlofeggs> #action mhroncok will file a council ticket
16:17:12 <bowlofeggs> ok, anything else on this before we move on?
16:17:21 <nirik> might be... but it will need some up front planning I think
16:17:49 <bowlofeggs> #topic Next week's chair
16:18:03 <jforbes> nirik: yeah, outreachy and GSoC both need a lot of up front planning, and actual mentoring.
16:18:10 <bowlofeggs> who's the lucky fesco member‽
16:18:31 <jforbes> I can do it
16:18:35 * mhroncok can do the one after that
16:18:45 <bowlofeggs> #action jforbes will chair next week's meeting
16:18:47 <nirik> yep. "replace filing tickets for branches and new packages" isn't a good project for that... unless it has a design for what to actually make. ;)
16:18:47 <zbyszek> It's a holiday here. I hope to attend the meeting, but can't be 100% yet.
16:19:00 <bowlofeggs> #action mhroncok will chair in two weeks if we remember this #action line
16:19:12 <bowlofeggs> #topic Open Floor
16:19:26 <zbyszek> #action somebody to remember what bowlofeggs #actioned
16:19:31 <bowlofeggs> hahaha
16:19:34 <bcotton> zbyszek++
16:19:38 * mhroncok now plots a scheme for you to forgot that action line
16:19:46 <bowlofeggs> hahaha
16:19:54 <nirik> Many kudos to everyone who has worked on Fedora 30... it's really close to the finish line. :)
16:20:16 <bowlofeggs> yeah and it's a multiple of 10 which i like as a human
16:20:21 <bcotton> nirik: don't jinx it
16:20:31 <zbyszek> Do we have a list of packages which still need rebuilding to make upgrades to F30 smoother?
16:20:37 <bowlofeggs> and the next two version numbers are both fun: a prime number and a power of 2!
16:20:38 <mhroncok> clearly, the readiness meeting showed yesterday that we are not ready D:
16:20:39 <mhroncok> :D
16:21:11 <nirik> zbyszek: not sure. was a tracker ever setup for those?
16:21:29 <zbyszek> We have https://bugzilla.redhat.com/show_bug.cgi?id=F30FTBFS, but that's hundreds of packages...
16:21:49 <mhroncok> that reminds me...
16:21:50 <zbyszek> Many are still installable, so don't create an immediate problem for users.
16:21:56 <nirik> yeah, I think mostly people were just fixing them as they appeared on lists, etc
16:22:07 <nirik> was there a test day on it?
16:22:16 <mhroncok> .fesco 1973
16:22:18 <zodbot> mhroncok: Issue #1973: The FTBFS cleanup policy is not happening - fesco - Pagure.io - https://pagure.io/fesco/issue/1973
16:22:39 <zbyszek> nirik: it's today
16:22:42 <nirik> http://testdays.fedorainfracloud.org/events/64
16:23:02 <nirik> yeah
16:23:25 <nirik> oh yeah, I was going to setup a cron here. oops.
16:23:39 <nirik> I can look at doing that and getting a freeze break, or after f30...
16:23:41 <mhroncok> nirik: should I poke you on IRC?
16:24:04 <nirik> mhroncok: or open an infra ticket to track the cron work
16:24:22 <nirik> thats better because then also other people could work on it too. ;)
16:24:32 <nirik> would it help if I just ran it manually until after freeze?
16:24:36 <mhroncok> nirik: infra, not releng? I'm always confused with the two pagure repos
16:24:51 <mhroncok> nirik: it would
16:25:02 <mhroncok> nirik: at least we would see if it works :D
16:25:04 <nirik> yeah, it's sometimes confusing. I guess either place.
16:25:29 <nirik> (note: we are looking at perhaps folding the two together down the road here)
16:25:36 <nirik> sure, I can after the meeting.
16:25:42 <mhroncok> #action mhroncok to file a releng or infra ticket about cronjob for FTBFS weekly bugzilla reminders
16:26:06 <mhroncok> and he's gone
16:27:37 <bowlofeggs> anything else for open floor?
16:27:38 <nirik> sigh. stupid net
16:28:33 <mhroncok> bowlofeggs: set us free
16:28:35 <bowlofeggs> #endmeeting