15:00:17 <ignatenkobrain_> #startmeeting FESCO (2019-12-09)
15:00:18 <zodbot> Meeting started Mon Dec  9 15:00:17 2019 UTC.
15:00:18 <zodbot> This meeting is logged and archived in a public location.
15:00:18 <zodbot> The chair is ignatenkobrain_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:18 <zodbot> The meeting name has been set to 'fesco_(2019-12-09)'
15:00:28 <ignatenkobrain_> #meetingname fesco
15:00:28 <zodbot> The meeting name has been set to 'fesco'
15:00:28 <ignatenkobrain_> #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrel
15:00:28 <zodbot> Current chairs: bookwar contyk dcantrel decathorpe ignatenkobrain ignatenkobrain_ mhroncok nirik sgallagh zbyszek
15:00:28 <ignatenkobrain_> #topic init process
15:00:32 <sgallagh> .hello2
15:00:33 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:37 <bookwar> .hello2
15:00:38 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:00:55 <contyk> .hello psabata
15:00:56 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:06 <decathorpe> .hello2
15:01:06 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:01:15 <bcotton> .hello2
15:01:16 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:19 * contyk doesn't have a working browser today
15:01:40 <dcantrell> .hello2
15:01:43 <ignatenkobrain_> contyk, \o/
15:01:43 <zodbot> dcantrell: Sorry, but you don't exist
15:01:53 <ignatenkobrain_> contyk, now we can just lie to you about content of a tickets :D
15:01:55 <nirik> morning
15:02:00 <dcantrell> my FAS account is 'dcantrel' and I use 'dcantrell' on IRC
15:02:07 <dcantrell> can anyone fix that?
15:02:09 <ignatenkobrain_> dcantrell, .hello dcantrel :)
15:02:21 <dcantrell> ignatenkobrain_: hi
15:02:24 <sgallagh> dcantrell: You can set your IRC nick in FAS and it will map them
15:02:31 <dcantrell> sgallagh: thanks
15:02:39 <sgallagh> np
15:02:45 <zbyszek> .ehllo2
15:02:47 <zbyszek> .hello2
15:02:48 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:59 <contyk> ignatenkobrain_: at least I can focus on you all :)
15:03:07 <sgallagh> .hello dcantrel
15:03:08 <zodbot> sgallagh: dcantrel 'David Cantrell' <dcantrell@redhat.com>
15:03:11 <sgallagh> (For the record)
15:03:20 <sgallagh> s/record/log/
15:03:21 <ignatenkobrain_> I think we are missing only Miro, but I think he said that he won't make it today
15:03:24 <nirik> hello2 is for when your irc nick and fas name are the same. :) hello <fasname> is the version for if they are different
15:03:26 <dcantrell> sgallagh: apparently I already had my irc nick set in FAS
15:03:35 <ignatenkobrain_> > I am not sure whether I can make it to the this meeting
15:03:37 <sgallagh> odd
15:03:45 <dcantrell> nirik: thanks
15:03:51 <sgallagh> nirik: Oh, my mistake
15:04:03 <ignatenkobrain_> so I guess we can start without Miro and hope he will join us later :)
15:04:13 <ignatenkobrain_> #topic #2295 Update FESCo membership with elections results, possibly setup new meeting time
15:04:21 <ignatenkobrain_> so first of all, welcome dcantrell and decathorpe :)
15:04:29 <dcantrell> thank you!
15:04:32 * sgallagh waves
15:04:35 <zbyszek> welcome!
15:04:38 <decathorpe> thanks :)
15:04:39 <nirik> and many thanks to outgoing members too!
15:04:40 <ignatenkobrain_> I hope bcotton already gave you a badge :)
15:04:48 <contyk> welcome to the party!
15:04:51 <ignatenkobrain_> nirik, that's the second of all :)
15:04:52 <dcantrell> I do have a badge
15:04:56 <dcantrell> also more email
15:04:57 <dcantrell> :)
15:05:01 <decathorpe> yeah, all good
15:05:09 <ignatenkobrain_> dcantrell, there is never too much email, right?
15:05:19 <dcantrell> of course not
15:05:21 <bookwar> gmail eats it all
15:05:22 <ignatenkobrain_> .fesco 2295
15:05:23 <zodbot> 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 <ignatenkobrain_> decathorpe, dcantrell, do you want to propose different time for this meeting or it is good enough?
15:06:00 <dcantrell> this time is fine for me
15:06:10 * nirik isn't crazy about this time, but can deal with it
15:06:27 <dcantrell> I am ok with a different time, but I can't do earlier
15:06:30 <zbyszek> yeah, I'm not crazy about, but realistically we are unlikely to get time earlier in the day
15:06:36 <bookwar> let's wait for miro to get a schedule and try to vote again
15:06:37 <contyk> we can do whenisgood again
15:06:54 <dcantrell> sounds reasonable to me
15:06:55 <contyk> although I kinda like this slot; doesn't conflict with anything and it isn't Friday night like before
15:07:12 <ignatenkobrain_> contyk, =1
15:08:02 <ignatenkobrain_> Proposal: keep this time for next ~2mo and then possibly run whenisgood
15:08:11 <sgallagh> +1
15:08:22 <zbyszek> +1
15:08:27 <decathorpe> +1
15:08:27 <bookwar> +1
15:08:30 <dcantrell> +1
15:08:49 <contyk> +1
15:09:10 <nirik> sure, I suppose, +1
15:09:18 <ignatenkobrain_> #agree Keep this time for next ~2mo and then possibly run whenisgood (+8, 0, -0)
15:09:22 <ignatenkobrain_> #topic #2285 Make Eclipse Installable
15:09:25 <ignatenkobrain_> .fesco 2285
15:09:27 <zodbot> ignatenkobrain_: Issue #2285: Make Eclipse Installable - fesco - Pagure.io - https://pagure.io/fesco/issue/2285
15:09:30 <ignatenkobrain_> 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 <bookwar> our favorite
15:10:10 <ignatenkobrain_> sgallagh, contyk do you have a solution which would revert modular RPMs to a "traditional" ones?
15:10:35 <contyk> nope, not currently
15:10:55 <ignatenkobrain_> is it being worked on?
15:11:12 <dcantrell> Langdon posted instructions on fedora-devel on how to revert.  I have not tested it myself.
15:11:14 <sgallagh> ignatenkobrain_: We're trying to brainstorm a solution
15:11:20 <nirik> in the mean time, perhaps adding it to common bugs and sending a announce post about it would be good?
15:11:29 <contyk> 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 <sgallagh> dcantrell: Reversion is useful, but we need a forward path
15:11:36 <ignatenkobrain_> dcantrell, well, dnf module disable && dnf distro-sync should do the trick. I did the same for Rust stuff
15:11:40 <contyk> it's being discussed but it's slow
15:12:12 <dcantrell> sgallagh: you mean forward as in revert but also let people still install the eclipse module?
15:12:25 <ignatenkobrain_> sgallagh, IIRC you have removed eclipse defaults, right? what abount maven?
15:12:27 <sgallagh> 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 <sgallagh> dcantrell: As in "do the revert for them when doing a regular `dnf update`"
15:13:04 <contyk> 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 <sgallagh> Moving further along to fixing Eclipse installation
15:13:06 <bookwar> are we discussing recovery from enabling eclipse as default, or the plan forward for eclipse?
15:13:30 <sgallagh> bookwar: Both, plus the general case of "drop an RPM from a module back to non-modular"
15:13:36 <dcantrell> I thought the question was how do we restore the functional protobuf for users
15:13:49 <bookwar> as i understood recovery procedure is clear we just need to announce it
15:13:52 <sgallagh> dcantrell: That's the specific symptom
15:14:20 <dcantrell> I feel that a path forward discussion is more involved
15:14:34 <dcantrell> no one has explained why eclipse bundled protobuf.  that seems really weird to me
15:14:43 <sgallagh> Let me provide a bit of background information that should clarify a few points.
15:15:00 <mbooth> dcantrell: It is a dependency of the javascript interpreter used by eclipse-webtools
15:15:41 <dcantrell> mbooth: ok, why bundle though?  it's provided by fedora.
15:15:47 <sgallagh> 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 <ignatenkobrain_> mbooth, then probably more general question. why did you put anything what is not eclipse-* into an eclipse module?
15:16:16 <sgallagh> 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 <sgallagh> 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 <sgallagh> So we're trying to fix that, which will allow us to simply drop protobuf from the stream and fix users.
15:17:17 <mbooth> 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 <zbyszek> mbooth: I think the stewardship sig would disagree with this stmt
15:17:49 <sgallagh> I don't know how actively DNF is working on this right this second.
15:18:00 <ignatenkobrain_> sgallagh, do we have link to a bug FTR?
15:18:10 <contyk> 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 <sgallagh> One moment
15:18:21 <contyk> but obviously it's not practical
15:18:28 <sgallagh> .bug 1770285
15:18:29 <decathorpe> zbyszek: we do ;)
15:18:30 <zodbot> sgallagh: 1770285 – Cannot drop packages from module stream - https://bugzilla.redhat.com/1770285
15:18:52 <contyk> I have a meeting with the DNF team tomorrow again, discussing this behavior :)
15:19:04 <mbooth> 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 <ignatenkobrain_> 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 <sgallagh> contyk: Can you extend that invite to me as well, please?
15:19:26 <contyk> sgallagh: sure
15:19:31 <sgallagh> Thank you
15:19:37 <dcantrell> 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 <contyk> sgallagh: oh, it's actually Wednesday
15:20:18 <bookwar> sgallagh: current state is that default module for eclipse is off?
15:20:25 <sgallagh> bookwar: Yes
15:20:35 <bookwar> for both f31 and f32
15:20:40 <sgallagh> yes
15:20:43 <nirik> IMHO, we can just not add any new ones... I think the existing ones should be ok.
15:21:06 <sgallagh> Right, and the current policy is that all new default streams requires FESCo approval already.
15:21:10 <bookwar> nirik: assuming that maintainers of current default streams don't add unexpected iverrides
15:21:21 <ignatenkobrain_> I think we need to drop maven default stream too
15:21:22 <dcantrell> 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 <zbyszek> 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 <sgallagh> dcantrell: Excellent question.
15:22:08 <dcantrell> 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 <sgallagh> dcantrell: The hand-wavy answer is  "automated testing"
15:22:22 <dcantrell> sgallagh: good answer  :)
15:22:23 <ignatenkobrain_> 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 <contyk> so all the changes to defaults are submitted as PRs to fedora-modules-defaults
15:23:07 <sgallagh> 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 <dcantrell> 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 <bookwar> ignatenkobrain_: i think it is a separate issue, we should have a discussion on it
15:23:35 <contyk> I think whoever is approving those PRs should be required to ask for a FESCo ticket reference
15:23:40 <dcantrell> sgallagh: I think we should identify the actual work that should happen and then figure out who can work on it
15:23:55 <contyk> or it could be linking to the ticket and an automated test could validate it, yes
15:23:58 <sgallagh> contyk: That would be me, and I do
15:24:14 <dcantrell> 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 <nirik> I think atomation is better than us. ;)
15:24:28 <sgallagh> dcantrell: +1
15:24:33 <dcantrell> nirik: agreed, automation is certainly how this scales
15:24:49 <sgallagh> dcantrell: For initial addition of a default stream, we require a FESCo vote
15:25:02 <sgallagh> Once that's in, right now the maintainer has full autonomy
15:25:22 <dcantrell> 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 <sgallagh> 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 <dcantrell> sgallagh: +1
15:26:00 <decathorpe> sgallagh: that sounds reasonable yeah
15:26:07 <zbyszek> yep, sounds very reasonable.
15:26:24 <contyk> um, while I understand your intention, I think that will add significant process burden to module maintanance
15:26:52 <ignatenkobrain_> contyk, it is already burden, so I don't think it is a problem :)
15:26:53 <ignatenkobrain_> sgallagh, +1
15:26:58 <sgallagh> contyk: I'm not sure I understand your concern
15:27:18 <dcantrell> 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 <dcantrell> I think the process needs to manual now to get the details sorted out about what automating that looks like
15:27:47 <contyk> 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 <sgallagh> contyk: I think that needs to be our first pass, and then we can refine it
15:28:03 <dcantrell> 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 <sgallagh> contyk: I think we can consider allowing special-cases as they arise.
15:28:36 <dcantrell> maybe we should let module maintainers eventually earn "provenmoduler"
15:28:49 <ignatenkobrain_> :/
15:28:50 <sgallagh> 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 <sgallagh> So you can add non-conflicting content easily.
15:29:12 <bookwar> 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 <sgallagh> But if it would override, *Red Alert, Shields Up*
15:29:38 <sgallagh> +1/+1/+1
15:29:42 <sgallagh> bookwar: ^^
15:29:45 <zbyszek> bookwar: +1
15:29:51 <decathorpe> bookwar: +1
15:29:51 <dcantrell> bookwar: +1
15:29:58 <ignatenkobrain_> bookwar, +1
15:30:18 <nirik> +1
15:30:21 <contyk> ... +1
15:30:44 <sgallagh> 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 <sgallagh> Acceptable?
15:31:11 <zbyszek> sgallagh: I think that's always possible, we don't need to say that explicitly.
15:31:28 <sgallagh> Well, the way it's phrased sounded like a definitive "not in F31"
15:31:32 <sgallagh> So I wanted that to be clear
15:31:49 <ignatenkobrain_> I'm fine with either
15:31:53 <decathorpe> I guess that means "possible, but unlikely" for F31
15:32:03 <dcantrell> I don't think it needs to be stated
15:32:25 <mbooth> 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 <ignatenkobrain_> #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 <mbooth> And obviously "dnf groupinstall" does not work without default streams -- should I remove the Eclipse comps group entirely?
15:33:29 <ignatenkobrain_> mbooth, hopefully it will be fixed by DNF folks before it becomes yet another "disable selinux at first" :)
15:33:52 <zbyszek> https://docs.fedoraproject.org/en-US/modularity/installing-modules/ doesn't actually answer this question, I think.
15:34:38 <zbyszek> I'll add it to the list in https://pagure.io/modularity/issue/168.
15:34:54 <ignatenkobrain_> 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 <ignatenkobrain_> I would rather fix non-modular eclipse in F31 so it actually *does* work
15:35:26 <mbooth> 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 <ignatenkobrain_> mbooth, what's missing in non-modular stuff to make non-modular eclipse work?
15:36:57 <decathorpe> I'd estimate about 1-2 dozen retired packages, but mbooth should know better
15:37:09 <mbooth> I lost count TBH
15:37:54 <mbooth> 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 <ignatenkobrain_> nirik, zbyszek, dcantrell, sgallagh, contyk, bookwar, decathorpe: so should we drop eclipse from comps for f31 until it is fixed?
15:38:55 <dcantrell> ignatenkobrain_: I am fine with that
15:39:05 <bookwar> does it have impact on other groups?
15:39:44 <nirik> the scientific lab includes eclipse... so that will break
15:39:58 <nirik> otherwise it would be ok
15:39:58 <decathorpe> well it's already broken
15:40:04 <zbyszek> If there is no plan to make the comps group useful, then I think it should be dropped.
15:40:21 <mbooth> That was one of the reasons for a default stream because spins are using comps groups
15:40:27 <nirik> actually... not sure it could be dropped.
15:40:35 <ignatenkobrain_> developer-workstation-environment, development, electronic-lab depend on eclipse group
15:41:13 <decathorpe> so ... don't remove it but try to fix it?
15:41:25 <decathorpe> I can help with that, if necessary
15:42:00 <ignatenkobrain_> decathorpe, that would be very nice. I am not very happy with shipping broken software to the users.
15:42:07 <nirik> 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 <zbyszek> 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 <decathorpe> ignatenkobrain_: me either. I'd just need a list of packages that needs to be fixed.
15:43:04 <mbooth> zbyszek: Which list?
15:43:19 <zbyszek> mbooth: the list to make non-modular eclipse healthy again
15:43:44 <ignatenkobrain_> proposal #action decathorpe will try to help fixing non-modular eclipse in F31
15:43:54 <ignatenkobrain_> decathorpe, fine with that?
15:44:04 <nirik> I don't know that we need to vote on that. ;)
15:44:15 <contyk> :)
15:44:17 <ignatenkobrain_> nirik, did not meant this to be voting, just so that decathorpe is fine with it :)
15:44:18 <zbyszek> I think decathorpe needs to get a vote
15:44:21 <decathorpe> if you vote I can't veto it ;)
15:44:27 <ignatenkobrain_> decathorpe, lol
15:44:31 <ignatenkobrain_> #action decathorpe will try to help fixing non-modular eclipse in F31
15:44:39 <ignatenkobrain_> let's move on
15:44:40 <nirik> well, and mbooth... :) but they could talk outside meeting...
15:44:41 <ignatenkobrain_> #topic #2291 F32 System-Wide Change: Disallow Empty Password By Default
15:44:41 <ignatenkobrain_> .fesco 2291
15:44:42 <zodbot> ignatenkobrain_: Issue #2291: F32 System-Wide Change: Disallow Empty Password By Default - fesco - Pagure.io - https://pagure.io/fesco/issue/2291
15:45:15 <zbyszek> Meta question for after that: should we amend our rules as proposed in the ticket.
15:45:30 <ignatenkobrain_> yeah, I think having -7 should make it instant reject
15:45:46 <dcantrell> agreed
15:45:49 <mbooth> 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 <dcantrell> and for the record, I'm a -1 on #2291
15:46:10 <decathorpe> I lost track of the conversation on devel once it became a shouting match between 2-3 people ...
15:46:59 <nirik> 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 <ignatenkobrain_> any volunteers to update our docs if we agree on this amendment?
15:47:23 <decathorpe> mbooth: Ping me afterwards, or open a ticket in the stewardship sig project on pagure :)
15:47:36 <mbooth> decathorpe: Sure
15:47:43 <zbyszek> ignatenkobrain_: I'll do it.
15:48:19 <ignatenkobrain_> proposal: Reject this Change and amend our policy to do an instant reject when ticket gets -7
15:48:27 <zbyszek> +1
15:48:38 <dcantrell> +1
15:48:40 <decathorpe> +1
15:48:49 <contyk> +1
15:48:49 <nirik> +1
15:49:41 <ignatenkobrain_> I always forget how the vote counting works with rejected items... is it like (+n or -n)?
15:49:54 <ignatenkobrain_> bookwar, sgallagh, vote?
15:50:07 <ignatenkobrain_> mhroncok, I suppose you would like to vote as well? :)
15:50:09 <bookwar> +1
15:50:14 <contyk> in this case the proposal is reject, so +1 to reject is -1 to the change
15:50:16 <mhroncok> hey, sorry for being late
15:50:18 <zbyszek> mhroncok: the vote is proposal: Reject this Change and amend our policy to do an instant reject when ticket gets -7
15:50:18 <sgallagh> +1
15:50:42 <mhroncok> zbyszek: for reference, if this is the default password change, +1
15:50:53 <decathorpe> it is :)
15:51:00 <ignatenkobrain_> #agree Reject this Change and amend our policy to do an instant reject when ticket gets -7 (+9, 0, -0)
15:51:17 <ignatenkobrain_> #action zbyszek to update docs to reflect this
15:51:26 <ignatenkobrain_> #topic Next week's chair
15:51:31 <ignatenkobrain_> any volunteers?
15:51:41 <contyk> I'll be around
15:51:46 <contyk> and haven't done it in a while
15:51:58 <ignatenkobrain_> also I would like to apologize for not sending schedule until the last moment, was quite busy with $dayjob
15:52:02 <dcantrell> 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 <ignatenkobrain_> #action contyk will chair next meeting
15:52:15 <nirik> whats our schedule for the rest ot the year/early next?
15:52:30 <sgallagh> I'm out for the rest of the calendar year
15:52:32 <ignatenkobrain_> I would do one more this year and then take a break
15:52:40 <sgallagh> Back on January 6
15:52:46 <contyk> I think we should skip the holiday week meeting, and probably the one right after, too
15:52:53 <mhroncok> ignatenkobrain: do we take a break in tickets as well?
15:52:53 <nirik> sgallagh: me too
15:53:03 <decathorpe> so, next meetings are Dec. 16 and Jan. 6?
15:53:03 <bookwar> skip 23th, 30th and meet on Jan 6th?
15:53:12 <contyk> bookwar: +1
15:53:19 <mhroncok> aka no auto approval after a week or two
15:53:23 <ignatenkobrain_> mhroncok, that's good question. I don't know :)
15:53:41 <contyk> I would still do autoapproval
15:53:48 <nirik> decathorpe: +1 (although I will not be here next week)
15:53:54 <mhroncok> I can do offline voting during the holidays, but I recon not everybody can
15:54:03 <sgallagh> I think auto-approval is fine
15:54:04 <zbyszek> I can too.
15:54:09 <decathorpe> im online as well. so it's ok I guess
15:54:16 <mhroncok> ok
15:54:25 <sgallagh> I mean, the worst-case is that someone votes a temporary -1 to hold it up until a meeting
15:54:31 <sgallagh> (If they think it might need more time)
15:54:37 <ignatenkobrain_> I'll be online as well. (/me is having PagerDuty at work since 23rd until 6th) :)
15:55:06 <decathorpe> ignatenkobrain_: that's rough
15:55:18 <mhroncok> +1 to what bookwar and decathorpe said basically
15:55:27 <dcantrell> same, +1
15:55:28 * nirik will be around all holiday for alerts/emergencies...
15:55:36 <ignatenkobrain_> #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 <ignatenkobrain_> #topic Open Floor
15:56:32 <ignatenkobrain_> anybody has anything? :)
15:56:37 <dcantrell> I have many questions
15:56:44 <ignatenkobrain_> dcantrell, go ahead!
15:56:44 <dcantrell> but I will start simple
15:56:44 <mbooth> dcantrell: 42
15:57:12 <dcantrell> 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 <dcantrell> I have searched for a policy on that and can't find anything
15:57:34 <sgallagh> The module maintainer is required to do so
15:57:47 <mhroncok> (could somebody share a log of this meeting with me in the meantime via a PM please?)
15:57:54 <ignatenkobrain_> dcantrell, you mean you have sorted your questions by `-simplicity`?
15:57:56 <zbyszek> mhroncok: I'll will
15:57:57 <nirik> they report bugs on the module, but how they know that I am not sure. ;)
15:58:09 <mhroncok> they report bugs anywhere
15:58:16 <dcantrell> nirik: right, this is the problem I'm getting at
15:58:20 <mhroncok> teh mainaters can then shuffle them arounds
15:58:22 <mhroncok> *around
15:58:29 <decathorpe> for Java stuff we reassign it to the one responsible ...
15:58:31 <nirik> sorry, let me rephrase... ideally they would file the bug on the module.
15:58:39 <dcantrell> like ignatenkobrain_ noted he didn't know eclipse did this and is the protobuf maintainer
15:59:26 <dcantrell> 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 <mhroncok> 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 <ignatenkobrain_> 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 <contyk> if the user reports the NVR, as they should, it will likely be clear
16:00:04 <dcantrell> I feel this is setting up maintainers for failure
16:00:25 <dcantrell> 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 <mhroncok> IMHO such thing should not be possible in the first place.
16:00:36 <ignatenkobrain_> mhroncok, +1
16:00:36 * decathorpe shrugs
16:00:53 <decathorpe> that's a longer discussion though
16:01:05 <dcantrell> 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 <contyk> I think it should be possible; not in the defaults, of course
16:01:09 <ignatenkobrain_> 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 <dcantrell> decathorpe: yes, it is
16:01:20 <contyk> but it's one of the features, providing alternative content
16:01:37 <mhroncok> contyk: it should not be possible to override "my" package without me knowing it, default or not
16:01:45 <dcantrell> mhroncok: +1
16:01:54 <nirik> filing bugs in general is difficult sometimes....
16:01:56 <ignatenkobrain_> contyk, if somebody who is shipping this alternative content is not a maintainer of those packages, it must not be possible.
16:01:56 <dcantrell> I am ok taking this discussion to a ticket and continuing in a future meeting
16:02:03 <dcantrell> but everyone sees the concern I have here, right?
16:02:10 <ignatenkobrain_> dcantrell, sure.
16:02:10 <decathorpe> yeah
16:02:15 <zbyszek> yep
16:02:16 <nirik> definitely.
16:02:34 <dcantrell> I will open a fesco ticket for us to continue the discussion
16:02:42 <ignatenkobrain_> thanks
16:02:43 <mhroncok> the modular maintainers who do this are abusing their provenpackager privileges
16:03:00 <ignatenkobrain_> dcantrell, now try the hardest question from ones you've had!
16:03:03 <dcantrell> mhroncok: agreed, but I feel the way things are set up right now sort of encourage that behavior
16:03:05 <zbyszek> well, all module maintainers are effectively super-provenpackagers
16:03:21 <dcantrell> ignatenkobrain_: do you really want me to say it in my first fesco meeting?
16:03:30 <ignatenkobrain_> dcantrell, ofc!
16:04:05 <dcantrell> ok...
16:04:15 <mhroncok> (and on a side note, I don't think we have any nonprovenpackager modular maitainers, except for very small selfcountianed modules)
16:05:22 <mbooth> 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 <dcantrell> 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 <dcantrell> from modularity except broken behavior.  what does it offer over flatpak and podman containers?
16:06:03 <zbyszek> dcantrell: no, let's not go there.
16:06:07 <ignatenkobrain_> zbyszek, :D
16:06:15 <dcantrell> hey, igor asked!  :)
16:06:34 <zbyszek> I mean, I want to finish this meeting *today*, and this has been discussed for weeks on the mailing list.
16:06:45 <dcantrell> completely understood
16:06:57 <contyk> :)
16:07:03 <dcantrell> I do think there is a lot in modularity to unpack and I want to actually understand more about it
16:07:13 <dcantrell> documentation is lacking, the system is opaque, and it's taking me a while to get through it
16:07:14 <contyk> "happy" to answer your question on #fedora-modularity
16:07:15 <ignatenkobrain_> well, we can dedicate 1hr of each meeting to discuss this question :D
16:07:25 <dcantrell> so for now I will open my ticket about the bug filing question
16:07:42 <contyk> dcantrell: but if you've really read the docs and still find them lacking, let us know what's missing
16:08:07 <sgallagh> dcantrell: Specifically https://docs.fedoraproject.org/en-US/modularity/
16:08:45 <mbooth> 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 <dcantrell> thanks, I will go through that again
16:08:55 <sgallagh> dcantrell: also https://communityblog.fedoraproject.org/fedora-modularity-whats-the-problem/
16:09:02 <sgallagh> Might be good to start there
16:09:13 <dcantrell> mbooth: sure, I'm interested in this from the maintainer's point of view too
16:09:50 <ignatenkobrain_> dcantrell, so now you have answer: read 15 different pages and tell those folks what's missing. That's it about modularity. </joking-mode>
16:09:57 <ignatenkobrain_> so, anyone has anything else?
16:10:00 <sgallagh> .fire ignatenkobrain_
16:10:00 <zodbot> adamw fires ignatenkobrain_
16:10:42 <ignatenkobrain_> 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 <ignatenkobrain_> I'll close this in a minute if nobody has anything
16:10:55 <sgallagh> Oh right, https://docs.fedoraproject.org/en-US/modularity/history/ contains the content from that blog post also
16:11:02 <dcantrell> ignatenkobrain_: thanks
16:11:05 <sgallagh> But maybe that needs to be more discoverable
16:11:07 <mhroncok> whre in the docs do I find it explained, how the modular content overrides the nonmodular content and when this goes away? for exmple, if proftobuf is removed from the eclipse module, is it enough for the nonmodular protobuf to ga back?
16:11:22 <mhroncok> *go
16:11:37 <ignatenkobrain_> mhroncok, sgallagh described this today... there is dnf bug and he is going to have meeting with DNF folks this wednesday
16:11:40 <sgallagh> mhroncok: Assuming normal ENVR update rules?
16:11:41 <contyk> mhroncok: no; we talked about it before you joined
16:11:52 <mhroncok> sure, will read the logs
16:12:14 <ignatenkobrain_> so, thanks all for attending. see you next week!
16:12:17 <ignatenkobrain_> #endmeeting