15:00:10 <zbyszek> #startmeeting FESCO (2019-03-25)
15:00:10 <zodbot> Meeting started Mon Mar 25 15:00:10 2019 UTC.
15:00:10 <zodbot> This meeting is logged and archived in a public location.
15:00:10 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:10 <zodbot> The meeting name has been set to 'fesco_(2019-03-25)'
15:00:10 <zbyszek> #meetingname fesco
15:00:10 <zbyszek> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:10 <zodbot> The meeting name has been set to 'fesco'
15:00:10 <zodbot> Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:13 <zbyszek> #topic init process
15:00:28 <contyk> .hello psabata
15:00:31 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:32 <zbyszek> .hello2
15:00:35 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:36 <jforbes> .hello2
15:00:36 <bookwar> .hello2
15:00:38 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:41 <otaylor> .hello2
15:00:41 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:00:47 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:01:03 <zbyszek> We have quorum.
15:01:10 <mhroncok> hi
15:01:30 <zbyszek> Let's start with an easy one
15:01:36 <zbyszek> #topic #2105 F31 Change: Mono 5
15:01:37 <zbyszek> .fesco 2105
15:01:37 <zbyszek> https://pagure.io/fesco/issue/2105
15:01:38 <zodbot> zbyszek: Issue #2105: F31 Change: Mono 5 - fesco - Pagure.io - https://pagure.io/fesco/issue/2105
15:01:59 <zbyszek> I think there's general agreement, but the full week hasn't run, so the vote is not yet "finished".
15:02:25 <zbyszek> (I'm talking about the additional approval of the Change for F30.)
15:02:47 <zbyszek> We're at +7.
15:02:52 <zbyszek> Should I just mark it as accepted?
15:02:59 <mhroncok> this still haven't even built in rawhide, I'm 0 at doing this in Fedora 30.
15:03:13 <mhroncok> i.e. I'm not voting on purpose, not ignoring tha call for vote
15:03:50 <zbyszek> OK, so what do you propose?
15:04:20 <mhroncok> have a hard deadline to have it testable
15:04:22 <jforbes> that they commit and build
15:04:27 <contyk> +1 to f31, +0 to f30
15:04:45 <bowlofeggs> .hello2
15:04:47 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:05:10 <zbyszek> https://koji.fedoraproject.org/koji/packageinfo?packageID=30 shows no 5.0 builds even in rawhide...
15:05:17 <mhroncok> exactly my worry
15:05:27 <jforbes> Well, we haven't offically approved it for F31, so no rawhide makes sense
15:06:07 <zbyszek> But https://src.fedoraproject.org/rpms/mono/commits/master shows commits to bootrap the 5.0 build.
15:06:08 <jforbes> I wouldn't ask for approval for something and then commit it anyway before that approval is given, it's bad form
15:06:35 <mhroncok> we approved it for f31
15:07:06 <zbyszek> But did we announce it as such? I don't see that anywhere.
15:07:18 <mhroncok> no we haven't
15:07:20 <jforbes> I did not see it either
15:07:54 <zbyszek> OK, so what about 1. announce approval for F31, 2. ask for F30 builds to be done until the end of this week, or skipped altogether?
15:08:22 <mhroncok> +1
15:08:36 <bowlofeggs> zbyszek: bcotton announced it as approved for F31
15:08:46 <bowlofeggs> https://pagure.io/fesco/issue/2105#comment-561929
15:09:16 <mhroncok> bowlofeggs: that is not an announcement IMHO, we e-mail such things to devel
15:09:23 <bowlofeggs> zbyszek: +1 though - we could re-announce it ☺
15:09:28 <bowlofeggs> mhroncok: fair
15:09:38 <jforbes> Yes, but that is the same as other bcotton handwavy approvals in ticket, that aren't always valid
15:10:13 <mhroncok> (aka this is approved but pending announcement for f31)
15:10:28 <mhroncok> so, still +1 to what zbyszek proposed
15:10:28 * nirik arrives late
15:10:39 <contyk> yeah, me too
15:10:41 <contyk> +1
15:10:57 <bcotton> i'm following the published FESCo policy. if y'all want me to handle these differently, let me know
15:11:34 <nirik> +1 to zbyszek's proposal
15:11:56 <jforbes> bcotton: I wasn't disagreeing, just saying comments in ticket aren't the same as an announcement
15:11:57 <zbyszek> bcotton: it'd help if you set the "pending announcement" flag on the tickets.
15:12:05 <bookwar> zbyszek: end of week = friday?
15:12:15 <zbyszek> bookwar: 31st March, Sunday
15:12:20 <bookwar> ok :)
15:12:31 <bcotton> zbyszek: i don't think i have permission to do that. would be happy to if you set the metadata to be editable or add me as admin
15:12:43 <bcotton> s/admin/whatever role/ :-)
15:12:55 * zbyszek doesn't know if the change owners are of the work-on-weekend or not variety
15:13:07 <nirik> just should need ticket for that.
15:13:15 <bookwar> zbyszek: +1 from me, let's review next monday, if builds are available and no criticals found - go for it in f30
15:14:07 <zbyszek> OK, so we're at +5 incl. me, anyone else?
15:14:30 <jforbes> I think my +1 in ticket for f30 and f31 would cover it
15:14:39 <otaylor> +1
15:15:01 <zbyszek> jforbes: yeah, but now we're setting a specific cut-off date...
15:15:09 <zbyszek> I'll count you as +1 :)
15:15:10 <jforbes> okay...
15:15:33 <zbyszek> #agreed The Change is approved for F31. It is also approved for F30, as long as the builds can be done and submitted as an update no later than March 31. If this isn't possible, F30 should keep the previous version. (+7, 0, 0)
15:15:44 <zbyszek> #topic #2104 Delay retiring of java-packages moved to module until a solution for the (Build)Requires has been found
15:15:47 <zbyszek> .fesco 2104
15:15:49 <zodbot> zbyszek: Issue #2104: Delay retiring of java-packages moved to module until a solution for the (Build)Requires has been found - fesco - Pagure.io - https://pagure.io/fesco/issue/2104
15:15:50 <zbyszek> https://pagure.io/fesco/issue/2104
15:16:30 <jforbes> Did that meeting happen?
15:17:30 <contyk> the buildroot one? yes
15:17:46 <contyk> we agreed that the proposed solution is the way forward
15:17:47 <bowlofeggs> yeah, but i got the impression that the solution might not be quick
15:17:56 <contyk> yeah
15:17:59 <bowlofeggs> contyk: would you agree that it might be a while
15:18:02 <bowlofeggs> hah yeah
15:18:18 <mhroncok> anything more concrete?
15:18:23 <jforbes> define "a while"
15:18:40 <contyk> probably before f31
15:18:55 * nirik hates giving estimates... especially when it's other teams doing the work.
15:19:02 <bowlofeggs> jforbes: i don't think anyone made a formal estimate, but yeah it sounded like july/august might be a vague guess
15:19:14 <jforbes> Oh, that is reasonable.
15:19:24 <nirik> there is a stewardship sig now... but not sure how active they are.
15:19:34 <zbyszek> nirik: 4 members, 2 packages
15:19:40 <jforbes> nirik: I wasn't looking for a firm deadline, just a rough idea.  Looking at 6 months, 6 years?
15:20:03 <jforbes> nirik: they have to be more active than the i686 sig
15:20:10 <nirik> zbyszek: cool... note that it just got created so it will be interesting to see if it grows or not
15:20:16 <bowlofeggs> jforbes: let's say def not shorter than 2 months, and maybe not longer than 1 year ☺
15:20:34 <contyk> that sounds about right!
15:20:44 <nirik> so what do we want to do here? delay retirement until we have a solution?
15:20:55 <mhroncok> I'm not sure delaying the retirement for maybe not longer than 1 year is a reasonable thing to do
15:21:17 <contyk> we still need someone to fix the packages if they're not sufficiently working
15:21:19 <bowlofeggs> we could ask for a more thorough estimate before deciding?
15:21:21 <nirik> I really don't think it will take that long...
15:21:22 <contyk> or in case of security issues
15:21:30 <mhroncok> also note that one package that I took (and added the stewardship sig) has no stream branch, so i guess not all orphaned packages in this batch are even in a module
15:21:30 <bowlofeggs> the estimate in the meeting was very hand wavy
15:22:02 <jforbes> security issues is the only real concern I have.
15:22:24 <nirik> do we even have a list of the not taken packages?
15:22:36 <jforbes> Other bugs, it would be nice if they were fixed, but not critical if they aren't
15:22:38 <contyk> well, they need to work well enough to be usable
15:22:42 <contyk> otherwise we don't need them
15:22:57 <bowlofeggs> jforbes: build issues can complicate fixing security issues, so i also care about those
15:23:13 <bowlofeggs> i.e., if there's a FTBFS and then a CVE comes along, that will delay the CVE fix
15:23:18 <mhroncok> nirik: I've posted in the ticket
15:23:25 <mhroncok> nirik: the list
15:23:26 <nirik> mhroncok: cool. thanks
15:23:42 <mhroncok> problem with my list is that I have no ide ahow toc heck if those are available in some module
15:23:46 <jforbes> contyk: I am going under the (perhaps mistaken) assumption that they worked well enough for now, and aren't expected to change with no one maintaining them
15:23:49 <mhroncok> I don' thinkt hat all of them are
15:23:49 <zbyszek> mhroncok: which ticket?
15:23:54 <mhroncok> delaying ticket
15:24:08 <mhroncok> https://pagure.io/fesco/issue/2104#comment-560255
15:24:33 <jforbes> yeah, it's not a short list
15:24:36 <mhroncok> it's 11 days old data, I've just removed 2 packages that i took
15:25:04 <mhroncok> sgallagh, contyk: how do I filter those available in a module?
15:25:18 <nirik> shall we ask the stewardship sig if they would be willing to take them all until we can move to the module versions?
15:25:35 <jforbes> nirik: that would be a great solution if they are willing
15:25:46 <zbyszek> nirik, jforbes: exactly
15:25:51 <mhroncok> nirik: I don't think a group can actually take packages, so so far I treated it like this: I take what I care about but I also add the sig
15:26:01 <mhroncok> and I'm not taking all of this, sorry
15:26:43 <jforbes> mhroncok: A group can take bugzilla notifications at least
15:27:16 <mhroncok> jforbes: yes, but I still not taking all of this
15:27:50 <zbyszek> OK, so any proposal to vote on?
15:27:53 <jforbes> Are you the only member of the sig?
15:27:54 <bookwar> do we have a list from libreoffice and dogtag and freeipa? what are _their_ requirements?
15:28:10 <jforbes> that would be more of a sii
15:28:43 <mhroncok> jforbes: no, I'm 25 % of the sig (ATM). I'm not even taking 25 % of this. yes, we can ask other members if they are
15:28:52 <nirik> I don't think we have such a list, no. ;(
15:29:13 <mhroncok> apparently maintainers of libreoffice freeipa and dogtag either don't care or have a backup plan
15:29:24 <mhroncok> I've heard freeipa might go into a module
15:29:34 <bookwar> this list lacks the reason why the package needs to be saved for each package, and it makes it harder
15:29:44 <nirik> proposal: ask stewardship sig if they would take this list until modular builds can be used in the buildroot, don't retire any packages until next week.
15:29:54 <jforbes> So my proposal would be to ask the sig if they are willing to at least cover security issues for the list. If so, I would not be opposed to delay retiring the packages until we move to module versions.
15:30:38 <zbyszek> I don't think the group will take the whole list. Probably just select packages.
15:30:49 <mhroncok> yet we still need to figure out what of those packages are actually in modules
15:31:02 <mhroncok> zbyszek: that was my plan in the group
15:31:20 <nirik> we don't even know which are important or not.
15:31:51 <mhroncok> exactly
15:32:03 <bowlofeggs> it sounds like there's a lot we don't know :/
15:32:08 <mhroncok> delaying retirement of the entire group is not a good idea
15:32:16 <mhroncok> it would set a bad precedence
15:32:17 <jforbes> Ugh, sorry, I have to step out, just got a call from the school that a kid is sick and I have to pick them up, I should be back
15:32:20 * contyk got distracted
15:32:33 <zbyszek> jforbes: no worries
15:32:34 <contyk> mhroncok: that depends on whether that modules is composed or not
15:32:44 <contyk> *module
15:32:51 <jforbes> mhroncok: I agree, I am not for delaying the retirement of anything where someone has not at least agreed to handle CVEs
15:33:11 <zbyszek> proposal: ask the SIG to take as many packages as possible, and other maintainers too, and retire according to schedule starting April 1st.
15:33:19 <mhroncok> contyk: the question is whether the packages will be available in the buildroot once the solution is ready
15:33:31 <bowlofeggs> zbyszek: +1
15:34:14 <zbyszek> (I'll join the SIG too, there's a few java packages that I need to stay around. I think my maintainership will be abysmal though.)
15:34:16 <bookwar> announce that orphan packages _will be retired_, but if you heavily depend on smth, you must reach out to SIG and convince it to take care of your package
15:34:30 <mhroncok> zbyszek: to be clear, that is basically "no exception happens" (except we agree taht we ask for help), right?
15:34:48 <nirik> zbyszek: +1
15:34:58 * nirik should join too. I can at least try and fix cve's...
15:35:00 <zbyszek> mhroncok: pretty much, yes. We're actually delaying a bit, since you said that some of those packages would be retired today.
15:35:03 <mhroncok> bookwar: the preferred thing to do si to maintain the package
15:35:09 <mhroncok> not convince the sig to do it
15:35:23 <bookwar> mhroncok: we already tried that
15:35:36 <mhroncok> bookwar: and we should continue to do so
15:35:46 <bookwar> announce that orphan packages _will be retired_, but if you heavily depend on smth, take ownership or reach out to SIG and convince it to take care of your package
15:36:11 <mhroncok> anyway, zbyszek +1
15:36:40 * mhroncok runs the "orphaned packages to be retired" script now, but it takes ages
15:37:03 <mhroncok> (to be clear: the script does not retire stuff)
15:37:18 <bookwar> mhroncok: i'd like to encourage people to  at least clarify the dependencies and impact. Not like "Dogtag depends on some of those, don't retire", but "Dear SIG, please take care of this one particular package i really need"
15:37:37 <zbyszek> bookwar: the announcement email has those details
15:37:59 <zbyszek> Are you asking for even more detail?
15:39:11 <bookwar> i'd like people to actively take one package they care about and hand it over to SIG, per package, personally, not sure about the wording though
15:39:35 <zbyszek> otaylor, contyk?
15:40:13 <bookwar> so Libreoffice comes and say: this is needed for bookmarks to function, this is needed fo sync with macos devices, and this is smth basic i need for everything. And SIG says - disable MacOS and tell us your plans on other two
15:40:15 <otaylor> zbyszek: +1 I guess
15:40:20 <contyk> +1
15:40:25 <contyk> but not sure if that will change anything
15:40:38 <zbyszek> bookwar: what you are asking for is a _lot_ of work.
15:41:19 <mhroncok> contyk: I'm quite sure it won't
15:41:38 <mhroncok> so this remains a large problem
15:41:45 <bookwar> that's why i was thinking that crowdsourcing this task is better then chasing who depends on what by SIG alone
15:42:18 <zbyszek> We've been at this for 20+ minutes...
15:42:22 <zbyszek> bookwar: yay or nay?
15:42:34 <bookwar> +1, it is all about wording anyway
15:42:42 <nirik> well, those maintainers have not done anything... I suppose we could reach out and ask them directly...
15:42:51 <zbyszek> #agreed FESCo asks the Stewardship SIG and other maintainers to take as many packages as possible. Packages which haven't found new owners will be retired according to schedule, but not earlier than April 1st. (+7, 0, 0)
15:43:03 <zbyszek> #topic #2102 F31 System-Wide Change: Gating Rawhide — Single package updates
15:43:06 <zbyszek> .fesco 2102
15:43:08 <zodbot> zbyszek: Issue #2102: F31 System-Wide Change: Gating Rawhide — Single package updates - fesco - Pagure.io - https://pagure.io/fesco/issue/2102
15:43:09 <zbyszek> https://pagure.io/fesco/issue/2102
15:43:30 <nirik> Is someone going to mail the sig about the last topic?
15:43:51 <mhroncok> afaik this is till being drafted and should be put back to inclomplte
15:43:57 <mhroncok> incomplete
15:44:03 <nirik> pingou: is this ready for discussion yet?
15:44:21 <contyk> re:previous topic; people will think it's a joke when retire them on that date ;)
15:44:52 <zbyszek> bookwar: can you draft the e-mail to the SIG and maintainers? You had some specific concerns...
15:45:02 <bookwar> zbyszek: will do
15:45:35 <zbyszek> #action bookwar to write an e-mail to the Stewardship SIG and other maintainers
15:45:53 <zbyszek> Hmm, did I do this right? Or does it need to start with .?
15:46:05 <mhroncok> zbyszek: imho good
15:46:43 <zbyszek> mhroncok: I think yes, it seems that there has been no movement on the topic since two weeks ago.
15:46:56 <zbyszek> Should we just move to the next topic?
15:47:08 <contyk> yes
15:47:15 <zbyszek> #topic #2027 RFC: Module lifecycles
15:47:15 <zbyszek> .fesco 2027
15:47:15 <zbyszek> https://pagure.io/fesco/issue/2027
15:47:17 <zodbot> zbyszek: Issue #2027: RFC: Module lifecycles - fesco - Pagure.io - https://pagure.io/fesco/issue/2027
15:48:05 <zbyszek> sgallagh is not here unfortunately
15:48:21 <contyk> asamalik?
15:49:27 <contyk> if neither is around, zbyszek, could you respond to sgallagh's last comment in the ticket?
15:49:36 <contyk> I think there's nothing more to do today
15:50:01 <zbyszek> OK, let's assume that people are busy with F30 beta, and things will pick up next week ;)
15:50:24 <zbyszek> #topic #2109 Policy revamp: Package Removal for Long-standing FTBFS and FTI bugs
15:50:27 <zbyszek> .fesco 2109
15:50:30 <zbyszek> https://pagure.io/fesco/issue/2109
15:50:31 <zodbot> zbyszek: Issue #2109: Policy revamp: Package Removal for Long-standing FTBFS and FTI bugs - fesco - Pagure.io - https://pagure.io/fesco/issue/2109
15:50:42 <mhroncok> there has been some feedback
15:51:06 <mhroncok> I'd like to change the proposal based on that feedback
15:51:15 * nirik nods
15:51:32 <mhroncok> but I don't want to redo that once again when somebody says the changes are not good
15:51:56 <mhroncok> I'd like to know if what others suggested is good for more people than those who suggested it
15:51:57 <asamalik> contyk: in a meeting, free in 5-10 mins
15:52:39 <zbyszek> OK. So for one "F30_fails_to_install" is a lot to type. But I can live with it.
15:52:51 <nirik> mhroncok: could post to devel for more feedback. :)
15:53:18 <mhroncok> zbyszek: I don't consider the tracker name important for the proposal, taht can be sorted out later
15:53:58 <mhroncok> nirik: I was thinking more fesco feedback, and once we have a proposal that sounds liek soemthign we want we ask for genereal feedback
15:53:59 <zbyszek> There's bowlofeggs's https://pagure.io/fesco/issue/2109#comment-561471, anything else?
15:54:32 <mhroncok> otherwise we might have a lot of bikeshedding (like the tracker name :D)
15:54:38 <nirik> should know by next week if bz needinfo sends reminders. :)
15:54:38 * mhroncok scands the ticket
15:55:06 <zbyszek> FWIW, all the suggestions seemed reasonable to me.
15:55:19 <zbyszek> (More like tweaks really.)
15:55:46 <mhroncok> ok,s o bascially I'd like to reduce the bumping as long as buzgilla sends weekly reminders
15:56:14 <bowlofeggs> nirik: historically it does, but i'm not sure how often (never seemed that often)
15:56:18 <mhroncok> and add a requirement to send an e-mail to the -maintainers address in second week or such
15:56:36 <nirik> bowlofeggs: I thought it was weekly, but I try and clear needinfos pretty often usually.
15:57:04 <bowlofeggs> nirik: i was bad and didn't clear one for a long time once haha
15:57:19 <bowlofeggs> my memory about it is hazy though
15:57:30 <mhroncok> naughty bowlofeggs, no Christmas presents
15:57:34 <bowlofeggs> haha
15:57:51 <mhroncok> ok, next ticket
15:57:55 <zbyszek> So I think I can answer the question about need-info reminders, negatively.
15:58:09 <nirik> it no longer sends reminders? ;( bummer
15:58:21 <zbyszek> I have a ticket with needinfo since Sept 26 last year, and the last e-mail I got on the subject was in November.
15:58:37 <nirik> oh well.
15:58:45 <mhroncok> let's open a metabugzilla?
15:58:56 <zbyszek> There used to be separate "you have needinfo" e-mails, but I haven't gotten one in a while.
15:59:20 <zbyszek> Anyway, mhroncok can you update the proposal and we'll vote in the ticket?
16:00:13 <zbyszek> #action mhroncok to update the proposal
16:00:14 * nirik can ask bz admins/we can file a bug on bugzilla to ask
16:00:15 <zbyszek> #topic #2110 F31 System-Wide Change: Enable Compiler Security hardening flags by default in GCC
16:00:18 <zbyszek> .fesco 2110
16:00:24 <zodbot> zbyszek: Issue #2110: F31 System-Wide Change: Enable Compiler Security hardening flags by default in GCC - fesco - Pagure.io - https://pagure.io/fesco/issue/2110
16:00:24 <zbyszek> https://pagure.io/fesco/issue/2110
16:00:29 <zbyszek> So the outlook on this one was very negative.
16:00:39 <zbyszek> Can we do a quick vote to reject it?
16:01:12 <otaylor> -1 for me certainly
16:01:13 <mhroncok> zbyszek: yes, sure
16:01:19 <zbyszek> -1 ftr
16:01:22 * mhroncok was disctracted
16:01:24 <nirik> -1 from me
16:01:26 <zbyszek> jforbes was -1 in the ticket
16:01:37 <zbyszek> mhroncok was -1 in the ticket
16:01:37 * mhroncok was -1 in the ticket as well
16:01:48 <zbyszek> -1 ftr
16:01:56 <bookwar> -1 from me too, forgot to add to the ticket
16:02:14 <bowlofeggs> -1
16:02:19 <asamalik> contyk: I'm back
16:02:27 <zbyszek> #agreed: proposal is rejected (0, 0, -7)
16:03:01 <zbyszek> asamalik: let me get to the end of the agenda, I think we only have a few quick ones now, and we'll circle back to you
16:03:10 <zbyszek> #topic #2108 Change release blocking deliverables process
16:03:10 <zbyszek> .fesco 2108
16:03:10 <zbyszek> https://pagure.io/fesco/issue/2108
16:03:15 <zodbot> zbyszek: Issue #2108: Change release blocking deliverables process - fesco - Pagure.io - https://pagure.io/fesco/issue/2108
16:03:28 <asamalik> zbyszek: thanks
16:04:55 * mhroncok was +1 in the ticket
16:05:00 * nirik was ok with it
16:05:11 <bowlofeggs> +1
16:05:36 <otaylor> +1
16:06:01 <bookwar> +1 in the ticket
16:06:10 <zbyszek> #agreed Proposed change to the process is approved (+6, 0, 0)
16:06:21 <zbyszek> #topic Next week's chair
16:06:21 <zbyszek> #action NAME will chair next meeting
16:06:31 <zbyszek> Any takers?
16:06:42 <mhroncok> thanks NAME
16:06:51 <bcotton> NAME++
16:06:51 * mhroncok looks to calendar
16:06:54 <bowlofeggs> i haven't in a while
16:07:13 <zbyszek> thanks
16:07:24 <zbyszek> #action bowlofeggs of chair next meeting
16:07:24 <mhroncok> I think sgallagh already said he will do it
16:07:31 <zbyszek> #undo
16:07:31 <zodbot> Removing item from minutes: ACTION by zbyszek at 16:07:24 : bowlofeggs of chair next meeting
16:07:36 <mhroncok> let me check
16:07:46 <bowlofeggs> either way is fine with me
16:08:01 <mhroncok> 16:22:40 <sgallagh> I'll be on PTO next Monday, but as I haven't done it in a while, I'll pick up April 1
16:08:01 <mhroncok> 16:22:50 <sgallagh> (no joke)
16:08:29 <bowlofeggs> cool
16:08:31 <bowlofeggs> +1
16:08:35 <zbyszek> #action sgallagh to chair next meeting
16:09:09 <zbyszek> So, let's circle back to the prievious topic quickly
16:09:28 <zbyszek> #topic #2027 RFC: Module lifecycles
16:09:28 <zbyszek> .fesco 2027
16:09:28 <zbyszek> https://pagure.io/fesco/issue/2027
16:09:30 <zodbot> zbyszek: Issue #2027: RFC: Module lifecycles - fesco - Pagure.io - https://pagure.io/fesco/issue/2027
16:09:46 <zbyszek> asamalik^
16:10:40 <zbyszek> otaylor: thank you for the comment. This summarizes my concerns as well.
16:10:50 <asamalik> so I was wondering how could we move this forward?
16:11:40 <asamalik> sgallagh has updated the proposal so it lists requirements instead of specific implementation
16:12:00 <mhroncok> propose a solution that has no (or very little) releng tickets in it?
16:12:11 <mhroncok> oh, when?
16:12:39 <mhroncok> This information MUST be stored persistently and made available via a stable, published API at a well-known web address.
16:13:21 <zbyszek> Also, "Some possible examples (non-exhaustive):". I'd prefer to vote on a specific solution.
16:13:27 <mhroncok> that certainly means it can be stored on https://asamalik.fedorapeople.org/eols.txt
16:13:34 <jforbes> That was discussed previously
16:13:47 <bowlofeggs> i just added a comment to the ticket, but to state here too: just an fyi that there is debate about whether FPDC will happen or not, so its future is uncertain. CC cverna
16:14:22 * nirik notes there's work involved no matter where we store it. tools that need to exist/be updated, etc.
16:14:22 * cverna reads
16:14:31 <jforbes> We asked for not a specific implementation detail, but a list of requirements
16:14:45 <zbyszek> We had very similar discussion in the "dynamic BRs" ticket, and we asked for a concrete proposal, not just a general idea.
16:14:56 <asamalik> does FESCo need to vote on a specific implementation detail? I thought that the Modularity Team was responsible for the implementation
16:15:00 <mhroncok> can we have this: the maintainer can update the information at any time, automatically, without releng or any other human involvement.
16:15:10 <asamalik> this is more about the higher-level requirements around that
16:15:10 <bowlofeggs> mhroncok: +1
16:15:21 <zbyszek> mhroncok: +1
16:15:32 <bowlofeggs> we are bottlenecking releng too much ever since pkgdb went away
16:15:32 <asamalik> and it's now taking weeks to make any progress :(
16:15:36 <nirik> is that really fair?
16:15:56 <mhroncok> the requirement? or bottlenecking releng?
16:16:29 <nirik> "I woke up this morning and decided to EOL this module, too bad about no warning" but I suppose it has to be on a boundry according to the rest of the proposal...
16:16:58 <bowlofeggs> nirik: yeah we might be able to have some tooling to ensure it meets the requiremnts
16:17:08 <bowlofeggs> nirik: but i'd rather not have to saddle releng humans with that task
16:17:17 <mhroncok> I'm ok if there are warnings somewhere and rules checker
16:17:25 <nirik> but I guess I can agree to that requirement and details can handle sanity checking it.
16:17:26 <mhroncok> bowlofeggs: that's what i meant
16:17:37 <zbyszek> nirik: but this is possible today with any package, and somehow it's not such a big problem (usually)
16:17:52 <bowlofeggs> nirik: but only on rawhide right?
16:17:54 <asamalik> I'm quite confused... where does the proposal mentions releng tickets?
16:18:03 <mhroncok> the maintainer can update the information at any time, automatically, without releng or any other human involvement, assuming the update is valid based on this policy
16:18:30 <bowlofeggs> asamalik: i'm not sure it does, but we want to put a requirement that any solution doesn't involve releng tickets
16:18:31 <nirik> zbyszek: well, somewhat I suppose...
16:18:44 <nirik> mhroncok: +1
16:18:49 <mhroncok> asamalik: it doesn't but the requirements for the tool allow solutions that do this
16:18:49 <bowlofeggs> mhroncok: +1
16:18:51 <zbyszek> mhroncok: still +1
16:18:56 <asamalik> bowlofeggs: fair enough
16:19:01 <asamalik> mhroncok: that sounds fair
16:19:09 <jforbes> +1 then
16:19:12 <mhroncok> asamalik: thanks
16:19:19 <asamalik> if I add mhroncok's requirement, are we good to go?
16:19:19 <otaylor> mhroncok: +1
16:19:25 <mhroncok> zbyszek: was this the only thing? can we allow them to move this forward?
16:19:26 * asamalik really doesn't want to wait another week :(
16:19:48 <zbyszek> I'm fine with the added requirement.
16:20:24 <mhroncok> proposal: policy is approved with that requirement added
16:20:29 <bowlofeggs> mhroncok: +1
16:20:31 <zbyszek> mhroncok: +1
16:20:32 <nirik> +1
16:20:34 <otaylor> mhroncok: +1
16:20:41 <jforbes> +1
16:20:50 <mhroncok> asamalik: \o/
16:20:58 <asamalik> \o/
16:21:18 <zbyszek> #agreed The proposal is approved with the additional requirement that the maintainer can update the information at any time, automatically, without releng or any other human involvement, assuming the update is valid based on policy (+6, 0, 0)
16:21:22 <mhroncok> asamalik: sorry for stalling this for too long
16:21:26 <asamalik> thanks everyone!
16:21:42 <zbyszek> Thanks asamalik
16:21:44 <zbyszek> #topic Open floor
16:22:03 * cverna has a quick one for open floor
16:22:09 <zbyszek> cverna: the floor is yours
16:22:45 <cverna> I started to work on the implementation of https://pagure.io/fesco/issue/2048 (Bodhi automated push to stable based on time in testing)
16:22:50 <mhroncok> zbyszek: I also ahve something, will wait for cverna so we don't mix topics
16:22:57 <asamalik> mhroncok: no worries, I'm happy we've moved this forward in a way that FESCo supports, that's important
16:23:08 <cverna> I would like to consider the possibility to implement this change in 2 phase
16:23:12 <mhroncok> asamalik++
16:23:46 <mhroncok> cverna: generally that should be OK, what is in phase 1?
16:23:53 <cverna> phase 1 needed for rawhide gating --> automated push to stable when the update reach the mandatory days to testing, packager can just opt-in our opt-out
16:24:16 <mhroncok> cverna: I'm Ok with that if -1 karma stops that
16:24:19 <cverna> phase 2:  packager can extend the length of time required (not needed for rawhide gating)
16:24:32 <cverna> yes karma has priority
16:24:37 <bowlofeggs> cverna: note that our management chain wants this to default to opt-out, not opt-in
16:24:49 <cverna> yes that's fine too
16:24:54 <jforbes> I don't think that is a problem
16:25:04 <bowlofeggs> well i wouldn't want to allow the two stage with an opt-out default
16:25:32 <bowlofeggs> and changing the default will require an X release
16:25:33 * nirik is fine with that 2 phase approach
16:26:13 <cverna> so by default the boolean would be False to be clear
16:26:24 <bowlofeggs> cverna: that's against the wishes our our mgmt
16:26:26 <cverna> in phase 1 and True in phase 2 ?
16:26:40 <bowlofeggs> cverna: we can only do that if we do another X release
16:26:53 <cverna> ok
16:27:04 <cverna> let's do another X release then
16:27:08 <bowlofeggs> cverna: as fesco i don't mind that, but as bodhi maintainer i don't like it
16:27:37 <mhroncok> bowlofeggs: what was the original plan for defaults? is your last ticket up  to date?
16:27:48 <mhroncok> lastest ticket comment
16:27:56 <cverna> ok so we can discuss the bodhi specific once we have agreement from fesco with the 2 phase approach
16:28:09 <bowlofeggs> mhroncok: the original plan aiui was to have it default to on, but allow opt-out. i haven't verified my memory of that against the ticket
16:28:19 <bowlofeggs> cverna: sure
16:28:57 <jforbes> I remember requiring that we could opt out, because it was otherwise problematic for kernel
16:29:04 <bowlofeggs> the reason i filed that fesco ticket was because my mgmt wanted updates to flow more automatically, hence that default
16:29:10 <cverna> Can we agree that we can consider a 2 phase approach, and then we will discuss the specific within the bodhi project ?
16:29:11 <bowlofeggs> jforbes: yeah opt out is def a requirement
16:29:28 <bowlofeggs> cverna: +1
16:29:31 <zbyszek> cverna: +1
16:29:34 <mhroncok> cverna: +1
16:29:54 <nirik> +1
16:30:06 <jforbes> +1
16:30:12 <cverna> that's all from then, thanks all :)
16:30:25 <zbyszek> #agreed Two-phase approach for #2048 is approved (+5, 0, 0)
16:30:50 <zbyszek> So, mhroncok, you had something?
16:30:53 <mhroncok> yes
16:31:23 <mhroncok> what can we, as fesco, do to prevent future fuckups as the java packages orphaning?
16:31:47 <mhroncok> I feel like we did nothing to help here (I feel like asking the sig is not a real action)
16:32:09 <mhroncok> if we have more packagers saying "I don't care about rawhide, let's move to modules" it will hurt the project
16:32:14 <zbyszek> Well, we can try to avoid bottlenecks and single-person points of failure
16:32:16 <nirik> well, it's not like we can hire a bunch of java developers... not sure there's too much more we can do?
16:32:34 <bowlofeggs> mhroncok: yeah i've thought about this a lot and sadly i don't have an answer :(
16:32:39 <jforbes> mhroncok: I think it really comes down to looking at longer term consequences for decisions we make. Most of the things we have been hitting lately which are difficult to solve are the direct result of us approving something a year or two ago
16:33:24 <bowlofeggs> jforbes: agreed - we didn't anticipate this happening when we approved modularity
16:33:35 <zbyszek> I need to run *now*, sorry.
16:33:40 <jforbes> Yeah, kill pkgdb, sounds like a great idea.  Only a portion of the utility was replaced with something new, and it has come back to bite us. Modularity, same thing
16:33:47 <bookwar> do you think it smth specific to modularity? or just generic: what if no one maintains a middle layer?
16:33:51 <zbyszek> Could wrap up the meeting?
16:33:56 <bowlofeggs> though not sure how i personally would have - it didn't occur to me that build deps could get weird
16:34:01 <zbyszek> I mean once the discussion is done...
16:34:05 <jforbes> sure
16:34:14 <zbyszek> jforbes: thanks
16:34:20 <bowlofeggs> thanks zbyszek!
16:34:38 <bowlofeggs> i do think this is important though mhroncok
16:34:54 <bowlofeggs> it can't be helping our contributor graph that mattdm likes to show
16:35:03 <mhroncok> can we somehow "make" the people working on "new stuff" stop for a while and clean the mess?
16:35:11 <mhroncok> I know that this is not possible, hence ""
16:35:12 <bowlofeggs> fedora is more painful to contribute to now than it was a few years ago for sure
16:35:31 <mhroncok> but I mean, most of the people work for the same company, this needs to be possible somehow
16:35:33 <jforbes> bowlofeggs: I think that is just the issue though. We look at proposals, and sure it looks good, but larger sweeping proposals I think we really need to spend time on.
16:36:14 <bowlofeggs> jforbes: yeah, i wish i had thought it through more for sure
16:36:15 <bookwar> mhroncok: what is the "new" thing you'd like to drop?
16:36:28 <mhroncok> I'm not suggesting to drop anything
16:36:51 <bowlofeggs> mhroncok: here's an idea - could we make a proposal to our primary sponsor to address the issues we see?
16:36:59 <mhroncok> I just thing that we, as FESCo are somewhat repsonsible for the current state of things
16:37:01 <nirik> I think there's also a press to move more quickly, etc... which sometimes mean less planning
16:37:11 <jforbes> mhroncok: That is exactly one of the things that annoys me with this hard line on releng added work. I absolutely agree, we don't need to allow things that increase their workload, but the flip side of that is we wouldn't have to if we hadn't allowed other changes to go in prematurely.  We have put contributors in a very unhealthy situation
16:37:20 <mhroncok> and if we don't stop and go back to fix stuff, Fedora will break, as a project
16:37:53 <bowlofeggs> i think we have crossed the breaking point line now with the java stuff :/
16:38:09 <bowlofeggs> i.e., not *will* break, but *has* broken
16:38:11 <mhroncok> and I was hoping to geta  delay and a wuick fix
16:38:12 <jforbes> (note, I am not saying we shouldn't keep the hard line, that is just deferring the debt)
16:38:35 * mhroncok cannot type anymore, sorry
16:38:44 <bowlofeggs> heh
16:38:49 <nirik> yeah, there's a lot of tech debt (some of our own deliberate making)
16:38:51 <mhroncok> yet there will be no qucik fix, no dealyed retirement, we simple agreed to break it
16:39:07 <jforbes> I am just annoyed that these are problems we caused.   I don't think there is a quick fix, but I do think we need to be understanding that people are frustrated.
16:40:06 <bowlofeggs> maybe we need a council objective to get us to a good place again
16:40:12 <jforbes> The fix there is go back to the original change that allowed it, and say, nope this isn't working, delayed until it is
16:40:26 <jforbes> back out
16:40:39 <bookwar> from modularity?
16:40:42 <bowlofeggs> jforbes: at this point, that might break things just as much though, right?
16:40:50 <bowlofeggs> just break differently?
16:40:56 <mhroncok> It is too late for that
16:40:56 <nirik> well, one of the recent objectives asked if we should skip f31 and use the time to fix things...
16:40:58 <jforbes> bowlofeggs: I was laughing as I typed it, that isn't feasible yet either
16:41:02 <bowlofeggs> haha
16:41:28 <mhroncok> nirik: not sure if I udnertood this in that way
16:41:51 <mhroncok> it was about the compose, wasn't it? and the large pushback was "we don't think delaying is needed to fix stuff"
16:41:59 <jforbes> Though I suppose we could say that you can't orphan the packages to begin with until a solution is found, but it would just mean they are not maintained unofficially anyay
16:42:06 <mhroncok> why donẗ we just stop creating new things for a while?
16:42:26 <bookwar> nirik: but delaying release is not an action it just provides a place, and there were no action plan, what do you want to do
16:42:30 <jforbes> mhroncok: better yet, just stop halfway creating new things
16:42:38 <bookwar> mhroncok: stop doing things is also not an action )
16:42:39 <mhroncok> should we put engineering time in stuff like rawhide gating or stuff like "unbreak everything"?
16:42:44 <nirik> sure.
16:43:07 <bookwar> mhroncok: define unbreak everything
16:43:14 <nirik> well, like most things: write up a list of all broken things, prioritize.
16:43:18 <jforbes> mhroncok: absolutely both. But unbreak seems a priority
16:43:30 <mhroncok> I don't define it ona meeting, that's part of the actual work
16:43:39 <mhroncok> jforbes: exactly
16:43:43 <bookwar> mhroncok: and gating will be part of the solution
16:43:54 <mhroncok> bookwar: no it won't
16:44:09 <bookwar> mhroncok: i am open to argue about it
16:44:14 <nirik> well, is this also part of: https://fedoraproject.org/wiki/Objectives/Packager_Experience ?
16:44:33 <jforbes> gating is a solution to some things, we have a large list of issues at the moment actually
16:44:38 <mhroncok> nirik: is that actually happening? https://fedoraproject.org/w/index.php?title=Objectives/Packager_Experience&action=history
16:45:05 <nirik> it's not a approved current objective no...
16:45:19 <nirik> I don't have any idea what stage it's in for council consideration
16:45:59 <bowlofeggs> i think gating is good, but a different topic than the problems we've gained due to the loss of pkgdb and retirement of java stuff, etc.
16:46:16 * mhroncok thing gating is awesome
16:46:18 <mhroncok> thinks
16:46:30 <mhroncok> gating not being good is certainly not my point
16:46:44 <bowlofeggs> oh i didn't think you were saying it wasn't good
16:46:51 <mhroncok> (it was an example of a large thing that RH paid people are working on)
16:46:53 <bowlofeggs> i meant more that it think it's unrelated to the discussion
16:46:58 <bowlofeggs> oh yeah
16:47:00 <bowlofeggs> ok
16:47:06 <bookwar> mhroncok: my point is - we need to do new stuff to unbreak old stuff, just saying "stop" doesn't work
16:47:19 <otaylor> I think we are not end-to-end enough in the planning - we plan big adds of functionality, we get 90% there, we accumulate the 10% (which is actually another 90% of course) as a set of "we should do that", we move back to scrabbling at the backlog, repeat.
16:47:20 <bowlofeggs> mhroncok: so you might argue that we should fix this stuff instead of working on gating?
16:47:40 <bowlofeggs> i.e. shift the resources
16:48:04 <bowlofeggs> otaylor: or, we never do it because a new thing comes along
16:48:07 <mhroncok> bowlofeggs: at this point I'd argue that we should fix this stuff instead of working on anything that isn't on fire
16:48:16 <jforbes> otaylor: agreed, there was a list of "yeah, we want to get to that" which were mentioned when the retire pkgdb was approved. A lot of those fell off the radar, and were not a requirement
16:48:18 <bowlofeggs> the retirement of pkgdb was never finished and now nobody is working on it
16:48:46 <bowlofeggs> and yeah, we as fesco didn't make that a requirement, which we should have
16:49:27 <bowlofeggs> mhroncok: yeah i would personally agree to that, though i'm not sure my mgmt would
16:49:32 <jforbes> There will always be some things that we can't foresee, but we can do a better job on reviewing these big changes too
16:49:45 <bowlofeggs> agreed
16:50:37 <jforbes> bowlofeggs: If we just let current policy stand, drop those java packages and break everything, perhaps management will feel it is worthwile to prioritize a solution?
16:50:40 <mhroncok> bowlofeggs: an I think we should try to work with your mgmt
16:51:01 <otaylor> It's not always so much about being able to foresee and approve the full work ahead, but being able to revisit the overall plan and say "are we there yet"
16:51:03 <bookwar> bowlofeggs: management can't agree on "stop and fix", but every "stop and fix" is actually a "let's do smth"
16:51:16 <bowlofeggs> jforbes: yeah, that might get some attention on the problem
16:51:19 <bookwar> change the presentation
16:51:42 <bowlofeggs> mhroncok: i have talked about this a bit with my mgmt before, but yeah it might help if it's FESCo and not just me
16:51:47 <mhroncok> ultimately, it's our job to list the things that are needed - go back to pkgdb retiremtn, to modularity
16:51:58 <otaylor> mhroncok: I think one of the problems of finishing modularity is that *extra* resources got committed, then pulled off ... for well known reasons
16:52:07 <mhroncok> and figure out the list of things that we consider will unbreak fedora
16:52:25 <bookwar> mhroncok: +
16:52:39 <bowlofeggs> bookwar: yeah, it's more of a proposal to do something instead of something else
16:52:50 <bowlofeggs> or, a request for additional funding so we can do both
16:53:18 <bowlofeggs> otaylor: indeed
16:53:19 <mhroncok> once we have this, we can work with that. aka we can -1  a new big thing and point to this list
16:54:32 <mhroncok> I guess the general sentiment here is more or less the same
16:55:30 <jforbes> otaylor: Yeah, I know how that happened, but it doesn't help our contributors and community.
16:56:04 <mhroncok> so we need to compile such list. any takers? I suppose I should do this since I've started this, but I'd appreciate a partner
16:56:40 <jforbes> mhroncok: I think start a ticket and let everyone contribute
16:56:44 <otaylor> Need to prevent a repeat of that with CI/gating ... which I think largely means being able to tie "finishing" CI to packager experience story - what's the end experience that is compelling to a user, and make clear to all stakeholders that it's not done until we're there
16:56:46 <bookwar> mhroncok: i can help asking questions and nitpicking
16:59:29 <bowlofeggs> otaylor: +1 +1 +1
17:00:09 <mhroncok> I'll open a ticket so this is tracked. it might take me some time to summarize this
17:00:12 <bowlofeggs> mhroncok: i would like to help you with this
17:00:28 <bowlofeggs> mhroncok: maybe you and i could do a call this week and discuss some thoughts?
17:00:31 <mhroncok> bookwar, bowlofeggs: thanks both. I'll ping you later
17:00:38 <mhroncok> bowlofeggs: +1
17:00:39 <bowlofeggs> i think a good start is to make a list of what problems we can think of to solve
17:00:51 <mhroncok> yes
17:01:04 <mhroncok> (time to end the meeting)
17:01:05 <bowlofeggs> i actually did write such a list 6-8 months ago
17:01:09 <bowlofeggs> but no idea where it went
17:01:12 <mhroncok> :D
17:01:12 <bowlofeggs> i can try to find it
17:03:44 <bookwar> who knows how to close the meeting properly? :)
17:03:58 <jforbes> Are we done?
17:04:23 <jforbes> Will give it 1 minute and then close it out
17:05:59 <jforbes> #endmeeting