14:00:24 <decathorpe> #startmeeting FESCo (2020-07-29)
14:00:24 <zodbot> Meeting started Wed Jul 29 14:00:24 2020 UTC.
14:00:24 <zodbot> This meeting is logged and archived in a public location.
14:00:24 <zodbot> The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:24 <zodbot> The meeting name has been set to 'fesco_(2020-07-29)'
14:00:29 <decathorpe> #meetingname fesco
14:00:29 <zodbot> The meeting name has been set to 'fesco'
14:00:31 <zbyszek> .hello2
14:00:33 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
14:00:35 <dcantrell> .hello2
14:00:36 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
14:00:37 <decathorpe> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
14:00:37 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
14:00:52 <decathorpe> #topic Init Process
14:00:53 <sgallagh> .hello2
14:00:54 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:01:10 <nirik> morning.
14:01:14 <nirik> .hello kevin
14:01:15 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
14:02:33 <bcotton> .hello2
14:02:34 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
14:03:42 <King_InuYasha> .hello ngompa
14:03:43 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
14:03:53 <King_InuYasha> hey folks, sorry I'm a bit late
14:04:11 <decathorpe> no problem. with you we have quorum :)
14:04:30 <decathorpe> I'll give the others another minute, then we'll start
14:05:34 <decathorpe> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NHIKO64AWRW72LEOD3LMJ5E6FJT62CED/ Schedule
14:06:01 <decathorpe> #topic #2446 What to do with the 33 packagers/watchers who do not have a valid bugzilla account?
14:06:09 <decathorpe> .fesco 2446
14:06:10 <zodbot> decathorpe: Issue #2446: What to do with the 33 packagers/watchers who do not have a valid bugzilla account? - fesco - Pagure.io - https://pagure.io/fesco/issue/2446
14:06:59 <decathorpe> I commented with a three-pronged proposal: https://pagure.io/fesco/issue/2446#comment-665491
14:07:02 * zbyszek voted for proposal 3 in the ticket
14:07:26 <decathorpe> the voting has started though I'm a bit confused what things were voted on, so I brought it up today
14:08:11 <dcantrell> just read through it, looks reasonable.  added my +1
14:08:18 <sgallagh> zbyszek: I don't think these are contradictory proposals, I think they're one proposal with individual steps
14:08:34 <nirik> I'm in favor of 2 and 3... but not sure I like 1.
14:08:54 <decathorpe> sgallagh: yes. that was my intent. I guess I was not specific enough
14:08:56 <zbyszek> Yeah, same as nirik here
14:09:11 <dcantrell> what's the downside to step 1?
14:09:15 <dcantrell> or part 1?
14:09:24 <nirik> 1 means if someone shows back up in a few weeks they have to ask to be re-added to all the stuff they want to maintain again.
14:09:29 <zbyszek> Exactly.
14:09:38 <mhroncok> hello, sorry for being late
14:09:47 <decathorpe> hi Miro!
14:09:49 <sgallagh> I would actually call that a benefit to part 1
14:09:56 <zbyszek> I think keeping them as co-maintainers doesn't hurt and makes it easier to pick up again.
14:09:59 <dcantrell> hi Miro
14:10:10 <sgallagh> It means they'll only ask to be re-added to the ones they actually care about
14:10:23 <nirik> or just decide it's too much red tape and go do something else?
14:10:25 <sgallagh> And we'll have a more realistic view of what packages are adequately maintained
14:10:27 <decathorpe> nirik: yes, that is a "potential downside" though if a packager is really voted to be non-responsive then I'm not sure keeping them as co-maintainer is actually a good idea, but that's a separate discussion
14:10:53 <dcantrell> some people go non-responsive too simply because they haven't had luck handing packages off to new maintainers
14:11:02 <King_InuYasha> I'm good with going with all three proposals together +1
14:11:09 <King_InuYasha> and I've said as much in the ticket
14:11:11 <dcantrell> we don't have a good exit path for people who no longer want to maintain packages or who do but lack time
14:11:13 <King_InuYasha> just now
14:11:35 <nirik> well, you can orphan your packages anytime?
14:11:48 <sgallagh> nirik: If that's too much red tape, chances are that's a good indicator of how much care they'd put into their packages.
14:12:16 <bcotton> orphaning your package requires admitting that you can't maintain them anymore, which is a hard thing to do for a lot of people :-)
14:12:39 <decathorpe> Question: Do we want to discuss this detail now, or should I modify my "proposal 1" slightly to remove the controversial bit?
14:12:41 <dcantrell> nirik: true, but in some cases if packages are still used but no one has claimed it off the orphaned packages list, then the last person to touch it still gets contacted and there is a certain amount of anxiety that comes along with that
14:13:20 <nirik> I don't think thats fair... say you added a stack of 30 packages that are needed for the 1 you care about... you get busy and find out that you were marked unresposive... you might come back and work on the one you care about, but you might not want to go through talking to all the new maintainerrs to be re-added to all those deps...
14:13:30 <dcantrell> decathorpe: personally, I don't think we need to do that.  the non-responsive policy is understood and I think this is an ok action when someone is non-responsive
14:13:49 <zbyszek> decathorpe: how would you change it?
14:14:14 <mhroncok> when somebody is nonrepsonsive, they should be removed from all their packages
14:14:27 <sgallagh> mhroncok: +1
14:14:34 <mhroncok> it reduces the amount of stale obsolete info
14:14:39 <dcantrell> nirik: that's valid, but are you really maintaining the 30 packages you added or just the one?  do you have the time to do all that work?
14:14:47 <mhroncok> look, this thing has 14 co-mainters... but all of them are gone
14:14:49 <dcantrell> mhroncok: +1
14:14:59 <nirik> it's hard to say in hypotheticals. ;)
14:15:02 <King_InuYasha> we have packages like that today, and it's pretty hard to get that reassigned
14:15:03 <zbyszek> Yeah, I guess that's a good point.
14:15:10 <King_InuYasha> e.g. some of the sip stack packages
14:15:25 <decathorpe> Modified Proposal 1: When a packager is declared non-responsive, also remove them from all packages as watchers, in addition to orphaning packages where they have "main admin" / "owner" role.
14:15:30 <decathorpe> This skips the "controversial part" for now, which we can discuss separately (since it's a modification of the Non-responsive maintainer policy)
14:15:32 <King_InuYasha> +1
14:15:39 <zbyszek> +1
14:15:51 <dcantrell> I think if you added pkgs but were unresponsive for some and got removed, it's an indicator that help is needed.  Not that you are failing.  And as a project we should step in and clear out their ownership and spread the work out.
14:15:58 <nirik> so... did we agree to remove people from retired packages?
14:16:20 <decathorpe> nirik: we did
14:16:25 <mhroncok> nirik: yes
14:16:25 <dcantrell> decathorpe: +1 to modified proposal
14:16:41 <mhroncok> decathorpe: +1 to this and please let me know what was the removed controvrsial bit
14:17:06 <decathorpe> mhroncok: don't remove nonresponsive packagers as comaintainers for now, move to different discussion
14:17:45 <sgallagh> I'm +1 to the revised Proposal 1, but I'd honestly *prefer* the original one.
14:18:25 <mhroncok> oh, so it removes them as watchers but not commit/admin/ticket?
14:18:35 <mhroncok> I change my vote to 0
14:18:45 <mhroncok> sorry, I've missed that bit
14:18:57 <mhroncok> my vote is to wipe them from ACLs and watchers
14:19:07 <zbyszek> I have to say that mhroncok's arguments convinced me, and I'd vote for the original proposal too.
14:19:21 <decathorpe> alright, so I withdraw modified Proposal 1
14:19:30 <dcantrell> I'd prefer the original step 1, but am +1 on both the original or the revised one
14:19:56 <nirik> I'm not in favor, but won't stand in everyone's way if you all feel thats the way to go... :)
14:20:14 <decathorpe> Ok, can I have votes for the original P1+2+3 (as stated in the ticket)? IRC / my internet connection seems to be wonky today and messages seem to arrive out of order :(
14:20:32 <zbyszek> +1 to original proposal in its entirety
14:20:40 <dcantrell> +1 to original proposal in its entirety
14:20:52 <nirik> -1 for 1, +1 2 and 3. ;)
14:21:01 <sgallagh> +1/+1/+1
14:21:14 <mhroncok> +1/+1/+1
14:21:14 <zbyszek> decathorpe: I think it's using TCP, so we must be just talking out of order (as usual) :)
14:21:42 <King_InuYasha> +1/+1/+1
14:21:51 <sgallagh> Or decathorpe is using IRCCloud via Internet Explorer :-P
14:22:19 <decathorpe> oh that may be it! :D
14:22:28 <decathorpe> thanks for the votes
14:22:54 <decathorpe> P1: (+5, 0, -1) ---- P2+P3: (+6, 0, -0)
14:23:30 <decathorpe> #agree APPROVED (P1: (+5, 0, -1); P2+P3: (+6, 0, -0))
14:23:52 <decathorpe> pingou will be happy
14:24:43 <decathorpe> #topic Next week's chair
14:24:45 <pingou> nirik: one thing about "I'm out and loosing all my packages", we're only considering accounts that are invalid in bugzilla
14:24:52 <King_InuYasha> I'm happy to chair next week
14:25:07 * pingou shouldn't be in two meetings at ones, so may have missed something
14:25:12 <nirik> pingou: right now yes, but not moving forward. ;)
14:25:18 <pingou> nirik: ah :(
14:25:32 <nirik> moving forward it means when someone is unresponsive they are removed from everything.
14:25:47 <pingou> I'd prefer we only remove people that somehow causes problem
14:25:49 <nirik> but thats ok, we will see if it causes any issues.
14:25:59 <decathorpe> well, we can always keep this in mind when voting non non-responsive maintainer tickets.
14:26:06 <King_InuYasha> if it causes a problem, we can revisit this
14:26:07 <pingou> people MIA that don't cause problem, well... don't cause problems
14:26:11 <zbyszek> nirik: yeah, it *feels* a bit scary, but we should try if it works better than the current rules.
14:26:19 <decathorpe> regarding next-weeks-chair: I think last week mhroncok volunteered for next week?
14:26:30 <King_InuYasha> oh, that's certainly fine :)
14:26:34 <sgallagh> pingou: I disagree
14:26:35 <mhroncok> decathorpe: I honestly don'T recall
14:26:55 <mhroncok> pingou: they cause outdated information
14:26:55 <sgallagh> People MIA still cause problems because it provides a false sense of the level of maintenance a package has.
14:26:58 <pingou> sgallagh: eager to hear more, but I'll ping you out of the meeting
14:27:02 <zbyszek> Maybe it'll encourage poeple to shed packages more quickly, without going through the whole non-resp maintainer procedure.
14:27:10 <decathorpe> ok, then the question is: any volunteeres?
14:27:23 <King_InuYasha> I can chair next week
14:27:30 <decathorpe> zbyszek: I hope that this will be the outcome, yes
14:27:42 <decathorpe> King_InuYasha: thanks
14:27:51 <decathorpe> #action ngompa will chair next week's meeting
14:28:05 <decathorpe> #topic Open Floor
14:28:12 <bcotton> o/
14:28:15 <mhroncok> no idea if you already talked baout this, but to do about all the stalled changes ticktes?
14:28:22 <mhroncok> *what to do
14:28:33 <zbyszek> We should treat each one individually.
14:28:54 <mhroncok> zbyszek: when is the point that we say: rejected
14:29:27 <mhroncok> there are official deadlines for submission, and code ready. do we only kill the chnages when they ar enot approved until beta freeze? or sooner
14:29:58 <bcotton> depends on the scope of the proposal, i'd say
14:29:58 <zbyszek> mhroncok: I think that for simple changes we can reject them at the last meeting before beta freeze.
14:30:14 <mhroncok> fine by me
14:30:22 <mhroncok> I just wanted to hear other opinions
14:30:34 * zbyszek looks for the F33 schedule
14:31:48 <zbyszek> Tue 2020-08-25 is change checkpoint and beta freeze
14:32:16 <mhroncok> ack
14:32:46 <zbyszek> So the fesco meeting 3 weeks from now is the last one before that.
14:33:08 <King_InuYasha> do we have any non-trivial changes left to examine?
14:34:15 <decathorpe> PostgreSQL 13 doesn't look too good.
14:34:43 <nirik> the forge macros is still waiting
14:35:05 <bcotton> panovotn updated the PostgreSQL 13 proposal https://fedoraproject.org/w/index.php?title=Changes%2FPostgreSQL_13&type=revision&diff=583493&oldid=582401
14:35:18 <zbyszek> 2409 (compiler policy change) is also stalled
14:35:25 <decathorpe> nirik: there was some "discussion" on #fedora-devel aboutt them
14:36:04 <nirik> yeah, but note there are 2 changes... the forge macros (33) and the autorelease stuff on top of that (34)
14:36:23 <mhroncok> bcotton: nice
14:36:27 <decathorpe> bcotton: oh, good, this does look better. though there's still no info as to who will actually do the necessary rebuilds.
14:36:28 <King_InuYasha> at least the pgsql 13 one, the changes to the proposal look fine to me
14:36:39 <King_InuYasha> I am assuming the change author is going to do the rebuilds
14:37:22 <decathorpe> they're not a provenpackager.
14:37:35 <King_InuYasha> umm well then
14:37:39 <King_InuYasha> that's a problem
14:37:42 <zbyszek> Also "revert changes" is not very ... verbose.
14:37:52 <King_InuYasha> someone is going to need to help this person :(
14:39:07 <decathorpe> so ... volunteer from FESCo to help with Change proposal and come up with more detailed rebuild plan and contingency mechanism?
14:39:45 <mhroncok> I've tried the last time several times, they didn't communicate :(
14:39:47 <King_InuYasha> anyone want to help shepherd this through?
14:40:03 * King_InuYasha is personally a little swamped
14:40:11 * sgallagh is in the same boat
14:40:30 <King_InuYasha> I'd *love* to have pgsql 13 in F33, but I don't think I have bandwidth to help out
14:40:52 * nirik is idle and has lots of free time to... naaa... kidding. I'm busy too. :)
14:41:19 <nirik> I guess I can try if no one else wants to... or we could ask them to line up provenpackagers on the list?
14:41:32 <King_InuYasha> nirik: that'd be great :)
14:41:55 <King_InuYasha> it'd be nice to see panovotn say something on-list at all, though :(
14:42:24 <mhroncok> that is the root of the problem
14:42:42 <decathorpe> yeah :( communication could be better (s/better/existent)
14:42:49 * mhroncok would be happy to help, we are on the same subsystem in RH, but there is no way
14:43:36 <King_InuYasha> wait, what?
14:43:40 <King_InuYasha> that seems broken
14:44:06 <King_InuYasha> iirc, SSTs are supposed to be able to talk to each other relatively easily
14:44:17 <King_InuYasha> s/SSTs/SST members/
14:44:22 <sgallagh> mhroncok: No way to do what?
14:44:31 * sgallagh is guessing that sentence was accidentally shortened.
14:45:53 <mhroncok> sgallagh: no way to talk to them
14:46:21 <mhroncok> sgallagh: as an example, there are no responses on the mailing list thread about this from the change owner
14:46:42 <sgallagh> That... feels like something that should likely be escalated in-house.
14:46:49 <nirik> and direct emails also get no answer?
14:47:06 <mhroncok> let me rephrase
14:47:19 <mhroncok> trough Fedora comminty channels, mailing list, fesco tickets and bugzilla, this didn't work
14:47:25 <nirik> in any case yeah... should try and educate them on how to better communicate for these sort of changes?
14:47:35 <mhroncok> I can volunteer my Fedora time to help, but I don't wish to do things interanally
14:48:11 <King_InuYasha> is this person new to Fedora things?
14:49:03 <mhroncok> no idea, there is no wiki page etc.
14:49:21 <zbyszek> They have been in RH for a while...
14:49:43 <King_InuYasha> that doesn't mean anything, unfortunately
14:49:54 <King_InuYasha> the person who maintains libseccomp in RHEL, for example, does nothing in Fedora
14:50:10 <King_InuYasha> same for pkgconf
14:50:13 <decathorpe> well, that seems ... suboptimal
14:50:25 <King_InuYasha> it happens a lot more these days
14:50:26 <mhroncok> https://src.fedoraproject.org/rpms/postgresql/commits/master suggest 2 years of postgresql maintanance
14:50:26 <dcantrell> that has kind of gotten worse over time too
14:50:39 <dcantrell> unfortunately
14:51:16 <King_InuYasha> it's something I've learned to expect more these days, sadly :(
14:51:27 <dcantrell> :(
14:51:39 <King_InuYasha> but at least this person *does* stuff in Fedora, admittedly quietly
14:52:01 <dcantrell> mhroncok is right, we should communicate on this psql issue via fedora channels rather than internally
14:52:06 <nirik> so, what do we want to do here? I can try mailing them, but if we know thats not going to work... what do we do? just reject the change?
14:52:16 <mhroncok> there is a contingency
14:52:23 <mhroncok> there is code 100% complete deadline
14:52:49 <mhroncok> we approve it and we let them now that we have provenpackagers who can help if reached throu Fedora channels
14:53:11 <nirik> ok. we should also note it should be done in a side tag.
14:53:54 <mhroncok> nirik: I wanted to say that this is obvious... but probably better to explicitly state that
14:54:00 <mhroncok> Proposal
14:54:02 <mhroncok> ...
14:54:47 <nirik> yeah, I don't see it mentioned on the change page.
14:55:13 <mhroncok> Change is APPROVED assuming the update will be delivered via a side tag. If provenpackager powers are required, please ask for help via Fedora channels.
14:55:40 <decathorpe> mhroncok: +1
14:55:45 <sgallagh> mhroncok: I'm good with that. +1
14:55:45 <dcantrell> mhroncok: +1
14:56:59 <King_InuYasha> mhroncok: +1
14:57:25 <zbyszek> mhroncok: I don't think the change is realistic as written. There's a list of ~100 packages that need to be rebuilt in the side tag, and no communication with proven packagers has happened to date.
14:57:46 <mhroncok> zbyszek: would you like to ask them again to adapt the proposal?
14:58:04 <zbyszek> Yes.
14:58:08 <mhroncok> ok
14:58:26 <zbyszek> I'll write a list of concrete questions in the ticket that I think need to be answered in the change page.
14:58:27 <mhroncok> we still have time...
14:59:20 <decathorpe> #action zbyszek to comment in PostgreSQL ticket with questions / missing details in Change Proposal
15:00:06 <decathorpe> If there's anything else, speak up now, or I will close the meeting in a few minutes :)
15:00:12 <zbyszek> Yes...
15:00:25 <zbyszek> .fesco 2416
15:00:26 <zodbot> zbyszek: Issue #2416: Update 3rd party repo policy - fesco - Pagure.io - https://pagure.io/fesco/issue/2416
15:00:48 <zbyszek> I made a proposal to approve https://pagure.io/fesco/issue/34
15:00:59 <decathorpe> #topic #2416 Update 3rd party repo policy
15:01:26 <bcotton> decathorpe: i also have a thing when the current topic is done
15:01:35 <zbyszek> There weren't any comments for a week, so I thought everyone is happy...
15:01:37 <decathorpe> bcotton: noted
15:01:46 <zbyszek> But maybe not. Either way, please vote or comment.
15:01:47 <King_InuYasha> zbyszek: +1
15:01:59 <zbyszek> King_InuYasha: in the ticket please, I don't think we should handle this here.
15:02:02 <King_InuYasha> oh
15:02:12 <King_InuYasha> issue 34 is kinda old though
15:02:44 <decathorpe> I see a fresh question from aday in PR#34, regarding flathub
15:02:45 <King_InuYasha> oh, that was supposed to fesco-docs/pull-request/34
15:02:48 <mhroncok> King_InuYasha: that is pagure UX fail
15:03:08 <mhroncok> King_InuYasha: please fix it :D
15:03:12 <King_InuYasha> haha
15:03:19 <King_InuYasha> it's because fesco-docs are not in fesco repo
15:03:21 * decathorpe wonders if that's the reason why the other proposal was worded so overly-generic :(
15:03:42 <King_InuYasha> cross repo references aren't really a thing yet
15:03:52 <zbyszek> King_InuYasha: I edited the proposal to contain the full link now.
15:03:57 <King_InuYasha> zbyszek: cool, thanks
15:04:32 <decathorpe> #action everybody will read tickets and proposed docs changes and vote in ticket
15:04:38 <zbyszek> decathorpe: oh, right. I'll answer in the ticket.
15:04:53 <decathorpe> zbyszek: thanks!
15:05:16 <decathorpe> can we hand over the mic to bcotton?
15:05:28 <zbyszek> (actually I saw the notification for this earlier, but there's so many tickets and prs that I couldn't find it... I'll keep a tab open now.)
15:05:41 <zbyszek> yes please
15:05:57 * decathorpe hands mic to bcotton
15:06:11 <bcotton> #info Council is voting on an actual process for promoting deliverables to Edition status https://fedoraproject.org/wiki/Editions/Promotion_Process
15:06:18 <bcotton> spoiler alert: it will likely pass
15:06:44 <bcotton> the main reason i'm bringing it up here is because in the next few days i'll be submitting an INCREDIBLY LATE F33 system-wide change proposal for promoting IoT to edition
15:07:00 <bcotton> the reason i'm doing this is because most of the work was done before f32, so it's mostly a paperwork issue at this point
15:07:07 <bcotton> so. if anyone objects, now is the time to let me know
15:07:30 <bcotton> or if anyone thinks we should shortcut the process in any way, also let me know
15:07:31 <bcotton> EOF
15:08:11 * nirik replied to the council list thread on it, but didn't see any replies. ;)
15:08:16 <King_InuYasha> meh, seems fine to me
15:08:31 <decathorpe> seems fine to me too. System Wide Change seems the appropriate channel
15:08:32 <zbyszek> yeah, looks reasonable
15:08:34 <King_InuYasha> though it's going to be interesting to see if we'll get more editions out of it
15:08:50 <King_InuYasha> iirc, one of the reasons this wasn't a real process was to *prevent* editions from spawning
15:09:34 <decathorpe> well, there are criteria that must be met
15:09:36 <bcotton> nirik: oh, poop. i meant to reply. i'll do that now anyway
15:09:56 <King_InuYasha> i.e. the Plasma Desktop product was rejected years ago on the basis that they didn't want such an edition
15:10:03 <King_InuYasha> s/i.e./e.g./
15:10:15 <bcotton> King_InuYasha: yeah, it's not about "i can make anything an edition" so much as "here's what that means"
15:10:30 <King_InuYasha> hmm
15:10:32 <bcotton> because we discovered when promoting IoT that there were a bunch of unchecked boxes
15:10:37 <bcotton> and i made adam very sad
15:10:41 <King_InuYasha> well yeah, because there were no boxes to check :D
15:10:48 <bcotton> exactly!
15:10:50 <King_InuYasha> it was at the whim of the Council back then
15:11:06 <King_InuYasha> which is what sort of upset a few KDE SIG folks, since they wanted to become a proper WG then
15:11:11 <King_InuYasha> meh, old history
15:11:23 <King_InuYasha> but relevant when considering having an actual process for making editions
15:11:29 <sgallagh> bcotton: Is there a complementary "demotion" policy as well?
15:11:34 <King_InuYasha> whimsy would look incredibly specious
15:11:39 <sgallagh> For example, discontinuing Editions that are on life-support?
15:11:48 <King_InuYasha> we still technically have a Cloud Edition
15:11:52 <bcotton> sgallagh: asking for a friend?
15:11:57 <decathorpe> bcotton: other than "this looks fine at first glance", is there anything we should discuss right now?
15:11:57 <King_InuYasha> which is being revived mind you, but has been dead for a few years
15:11:58 <sgallagh> My best friend!
15:12:21 <bcotton> there is not, in part because it's basically "stop calling this an edition", but that's something we can look at later
15:12:37 <bcotton> decathorpe: nope. just wanted to make sure everyone was aware it's coming and _why_ it's coming so unbelievably late
15:12:48 <King_InuYasha> bcotton: I'd like to see some marketing clarifications for Editions as a followup, but the process lgtm
15:12:57 <bcotton> where "it" is "the iot promotion proposal"
15:13:06 <zbyszek> bcotton: you are still doing the spin liveness check every release right?
15:13:19 <decathorpe> bcotton: alright thanks, I just don't want this meeting to run any longer than necessary :)
15:13:34 <King_InuYasha> technically, Fedora has five editions, but only three are marketed
15:13:37 <bcotton> zbyszek: correct
15:13:50 <zbyszek> bcotton: could we just include the editions in that too?
15:13:52 <King_InuYasha> with IoT being promoted, that'd be six editions
15:14:04 <bcotton> King_InuYasha: good item for the council-discuss list
15:14:06 * dcantrell hears The Count from Sesame Street
15:14:23 <sgallagh> I'm prepared to propose Server to drop back to being a Spin
15:14:24 <King_InuYasha> bcotton: I'll bring it up sometime later
15:14:43 <King_InuYasha> sgallagh: why?
15:14:47 <bcotton> zbyszek: maybe. there's more to an edition than "someone is still there", but it'd be good to at least know if something is dead
15:14:56 <sgallagh> Because I can't keep running it solo and still pretend it's an "Edition"
15:15:18 <dcantrell> we should drop the Server edition and create a Fedora Enterprise edition
15:15:21 <King_InuYasha> sgallagh: sorry about that... I'd certainly be happy to help with Server WG stuff, I just didn't know what to do
15:15:22 <King_InuYasha> hahaha
15:15:28 <King_InuYasha> dcantrell: oh boy, hehe
15:15:34 <decathorpe> Proposal: End meeting if there's no other topics to discuss?
15:15:43 <mhroncok> +1 to end
15:15:45 <dcantrell> +1
15:15:47 <zbyszek> ack
15:15:49 <King_InuYasha> ack
15:15:52 <mhroncok> see you later
15:15:57 <mhroncok> decathorpe++
15:16:03 <dcantrell> thanks, decathorpe++
15:16:08 <decathorpe> great. thanks everybody! have a nice week.
15:16:11 <sgallagh> Thanks decathorpe
15:16:15 <sgallagh> decathorpe++
15:16:15 <zodbot> sgallagh: Karma for decathorpe changed to 13 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:16:19 <zbyszek> thanks decathorpe
15:16:25 <decathorpe> #endmeeting