15:00:00 #startmeeting FESCO (2019-04-29) 15:00:00 Meeting started Fri Apr 26 15:00:00 2019 UTC. 15:00:00 This meeting is logged and archived in a public location. 15:00:00 The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:00 The meeting name has been set to 'fesco_(2019-04-29)' 15:00:02 #meetingname fesco 15:00:02 The meeting name has been set to 'fesco' 15:00:04 #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:04 Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:06 #topic init process 15:00:15 hey hou 15:00:22 .hello2 15:00:23 jforbes: jforbes 'Justin M. Forbes' 15:00:38 I'm kind of here, but also quite sick and medicating this morning. 15:00:51 sgallagh: oh bummer - hope you feel better 15:01:03 .hello2 15:01:04 bcotton: bcotton 'Ben Cotton' 15:01:28 .hello2 15:01:29 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:29 .hello2 15:01:30 morning 15:01:32 bookwar: bookwar 'Aleksandra Fedorova' 15:02:02 .hello kevin 15:02:06 nirik: kevin 'Kevin Fenzi' 15:03:34 suhweeet suhweeet quorum 15:03:47 #topic #2088 F31 Change – “dnf --best” as default behavior 15:03:49 .fesco 2088 15:03:51 bowlofeggs: Issue #2088: F31 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088 15:04:13 After some consideration, I'm still strongly -1 on this. 15:04:50 This will be another case where we degrade user experience to solve an issue which is better handled through automatic checks. 15:05:17 I think that jmracek haven't answered all the questions. 15:05:35 * nirik tries to swap back in this thing 15:05:36 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 i worry a bit that a third party repo being broken could cause users to miss important updates from our repos 15:06:36 Or a broken modular package could do the same, see the mail mhroncok posted today. 15:06:38 Yeah, that is a problem 15:06:52 Or some obscure python2 package that nobody cares about would have the same effect. 15:07:07 "maybe dnf could default to --best only for security updates?" 15:07:14 that i think is a possible way to go 15:07:25 I'm not saying it's easy 15:07:30 that makes things even more complex tho... ;( 15:07:49 much more complex 15:07:50 Yeah, I'd amend that proposal: 15:08:29 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 BTW, there is likely no way this would be possible to do for f30 ga. ;) 15:09:12 This will keep things working for users, while solving the problem of missed updates being hard to notice. 15:09:12 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 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 I guess their thought is that failing is a better way to get users attention... 15:09:46 i think we should also consider otaylor's concerns about differing behavior between gnome software and dnf as well 15:10:03 nirik: the change is marked for F31 15:10:23 ah, I read the Note: at the top... 15:10:29 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 yeah it used to be for F30 15:10:52 during one of our previous meetings we voted that it couldn't go for F30 because it was too late 15:10:59 right, it is. 15:12:00 i think i could be ok with zbyszek's amendment to this change 15:12:11 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 I would also like to see some answers to our questions provided by the change owner 15:13:06 until that, we can but speculate and have ideas... 15:13:28 So punt until we get that clarification? 15:13:33 yeah jmarek hasn't responded in a long time 15:14:18 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 proposal: ask for a response from jmracek and punt till next week 15:14:39 mhroncok: yeah i had a similar thought 15:14:42 bowlofeggs: +1 15:14:54 bowlofeggs: +1 15:15:06 mhroncok: which questions (sorry, it's a long thread)? 15:15:30 not sure if there is one specific question to answer 15:15:52 more like "get a consensus between dnf team and fesco" 15:16:02 clearly, there were proposals, concerns, no reply 15:16:15 it would probably help jmarek et al if there was an updated list of unanswered questions 15:16:17 there have been a lot of comments from people with no reply from the change owner 15:16:33 OK. 15:16:46 bowlofeggs: +1 15:17:04 bcotton: that would probably help, but I don't consider it a must 15:17:05 bowlofeggs: +1, I guess 15:17:36 bookwar: ? 15:18:39 +1 15:19:05 #agree ask for a response from jmracek and punt till next week (+6, 0, -0) 15:19:14 #topic #2096 F31 System-Wide Change: BuildRequires generators 15:19:16 .fesco 2096 15:19:20 bowlofeggs: Issue #2096: F31 System-Wide Change: BuildRequires generators - fesco - Pagure.io - https://pagure.io/fesco/issue/2096 15:19:32 we're at +4 in the ticket 15:19:47 i'll +1 as well 15:20:05 I guess I am +1. 15:20:22 ignatenkobrain: we're on your topic ☺ 15:21:06 .hrllo2 15:21:09 .hello2 15:21:10 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:21:49 i think that makes us +6 15:21:53 bookwar: ? 15:22:07 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 cool 15:22:44 #agree APPROVED (+7, 0, -0) 15:23:01 alright, is everyone ready for some easy topics? 15:23:07 #topic #2114 What is the scope of Modularity? 15:23:09 .fesco 2114 15:23:11 bowlofeggs: Issue #2114: What is the scope of Modularity? - fesco - Pagure.io - https://pagure.io/fesco/issue/2114 15:23:22 how is that easy? ) 15:23:34 bookwar: that's the point 15:23:49 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 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 ignatenkobrain: do you agree with eclipseo's response to me as well? https://pagure.io/fesco/issue/2114#comment-565336 15:25:34 bowlofeggs: let me check 15:25:53 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 nirik: I think we can only reasonably be expected to work from present knowledge 15:26:44 bowlofeggs: generally yes. Java is to some extent very similar 15:26:46 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 That's why he has moved to modules 15:27:02 I suppose, but thats a possibly big hurdle for a new person... 15:27:24 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 bowlofeggs: well, when you want multiple versions, you would rather move completely to modules 15:28:22 yeah 15:28:29 Instead of mainting standard branches and modules 15:28:38 I am all for moving "additional" versions to module 15:28:52 yeah i think i can understand why you might not want to maintain both kinds of packages 15:28:52 as long as we keep the "integrated" version in Fedora 15:29:30 mhroncok: To reiterate, we don't *need* the "integrated" version, once the buildroot situation is resolved. 15:29:31 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 mhroncok: we just need modules in buildroot which sgallagh is working on IIRC 15:29:37 and when i say in Fedora, I mean it - this is how this thing is perceived by our packagers 15:29:51 The problem here is that we did not give good guidance about not making this change before that happens 15:30:08 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 I'm sorry folks, I need to continue my bike ride. 15:30:40 ignatenkobrain: don't IRC and drive 15:30:44 FWIW, I currently do exactly what mhroncok is proposing for Node.js 15:31:00 I have the non-modular version and alternatives as modules. 15:31:19 That seems like the most sane implementation TBH 15:31:23 there are two tiny little problems with modules in buildroot 15:31:24 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 As soon as that becomes available, I intend to drop the non-modular builds entirely 15:31:48 thanks ignatenkobrain! 15:31:52 mhroncok: Go on 15:31:53 sgallagh: totally agree - and this is what I always had in mind when we talked about modularity past f28 15:32:14 well, tiny problem 1: it is not ready and there is no real estimate other than maybe in a year 15:33:08 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 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 I would like to see your definition of a big problem if problem 1 is tiny. 15:33:48 "Within a year" is definitely exaggerated 15:33:52 aka Alice, the Friday packager, is confused by all those packages being created in alien way 15:34:14 where is this coming from, why can't I just see the spec file "here" as I'm used to? 15:34:27 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 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 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 zbyszek: bookwar seemed not to agree with that, I'd like to hear more 15:35:58 zbyszek: I'm OK for modularity that they don't need to care about 15:36:29 Alice Friday? 15:36:43 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 sgallagh: the Friday packager who doesn't do it as dayjob 15:37:03 mhroncok: End-users, yes. 15:37:04 sgallagh: "mhroncok> aka Alice, the Friday packager, is confused by a..." 15:37:14 sgallagh: end users 15:37:29 and I just fail to udnerstand why our packagers are not treated the same 15:38:10 mhroncok: well, I think that ship has long sailed. Everybody needs to care about Modularity because it breaks many things. 15:38:26 zbyszek: that is the wrong way to think about this 15:38:34 "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 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 because it breaks many things, we need to protect the innocent and fix those things 15:38:47 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 bookwar: sure 15:39:25 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 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 nirik: I completely disagree 15:40:09 zbyszek: it is impossible to go back and undo things 15:40:20 zbyszek: however it is possible to put an end to this 15:40:25 And it should absolutely not leave people without security updates 15:40:41 jforbes: it's already pretty transparent to end users, it's maintainers we are talking about here. :) 15:40:58 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 yeah i think the maintainers are the primary audience i am concerned about 15:41:18 especially the volunteer maintainers 15:41:18 zbyszek: I am talking about packagers/maintainers. not end users. 15:42:00 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 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 which user should treat differently 15:42:59 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 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 bowlofeggs: I think very much so 15:43:29 bowlofeggs: very much so 15:43:54 ok, so why don't we focus on just solving the current emergency first 15:44:12 bowlofeggs: totally. but how? :D 15:44:13 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 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 don't move package to modules at all, _add_ modules instead? 15:45:13 imo, it's ok to move if they don't have deps 15:45:25 i mean, if others dont' depend on them 15:45:38 and it's ok to *add* modules too 15:45:50 basically, i'm thinking about what sgallagh said he did with his node packages 15:46:02 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 what sgallagh did with nodejs is what we aim for 15:46:24 yeah i meant "are deps" just bad wording on my part ☺ 15:46:35 * nirik wonders how we can enforce that. 15:46:46 jforbes: good point re third party - we can't know about those really 15:46:49 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 nirik: yeah i agree to an extent, but we also have other policies that we have similar limitation on enforcement 15:47:29 we can urge or ask not to do it... but I'm not sure how we can enforce it 15:47:55 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 i think almost all our policies have that problem 15:48:01 is there a module review request? 15:48:12 is there a gatekeeper? 15:48:15 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 mhroncok: i think you can make a modular without review 15:48:30 or at least, i was able to with rpick 15:48:32 mhroncok: No, modules no longer require review. 15:48:45 Because there's no content in them that wasn't already reviewed by package review 15:48:50 yes 15:48:51 sgallagh: Yes, and we can even make it clear that the fix is "coming soon" 15:48:52 yeah i think it's ok that we are "weak" on enforcement 15:49:00 except the fact that they are new modules 15:49:04 ha, we dropped that? nice. ;( 15:49:17 mhroncok: There's a review process for making a default module stream, though. 15:49:24 https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/ still mentions it. 15:49:31 nirik: File a bug please 15:49:43 sgallagh: and who reviews that? sorry for not knowing those things 15:49:44 sure 15:49:49 Wait, no it doesn't 15:49:57 nirik: It just tells you that the packages need review 15:50:11 Not the module 15:50:22 mhroncok: mboddu and myself at the moment. 15:50:26 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 there's a --exception flag (or something similar) on fedpkg request-repo that you can use to skip review 15:50:43 I think the Java stuff slipped in before we had that process though 15:51:00 default* and buildroot* (sorry, my typing is weird) 15:51:07 bookwar: true, but for now let's see if we can come up with a short term policy 15:51:43 is anyone opposed to just saying "no further packages can migrate from ursine to modular only" as a short term measure? 15:52:05 I'm fine with that. 15:52:10 I'm fine with that. 15:52:10 note: i left the leaf part out due to jforbes' concern about 3rd party repos 15:52:35 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 mhroncok: should we worry about the 3rd party repo concern that jforbes raised though? 15:53:36 I trust sgallagh to sue common sense when reviewing this 15:53:39 *use 15:53:58 this doesn't say that anything that is leaf is automatically approved 15:53:59 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 I approved the ant and maven default streams without realizing at the time what problems would arise. 15:54:38 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 I am more aware of this now, certainly 15:55:03 agreed nirik 15:55:56 counter proposal: "no further packages can migrate from ursine to modular only" 15:56:00 as said we cannot prevent people from orphaning 15:56:14 i think we should use the default module approval process as a leverage for this, as miro suggested 15:56:23 but we can prevent them to have the modular default thing to use as their internal rationale to oprhan 15:56:39 I mean, somebody can still say: ... 15:56:57 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 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 but most people i think will follow our leadership 15:57:37 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 bowlofeggs: ...for now? 15:58:19 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 obvs, all fesco policies can be changed at any time with a vote ☺ 15:58:38 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 I just wanted it to note that this is only right now, and may be changed. 15:58:51 nirik: sure 15:58:59 i don't oppose mhroncok's proposal 15:59:15 But either proposal is better than status quo. 15:59:16 jforbes: what do you think, given your concerns about 3rd party repos? 15:59:22 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 (somebody with better understanding of proper terms should probably rephrase my proposal if we want to vote on it) 15:59:29 Strawman proposal: FESCo forbids the addition of new default stream settings until further notice while we work out the buildroot problems. 15:59:45 Just ban them all. Avoid setting rules on which are "okay" for now. 15:59:59 as long as the reviewers keep the major 3rd party in mind when reviewing, I am okay with that. 16:00:10 sgallagh: while this "works" it just moves this problem further 16:00:12 sgallagh: that seems effective to me 16:00:20 sgallagh: is this different than bowlofeggs's proposal? 16:00:22 well, that's another thing, no? not saying anything about moving non modular packages... 16:00:44 zbyszek: Yes, it also removes adding new module-only content. 16:01:06 i like that it's simple to state 16:01:08 I'm just suggesting we make a blanket ban to avoid making the problem worse while we fix things 16:01:14 nirik: "moving" is replacing package with default modular stream, so it is the same mostly 16:01:32 ah, I see what you are saying. Sure +1, and we can enforce this. :) 16:01:36 and it is also easily enforceable since default stream requires action from releng 16:01:50 I guess sgallagh's proposal works for me as long as we have a course of action 16:01:52 sgallagh: +1 16:02:05 sgallagh: i actually like that, but we need to come up with understanding and ETA when we plan to resolve this 16:02:09 sgallagh: +1 16:02:32 I also see that this mind bring frusration to modular friendly people - such as the rust packagers 16:03:10 mhroncok: I can amend it to say "without FESCo approval" if you want. 16:03:11 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 That'll give them a workaround 16:03:30 sgallagh: +1 with "without FESCo approval" 16:03:33 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 sgallagh: +1 with "wihtout FESCo approval" 16:03:59 i'm also +1 to the fesco approval amendment 16:04:04 sure, +1 16:04:05 +1 16:04:10 +1 16:04:18 * bowlofeggs tries to parse the count with his soft, human brain 16:04:37 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 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 mhroncok: We need to create rules before we lift the ban. 16:04:53 i think i count +7 to the amended proposal 16:04:58 mhroncok: create rules 16:05:04 good 16:05:08 ack 16:05:15 so we shouldn't close the ticket yet 16:05:21 i'll mark that as an agreement for the short term, and then we can talk about longer term ☺ 16:05:22 bowlofeggs: this was easy, after all :D 16:06:04 #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 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 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 i;d start work on a policy assuming buildroot modules are there 16:06:22 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 there is no need to wait for it 16:06:28 I'll then ask my team to put together a proposal for them and present them to FESCo 16:06:42 bookwar: Exactly what I was just asking. 16:06:44 oh ok, yeah we could close this ticket too 16:06:48 I see one problem 16:06:58 I would like FESCo to provide the use cases/requirements though 16:07:04 can packagers add more packages to existing default module streams? 16:07:51 mhroncok: I think so. Let's trust our pakcagers not to abuse this. 16:08:01 zbyszek: I was just typing the same answer 16:08:05 #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 yeah i'm +1 to trust 16:08:18 thank you 16:08:26 i think FESCo largely relies on trust anyway ☺ 16:08:47 You haven't been visited by "The Enforcer" yet then? 16:08:51 bowlofeggs: Only because I secretly implanted you each with private keys. 16:08:51 hahaha 16:08:58 lol 16:09:21 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 I would prefer that 16:09:39 i.e., shall we move to next topic? 16:09:46 cool 16:09:51 +1 16:10:07 you have 15 s to object! 16:10:17 Agreed 16:10:24 #topic #2115 Missing PkgDB features should be implemented 16:10:25 .fesco 2115 16:10:27 bowlofeggs: Issue #2115: Missing PkgDB features should be implemented - fesco - Pagure.io - https://pagure.io/fesco/issue/2115 16:11:25 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 I still think that doing a statement can be worth it 16:11:49 so this is just a statement from fesco to the council 16:11:54 nirik: +1 16:12:05 we could then approach the council or FPL or whatever and say: please urge RH to fund this 16:12:24 hold a bake sale and fund someone to do this? 16:12:29 haha 16:12:29 nirik: thank you 16:12:34 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 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 nirik: anything you can elaborate on? 16:12:59 there's a proof of concept at least for a pagure plugin to handle monitoring 16:13:07 sgallagh: get better and thanks 16:13:12 i think i see +4 in ticket 16:13:16 and possibly bugzilla overrides 16:13:27 feel better sgallagh! 16:13:39 sorry to hear it sgallagh. 16:13:56 feel better sgallagh 16:14:17 jforbes: actually we have Outreacy and GSoC for exactly this 16:14:20 i think i count a total of +6? 16:14:25 including ticket and irc 16:14:56 #agree APPROVED (+6, 0, -0) 16:15:08 bookwar: this might actually be good projects for those, as there is a definite scope 16:15:10 mhroncok: would you like to file a council ticket for this? 16:15:36 bowlofeggs: sure. however is there a specific action we ask form council? 16:15:53 is it "talk to RH about funding" or somehting else? 16:16:10 or is it "please figure out how to make this happen"? 16:16:23 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 I think the latter, and bookwar might be on to something there 16:16:41 yeah bookwar's idea is solid 16:16:50 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 #action mhroncok will file a council ticket 16:17:12 ok, anything else on this before we move on? 16:17:21 might be... but it will need some up front planning I think 16:17:49 #topic Next week's chair 16:18:03 nirik: yeah, outreachy and GSoC both need a lot of up front planning, and actual mentoring. 16:18:10 who's the lucky fesco member‽ 16:18:31 I can do it 16:18:35 * mhroncok can do the one after that 16:18:45 #action jforbes will chair next week's meeting 16:18:47 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 It's a holiday here. I hope to attend the meeting, but can't be 100% yet. 16:19:00 #action mhroncok will chair in two weeks if we remember this #action line 16:19:12 #topic Open Floor 16:19:26 #action somebody to remember what bowlofeggs #actioned 16:19:31 hahaha 16:19:34 zbyszek++ 16:19:38 * mhroncok now plots a scheme for you to forgot that action line 16:19:46 hahaha 16:19:54 Many kudos to everyone who has worked on Fedora 30... it's really close to the finish line. :) 16:20:16 yeah and it's a multiple of 10 which i like as a human 16:20:21 nirik: don't jinx it 16:20:31 Do we have a list of packages which still need rebuilding to make upgrades to F30 smoother? 16:20:37 and the next two version numbers are both fun: a prime number and a power of 2! 16:20:38 clearly, the readiness meeting showed yesterday that we are not ready D: 16:20:39 :D 16:21:11 zbyszek: not sure. was a tracker ever setup for those? 16:21:29 We have https://bugzilla.redhat.com/show_bug.cgi?id=F30FTBFS, but that's hundreds of packages... 16:21:49 that reminds me... 16:21:50 Many are still installable, so don't create an immediate problem for users. 16:21:56 yeah, I think mostly people were just fixing them as they appeared on lists, etc 16:22:07 was there a test day on it? 16:22:16 .fesco 1973 16:22:18 mhroncok: Issue #1973: The FTBFS cleanup policy is not happening - fesco - Pagure.io - https://pagure.io/fesco/issue/1973 16:22:39 nirik: it's today 16:22:42 http://testdays.fedorainfracloud.org/events/64 16:23:02 yeah 16:23:25 oh yeah, I was going to setup a cron here. oops. 16:23:39 I can look at doing that and getting a freeze break, or after f30... 16:23:41