15:00:17 #startmeeting FESCO (2019-12-09) 15:00:18 Meeting started Mon Dec 9 15:00:17 2019 UTC. 15:00:18 This meeting is logged and archived in a public location. 15:00:18 The chair is ignatenkobrain_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:18 The meeting name has been set to 'fesco_(2019-12-09)' 15:00:28 #meetingname fesco 15:00:28 The meeting name has been set to 'fesco' 15:00:28 #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrel 15:00:28 Current chairs: bookwar contyk dcantrel decathorpe ignatenkobrain ignatenkobrain_ mhroncok nirik sgallagh zbyszek 15:00:28 #topic init process 15:00:32 .hello2 15:00:33 sgallagh: sgallagh 'Stephen Gallagher' 15:00:37 .hello2 15:00:38 bookwar: bookwar 'Aleksandra Fedorova' 15:00:55 .hello psabata 15:00:56 contyk: psabata 'Petr Šabata' 15:01:06 .hello2 15:01:06 decathorpe: decathorpe 'Fabio Valentini' 15:01:15 .hello2 15:01:16 bcotton: bcotton 'Ben Cotton' 15:01:19 * contyk doesn't have a working browser today 15:01:40 .hello2 15:01:43 contyk, \o/ 15:01:43 dcantrell: Sorry, but you don't exist 15:01:53 contyk, now we can just lie to you about content of a tickets :D 15:01:55 morning 15:02:00 my FAS account is 'dcantrel' and I use 'dcantrell' on IRC 15:02:07 can anyone fix that? 15:02:09 dcantrell, .hello dcantrel :) 15:02:21 ignatenkobrain_: hi 15:02:24 dcantrell: You can set your IRC nick in FAS and it will map them 15:02:31 sgallagh: thanks 15:02:39 np 15:02:45 .ehllo2 15:02:47 .hello2 15:02:48 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:02:59 ignatenkobrain_: at least I can focus on you all :) 15:03:07 .hello dcantrel 15:03:08 sgallagh: dcantrel 'David Cantrell' 15:03:11 (For the record) 15:03:20 s/record/log/ 15:03:21 I think we are missing only Miro, but I think he said that he won't make it today 15:03:24 hello2 is for when your irc nick and fas name are the same. :) hello is the version for if they are different 15:03:26 sgallagh: apparently I already had my irc nick set in FAS 15:03:35 > I am not sure whether I can make it to the this meeting 15:03:37 odd 15:03:45 nirik: thanks 15:03:51 nirik: Oh, my mistake 15:04:03 so I guess we can start without Miro and hope he will join us later :) 15:04:13 #topic #2295 Update FESCo membership with elections results, possibly setup new meeting time 15:04:21 so first of all, welcome dcantrell and decathorpe :) 15:04:29 thank you! 15:04:32 * sgallagh waves 15:04:35 welcome! 15:04:38 thanks :) 15:04:39 and many thanks to outgoing members too! 15:04:40 I hope bcotton already gave you a badge :) 15:04:48 welcome to the party! 15:04:51 nirik, that's the second of all :) 15:04:52 I do have a badge 15:04:56 also more email 15:04:57 :) 15:05:01 yeah, all good 15:05:09 dcantrell, there is never too much email, right? 15:05:19 of course not 15:05:21 gmail eats it all 15:05:22 .fesco 2295 15:05:23 ignatenkobrain_: Issue #2295: Update FESCo membership with elections results, possibly setup new meeting time - fesco - Pagure.io - https://pagure.io/fesco/issue/2295 15:05:48 decathorpe, dcantrell, do you want to propose different time for this meeting or it is good enough? 15:06:00 this time is fine for me 15:06:10 * nirik isn't crazy about this time, but can deal with it 15:06:27 I am ok with a different time, but I can't do earlier 15:06:30 yeah, I'm not crazy about, but realistically we are unlikely to get time earlier in the day 15:06:36 let's wait for miro to get a schedule and try to vote again 15:06:37 we can do whenisgood again 15:06:54 sounds reasonable to me 15:06:55 although I kinda like this slot; doesn't conflict with anything and it isn't Friday night like before 15:07:12 contyk, =1 15:08:02 Proposal: keep this time for next ~2mo and then possibly run whenisgood 15:08:11 +1 15:08:22 +1 15:08:27 +1 15:08:27 +1 15:08:30 +1 15:08:49 +1 15:09:10 sure, I suppose, +1 15:09:18 #agree Keep this time for next ~2mo and then possibly run whenisgood (+8, 0, -0) 15:09:22 #topic #2285 Make Eclipse Installable 15:09:25 .fesco 2285 15:09:27 ignatenkobrain_: Issue #2285: Make Eclipse Installable - fesco - Pagure.io - https://pagure.io/fesco/issue/2285 15:09:30 Now to more complicated things : 15:09:37 * sgallagh sighs 15:09:52 * dcantrell takes another sip of coffee 15:09:59 * dcantrell and a couple more 15:10:07 our favorite 15:10:10 sgallagh, contyk do you have a solution which would revert modular RPMs to a "traditional" ones? 15:10:35 nope, not currently 15:10:55 is it being worked on? 15:11:12 Langdon posted instructions on fedora-devel on how to revert. I have not tested it myself. 15:11:14 ignatenkobrain_: We're trying to brainstorm a solution 15:11:20 in the mean time, perhaps adding it to common bugs and sending a announce post about it would be good? 15:11:29 it's part of a bigger proposal that would allow us to move packages out of modules as well as change module-level dependencies 15:11:32 dcantrell: Reversion is useful, but we need a forward path 15:11:36 dcantrell, well, dnf module disable && dnf distro-sync should do the trick. I did the same for Rust stuff 15:11:40 it's being discussed but it's slow 15:12:12 sgallagh: you mean forward as in revert but also let people still install the eclipse module? 15:12:25 sgallagh, IIRC you have removed eclipse defaults, right? what abount maven? 15:12:27 Yeah, the short answer is that it touches on a bunch of assumptions made by the original design and some that were invented by the DNF team that we didn't know about 15:12:47 dcantrell: As in "do the revert for them when doing a regular `dnf update`" 15:13:04 maybe I misunderstood the question; I thought you were asking about dropping a package from an active stream and switching to the non-modular variant again 15:13:05 Moving further along to fixing Eclipse installation 15:13:06 are we discussing recovery from enabling eclipse as default, or the plan forward for eclipse? 15:13:30 bookwar: Both, plus the general case of "drop an RPM from a module back to non-modular" 15:13:36 I thought the question was how do we restore the functional protobuf for users 15:13:49 as i understood recovery procedure is clear we just need to announce it 15:13:52 dcantrell: That's the specific symptom 15:14:20 I feel that a path forward discussion is more involved 15:14:34 no one has explained why eclipse bundled protobuf. that seems really weird to me 15:14:43 Let me provide a bit of background information that should clarify a few points. 15:15:00 dcantrell: It is a dependency of the javascript interpreter used by eclipse-webtools 15:15:41 mbooth: ok, why bundle though? it's provided by fedora. 15:15:47 First, the inclusion of protobuf in the module was in violation of our established policies for default streams. We missed this when reviewing it, to our detriment. 15:15:47 mbooth, then probably more general question. why did you put anything what is not eclipse-* into an eclipse module? 15:16:16 This is added to the problem that DNF considers all visible versions of the module for determining what package names to "hide" from the transaction. 15:16:40 This was an assumption that the DNF team made that took us by surprise. We only intended that the highest available version was considered for that purpose. 15:17:11 So we're trying to fix that, which will allow us to simply drop protobuf from the stream and fix users. 15:17:17 ignatenkobrain_: Because the non-modular java stack is slowly going away. I admit it was a mistake to include protobuf in hindsight (it is not a "Java ecosystem" package, rather a package that just happens to have a Java binding) 15:17:45 mbooth: I think the stewardship sig would disagree with this stmt 15:17:49 I don't know how actively DNF is working on this right this second. 15:18:00 sgallagh, do we have link to a bug FTR? 15:18:10 the reason DNF does it is to ensure all versions and/or any RPM from any version can be installed, letting users cherry-pick what they want 15:18:11 One moment 15:18:21 but obviously it's not practical 15:18:28 .bug 1770285 15:18:29 zbyszek: we do ;) 15:18:30 sgallagh: 1770285 – Cannot drop packages from module stream - https://bugzilla.redhat.com/1770285 15:18:52 I have a meeting with the DNF team tomorrow again, discussing this behavior :) 15:19:04 zbyszek: As is their right, it doesn't change that my dependencies have been going away. Including them in a self-contained module is necessary for deps that have already gone away, and protects Eclipse from future retirements 15:19:08 contyk, I feel that the right approach would be to add special flag "yanked" to a modular metadata and in that case, dnf should not hide packages from those 15:19:13 contyk: Can you extend that invite to me as well, please? 15:19:26 sgallagh: sure 15:19:31 Thank you 15:19:37 so if the path forward requires work in dnf, where does that leave modules now in fedora? based on what you've said, as a user I would prefer that default streams be off until dnf is updated 15:20:02 sgallagh: oh, it's actually Wednesday 15:20:18 sgallagh: current state is that default module for eclipse is off? 15:20:25 bookwar: Yes 15:20:35 for both f31 and f32 15:20:40 yes 15:20:43 IMHO, we can just not add any new ones... I think the existing ones should be ok. 15:21:06 Right, and the current policy is that all new default streams requires FESCo approval already. 15:21:10 nirik: assuming that maintainers of current default streams don't add unexpected iverrides 15:21:21 I think we need to drop maven default stream too 15:21:22 ok, that sounds reasonable. another thing was mentioned by sgallagh regarding module policy violations. how does that get caught in the future? 15:21:34 sgallagh: FWIW, I think your request in 1770285 is reasaonble. I don't see how current behaviour could be made to work. 15:21:36 dcantrell: Excellent question. 15:22:08 bookwar: personally, as a user, I am worried about this. last week's modular behavior via dnf has left me not trusting modules in stable fedora. 15:22:13 dcantrell: The hand-wavy answer is "automated testing" 15:22:22 sgallagh: good answer :) 15:22:23 1) mizdebsk wanted to update default stream to 3.6 (now it is 3.5) which would cause problems on upgrade 2) mbooth told that eclipse will need maven:3.6 3) stewardship-sig makes great job to keep maven on the latest version so I don't think we need to have it modular 15:23:06 so all the changes to defaults are submitted as PRs to fedora-modules-defaults 15:23:07 dcantrell: I don't have the cycles currently to implement it, but I'd like all modules to have a Bodhi gating test that disallows adding new packages without approval. 15:23:10 sgallagh: the more involved response that the community should be aware of is who is on that part as well as what the module policy actually is 15:23:13 ignatenkobrain_: i think it is a separate issue, we should have a discussion on it 15:23:35 I think whoever is approving those PRs should be required to ask for a FESCo ticket reference 15:23:40 sgallagh: I think we should identify the actual work that should happen and then figure out who can work on it 15:23:55 or it could be linking to the ticket and an automated test could validate it, yes 15:23:58 contyk: That would be me, and I do 15:24:14 sgallagh: in fact, in the interim, I think it's worth even having a checklist and two-person rule until it's automated 15:24:16 I think atomation is better than us. ;) 15:24:28 dcantrell: +1 15:24:33 nirik: agreed, automation is certainly how this scales 15:24:49 dcantrell: For initial addition of a default stream, we require a FESCo vote 15:25:02 Once that's in, right now the maintainer has full autonomy 15:25:22 a fesco vote is good, but I'd like to see a checklist based on some policies we both know and maybe we all agree we need now 15:25:35 I'd like us to put a gate in place so the set of components included in a stream cannot change without similar approval 15:25:58 sgallagh: +1 15:26:00 sgallagh: that sounds reasonable yeah 15:26:07 yep, sounds very reasonable. 15:26:24 um, while I understand your intention, I think that will add significant process burden to module maintanance 15:26:52 contyk, it is already burden, so I don't think it is a problem :) 15:26:53 sgallagh, +1 15:26:58 contyk: I'm not sure I understand your concern 15:27:18 contyk: I think ultimately we should automation that validates a module and the approval becomes more or less automated once that passes 15:27:39 I think the process needs to manual now to get the details sorted out about what automating that looks like 15:27:47 if I have a large modules with dozens or hundreds of components, list of which changes quite often, I'd have to go through a FESCo approval process every time I want to update it 15:27:54 contyk: I think that needs to be our first pass, and then we can refine it 15:28:03 and I agree it's a burden for module maintenance, but I would rather go for that than drop surprises on users that could lead to broken systems :/ 15:28:14 contyk: I think we can consider allowing special-cases as they arise. 15:28:36 maybe we should let module maintainers eventually earn "provenmoduler" 15:28:49 :/ 15:28:50 A second pass at the gating could be something like "Don't block if the new component is not in the non-modular set" 15:29:04 So you can add non-conflicting content easily. 15:29:12 proposal: 1) eclipse module doesn't get a default stream in f31, createing a Common Issues entry is recommended 2) adding default stream for eclipse module for f32 can be put on discussion via Fedora Change process 3) fesco will identify work items on the policy enforcement for default streams content 15:29:16 But if it would override, *Red Alert, Shields Up* 15:29:38 +1/+1/+1 15:29:42 bookwar: ^^ 15:29:45 bookwar: +1 15:29:51 bookwar: +1 15:29:51 bookwar: +1 15:29:58 bookwar, +1 15:30:18 +1 15:30:21 ... +1 15:30:44 Actually, one modification on 1): mbooth *may* come back and re-request it for F31 after F32's default has been vetted. 15:30:54 Acceptable? 15:31:11 sgallagh: I think that's always possible, we don't need to say that explicitly. 15:31:28 Well, the way it's phrased sounded like a definitive "not in F31" 15:31:32 So I wanted that to be clear 15:31:49 I'm fine with either 15:31:53 I guess that means "possible, but unlikely" for F31 15:32:03 I don't think it needs to be stated 15:32:25 You would have to document how to upgrade from non-modular to modular applications somewhere -- AIUI this is not something that is well-known 15:32:47 #agree 1) eclipse module doesn't get a default stream in f31, creating a Common Issues entry is recommended 2) adding default stream for eclipse module for f32 can be put on discussion via Fedora Change process 3) FESCo will identify work items on the policy enforcement for default streams content (+8, 0, -0) 15:33:13 And obviously "dnf groupinstall" does not work without default streams -- should I remove the Eclipse comps group entirely? 15:33:29 mbooth, hopefully it will be fixed by DNF folks before it becomes yet another "disable selinux at first" :) 15:33:52 https://docs.fedoraproject.org/en-US/modularity/installing-modules/ doesn't actually answer this question, I think. 15:34:38 I'll add it to the list in https://pagure.io/modularity/issue/168. 15:34:54 mbooth, well, I don't think we have to do this. Hopefully at some point it will work. I believe some of our comps are broken and we don't fix them. But that's just my opinion. 15:35:22 I would rather fix non-modular eclipse in F31 so it actually *does* work 15:35:26 ignatenkobrain_: Well, I get quite a few bugs when comps is broken, so at least the Eclipse group is maintained by me 15:35:47 mbooth, what's missing in non-modular stuff to make non-modular eclipse work? 15:36:57 I'd estimate about 1-2 dozen retired packages, but mbooth should know better 15:37:09 I lost count TBH 15:37:54 You can my build time deps in the tycho module: https://src.fedoraproject.org/modules/tycho/blob/1.4/f/tycho.yaml 15:38:15 nirik, zbyszek, dcantrell, sgallagh, contyk, bookwar, decathorpe: so should we drop eclipse from comps for f31 until it is fixed? 15:38:55 ignatenkobrain_: I am fine with that 15:39:05 does it have impact on other groups? 15:39:44 the scientific lab includes eclipse... so that will break 15:39:58 otherwise it would be ok 15:39:58 well it's already broken 15:40:04 If there is no plan to make the comps group useful, then I think it should be dropped. 15:40:21 That was one of the reasons for a default stream because spins are using comps groups 15:40:27 actually... not sure it could be dropped. 15:40:35 developer-workstation-environment, development, electronic-lab depend on eclipse group 15:41:13 so ... don't remove it but try to fix it? 15:41:25 I can help with that, if necessary 15:42:00 decathorpe, that would be very nice. I am not very happy with shipping broken software to the users. 15:42:07 IIRC, comps groups are additive accross repos... so the one in the base repo from GA that has the eclipse group would be used if we nuke the one from updates... but I could be misremembering... 15:42:44 mbooth: does the list only include retired packages, or also packages which have versions incompatible with what's currently available in Fedora? 15:42:46 ignatenkobrain_: me either. I'd just need a list of packages that needs to be fixed. 15:43:04 zbyszek: Which list? 15:43:19 mbooth: the list to make non-modular eclipse healthy again 15:43:44 proposal #action decathorpe will try to help fixing non-modular eclipse in F31 15:43:54 decathorpe, fine with that? 15:44:04 I don't know that we need to vote on that. ;) 15:44:15 :) 15:44:17 nirik, did not meant this to be voting, just so that decathorpe is fine with it :) 15:44:18 I think decathorpe needs to get a vote 15:44:21 if you vote I can't veto it ;) 15:44:27 decathorpe, lol 15:44:31 #action decathorpe will try to help fixing non-modular eclipse in F31 15:44:39 let's move on 15:44:40 well, and mbooth... :) but they could talk outside meeting... 15:44:41 #topic #2291 F32 System-Wide Change: Disallow Empty Password By Default 15:44:41 .fesco 2291 15:44:42 ignatenkobrain_: Issue #2291: F32 System-Wide Change: Disallow Empty Password By Default - fesco - Pagure.io - https://pagure.io/fesco/issue/2291 15:45:15 Meta question for after that: should we amend our rules as proposed in the ticket. 15:45:30 yeah, I think having -7 should make it instant reject 15:45:46 agreed 15:45:49 zbyszek: Yesm some modular packages have been updated and diverge from non-modular -- I have been maintaining modular versions as if they were part of the base repo (i.e. business as usual) 15:45:56 and for the record, I'm a -1 on #2291 15:46:10 I lost track of the conversation on devel once it became a shouting match between 2-3 people ... 15:46:59 yeah, that thread should be closed. I almost asked people several times, but oh well... if it's still going today it should end... 15:47:20 any volunteers to update our docs if we agree on this amendment? 15:47:23 mbooth: Ping me afterwards, or open a ticket in the stewardship sig project on pagure :) 15:47:36 decathorpe: Sure 15:47:43 ignatenkobrain_: I'll do it. 15:48:19 proposal: Reject this Change and amend our policy to do an instant reject when ticket gets -7 15:48:27 +1 15:48:38 +1 15:48:40 +1 15:48:49 +1 15:48:49 +1 15:49:41 I always forget how the vote counting works with rejected items... is it like (+n or -n)? 15:49:54 bookwar, sgallagh, vote? 15:50:07 mhroncok, I suppose you would like to vote as well? :) 15:50:09 +1 15:50:14 in this case the proposal is reject, so +1 to reject is -1 to the change 15:50:16 hey, sorry for being late 15:50:18 mhroncok: the vote is proposal: Reject this Change and amend our policy to do an instant reject when ticket gets -7 15:50:18 +1 15:50:42 zbyszek: for reference, if this is the default password change, +1 15:50:53 it is :) 15:51:00 #agree Reject this Change and amend our policy to do an instant reject when ticket gets -7 (+9, 0, -0) 15:51:17 #action zbyszek to update docs to reflect this 15:51:26 #topic Next week's chair 15:51:31 any volunteers? 15:51:41 I'll be around 15:51:46 and haven't done it in a while 15:51:58 also I would like to apologize for not sending schedule until the last moment, was quite busy with $dayjob 15:52:02 I will be here, but do not yet feel comfortable chairing a meeting yet. This is my first time ever using this meeting channel or having an irc meeting 15:52:07 #action contyk will chair next meeting 15:52:15 whats our schedule for the rest ot the year/early next? 15:52:30 I'm out for the rest of the calendar year 15:52:32 I would do one more this year and then take a break 15:52:40 Back on January 6 15:52:46 I think we should skip the holiday week meeting, and probably the one right after, too 15:52:53 ignatenkobrain: do we take a break in tickets as well? 15:52:53 sgallagh: me too 15:53:03 so, next meetings are Dec. 16 and Jan. 6? 15:53:03 skip 23th, 30th and meet on Jan 6th? 15:53:12 bookwar: +1 15:53:19 aka no auto approval after a week or two 15:53:23 mhroncok, that's good question. I don't know :) 15:53:41 I would still do autoapproval 15:53:48 decathorpe: +1 (although I will not be here next week) 15:53:54 I can do offline voting during the holidays, but I recon not everybody can 15:54:03 I think auto-approval is fine 15:54:04 I can too. 15:54:09 im online as well. so it's ok I guess 15:54:16 ok 15:54:25 I mean, the worst-case is that someone votes a temporary -1 to hold it up until a meeting 15:54:31 (If they think it might need more time) 15:54:37 I'll be online as well. (/me is having PagerDuty at work since 23rd until 6th) :) 15:55:06 ignatenkobrain_: that's rough 15:55:18 +1 to what bookwar and decathorpe said basically 15:55:27 same, +1 15:55:28 * nirik will be around all holiday for alerts/emergencies... 15:55:36 #info The next meeting will be on 16th of Dec and then on Jan. 6. There will be still voting in the tickets and auto-approvals. 15:55:56 #topic Open Floor 15:56:32 anybody has anything? :) 15:56:37 I have many questions 15:56:44 dcantrell, go ahead! 15:56:44 but I will start simple 15:56:44 dcantrell: 42 15:57:12 for modules that bundle packages that are included in non-modular fedora, how do users report bugs? that is, who is maintaining the package in the module vs. the base system? 15:57:25 I have searched for a policy on that and can't find anything 15:57:34 The module maintainer is required to do so 15:57:47 (could somebody share a log of this meeting with me in the meantime via a PM please?) 15:57:54 dcantrell, you mean you have sorted your questions by `-simplicity`? 15:57:56 mhroncok: I'll will 15:57:57 they report bugs on the module, but how they know that I am not sure. ;) 15:58:09 they report bugs anywhere 15:58:16 nirik: right, this is the problem I'm getting at 15:58:20 teh mainaters can then shuffle them arounds 15:58:22 *around 15:58:29 for Java stuff we reassign it to the one responsible ... 15:58:31 sorry, let me rephrase... ideally they would file the bug on the module. 15:58:39 like ignatenkobrain_ noted he didn't know eclipse did this and is the protobuf maintainer 15:59:26 so the procedure is for the user to file against the module and the module maintainer is the bug multiplexer that way....BUT, in the protobuf example, igor didn't know eclipse did that so how would he be on the hook to fix a bug in that protobuf? 15:59:32 it takes an enormous amount of effor to even find out what module is the package coming from, we cannot expects the users to know 15:59:33 I think if this happens (that module overrides non-modular package), then maintainers of non-modular packages should be aware of that. That would mean, they can easily reassign bugreport. 15:59:33 if the user reports the NVR, as they should, it will likely be clear 16:00:04 I feel this is setting up maintainers for failure 16:00:25 in any module can bundle anything provided by the base system *and* override it, how can the non-modular package maintainer be on the hook for that? 16:00:27 IMHO such thing should not be possible in the first place. 16:00:36 mhroncok, +1 16:00:36 * decathorpe shrugs 16:00:53 that's a longer discussion though 16:01:05 if they aren't on the hook and the module maintainer is, then modules are discourage cooperation and coordination among package maintainers 16:01:07 I think it should be possible; not in the defaults, of course 16:01:09 dcantrell, if they are fine with that, they should simply reassign bug to a proper person I think. If they are not, such module should not be shipped. 16:01:10 decathorpe: yes, it is 16:01:20 but it's one of the features, providing alternative content 16:01:37 contyk: it should not be possible to override "my" package without me knowing it, default or not 16:01:45 mhroncok: +1 16:01:54 filing bugs in general is difficult sometimes.... 16:01:56 contyk, if somebody who is shipping this alternative content is not a maintainer of those packages, it must not be possible. 16:01:56 I am ok taking this discussion to a ticket and continuing in a future meeting 16:02:03 but everyone sees the concern I have here, right? 16:02:10 dcantrell, sure. 16:02:10 yeah 16:02:15 yep 16:02:16 definitely. 16:02:34 I will open a fesco ticket for us to continue the discussion 16:02:42 thanks 16:02:43 the modular maintainers who do this are abusing their provenpackager privileges 16:03:00 dcantrell, now try the hardest question from ones you've had! 16:03:03 mhroncok: agreed, but I feel the way things are set up right now sort of encourage that behavior 16:03:05 well, all module maintainers are effectively super-provenpackagers 16:03:21 ignatenkobrain_: do you really want me to say it in my first fesco meeting? 16:03:30 dcantrell, ofc! 16:04:05 ok... 16:04:15 (and on a side note, I don't think we have any nonprovenpackager modular maitainers, except for very small selfcountianed modules) 16:05:22 FWIW I conciously limit my provenpackager powers to packages that ship java bytecode -- this is the only area I can claim expertise 16:05:33 as a user I have not used modules in any way. my only experience with modularity so far is that my system received a broken protobuf package. as a user that leads to generally not trust modularity. I spent the weekend reading docs about modularity and understanding as much as I can about it. I'm sure I am lacking info and misunderstanding some things, but I don't understand what we gain 16:05:39 from modularity except broken behavior. what does it offer over flatpak and podman containers? 16:06:03 dcantrell: no, let's not go there. 16:06:07 zbyszek, :D 16:06:15 hey, igor asked! :) 16:06:34 I mean, I want to finish this meeting *today*, and this has been discussed for weeks on the mailing list. 16:06:45 completely understood 16:06:57 :) 16:07:03 I do think there is a lot in modularity to unpack and I want to actually understand more about it 16:07:13 documentation is lacking, the system is opaque, and it's taking me a while to get through it 16:07:14 "happy" to answer your question on #fedora-modularity 16:07:15 well, we can dedicate 1hr of each meeting to discuss this question :D 16:07:25 so for now I will open my ticket about the bug filing question 16:07:42 dcantrell: but if you've really read the docs and still find them lacking, let us know what's missing 16:08:07 dcantrell: Specifically https://docs.fedoraproject.org/en-US/modularity/ 16:08:45 dcantrell: I have opinions on this too (as the Eclipse module maintainer, the Eclipse RPM maintainer, and Eclipse Flatpak maintainer) if you want them :-) 16:08:48 thanks, I will go through that again 16:08:55 dcantrell: also https://communityblog.fedoraproject.org/fedora-modularity-whats-the-problem/ 16:09:02 Might be good to start there 16:09:13 mbooth: sure, I'm interested in this from the maintainer's point of view too 16:09:50 dcantrell, so now you have answer: read 15 different pages and tell those folks what's missing. That's it about modularity. 16:09:57 so, anyone has anything else? 16:10:00 .fire ignatenkobrain_ 16:10:00 adamw fires ignatenkobrain_ 16:10:42 dcantrell, feel free to ping me as well, I was the one who dropped 28 out of 52 modules (all of which had default stream and were maintained by me) from Fedora at some point 16:10:54