15:00:05 <zbyszek> #startmeeting FESCO (2020-11-18)
15:00:05 <zodbot> Meeting started Wed Nov 18 15:00:05 2020 UTC.
15:00:05 <zodbot> This meeting is logged and archived in a public location.
15:00:05 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:05 <zodbot> The meeting name has been set to 'fesco_(2020-11-18)'
15:00:05 <zbyszek> #meetingname fesco
15:00:05 <zbyszek> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
15:00:05 <zodbot> The meeting name has been set to 'fesco'
15:00:05 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:07 <zbyszek> #topic init process
15:00:10 <zbyszek> .hello2
15:00:11 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:19 <bcotton> .hello2
15:00:20 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:00:42 <dcantrell> .hello2
15:00:43 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
15:01:11 <sgallagh> .hello2
15:01:12 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:12 <cverna> .hello2
15:01:15 <zodbot> cverna: cverna 'Clement Verna' <clems.verna@gmail.com>
15:01:19 <nirik> morning
15:01:23 <nirik> .hello kevin
15:01:24 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:01:35 <mhroncok> .hello churchyard
15:01:37 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
15:01:57 <zbyszek> That's quorum.
15:01:59 <zbyszek> Let's start.
15:02:07 <zbyszek> #topic #2473 Updates policy is out of date
15:02:07 <zbyszek> .fesco 2473
15:02:08 <zodbot> zbyszek: Issue #2473: updates policy is out of date - fesco - Pagure.io - https://pagure.io/fesco/issue/2473
15:02:12 <decathorpe> .hello2
15:02:13 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:02:44 <King_InuYasha> .hello ngompa
15:02:45 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
15:02:49 <nirik> I haven't had time to fold in the last comments...
15:02:52 <zbyszek> So... there were some unaddressed comments, but in general it's a solid upgrade to what we have now.
15:02:58 * nirik 's power was out most of yesterday. ;(
15:03:19 <decathorpe> yeah I think we can approve this in the ticket / PR once the final version is ready
15:03:31 <zbyszek> Sounds reasonable.
15:04:06 <zbyszek> Any other comments?
15:04:09 <mhroncok> nope
15:04:18 <dcantrell> none from me
15:04:28 <zbyszek> #topic #2475 Proposal: let's develop the idea of a new repo for lightly-maintained packages
15:04:31 <zbyszek> .fesco 2475
15:04:32 <zodbot> zbyszek: Issue #2475: proposal: let's develop the idea of a new repo for lightly-maintained packages - fesco - Pagure.io - https://pagure.io/fesco/issue/2475
15:05:05 <nirik> this is being discussed on list, right?
15:05:07 <zbyszek> I think one clear outcome is that many people are against a separate repo, because it'd cause additional work.
15:05:13 <mhroncok> the discussion is happening under the fesco email
15:05:20 <dcantrell> zbyszek: agreed
15:05:37 <zbyszek> #info https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/P7QMEXGV3X76Z2K67AW32YX6BQVFDHS3/
15:05:37 <dcantrell> I think the next step here is to actually draft a proposal based on the list feedback and post it
15:05:43 <dcantrell> I don't mind doing that
15:06:06 <decathorpe> dcantrell: well what do you want to propose? I don't think there's any agreement on the devil list
15:06:13 <nirik> I'm a bit torn on this... as I think it's good to set user expectations, but I think marking things will be not at all easy
15:06:54 <dcantrell> I guess I'm thinking more difference between policy vs implementation.  My first thought was we could have a policy that allows for packages that fit this criteria.  How we do that would be a separate task
15:07:16 <zbyszek> One open question is whether dnf and the other installation tools should make use of this? E.g. should dnf ask about installing (the first) lightly-maintained package similarly how it asks for new gpg keys?
15:07:17 <nirik> 'lightly maintained' isn't a good expectation...
15:07:21 <decathorpe> Well, the technical limitations should certainly inform the policy :/
15:07:59 <King_InuYasha> I think this is fundamentally a bad idea
15:08:06 <dcantrell> I don't think this is an idea for dnf.  My thought for all of this is to help inform project contributors what packages fit this category
15:08:11 <dcantrell> not necessarily end users
15:08:20 <nirik> I maintain libfoo only as to make sure bar works could be one, but also I only maintain libfoo when I have time and it's not my priority, but also ...
15:08:39 <dcantrell> nirik: that's pretty much exactly the case I'm thinking about because it's real and it already exists
15:08:41 <King_InuYasha> by definition, almost the entirety of RHEL and Fedora are "lightly maintained" in that regard
15:08:49 <dcantrell> I disagree
15:08:50 <decathorpe> Why can't SIGs fit in here?
15:09:02 <dcantrell> decathorpe: they could, sure
15:09:22 <nirik> So, if a package is 'lightly maintained' what different behavior should users expect?
15:09:31 <mhroncok> also, when we open bugzillas because something is broken, I don't want people replying: this is a second degree package, don't expect this fixed
15:10:09 <decathorpe> mhroncok: yeah that would obviously be bad
15:10:11 <King_InuYasha> see, that's the problem, because we'll see that behavior formalized
15:10:11 <dcantrell> no, what I'm thinking is that by having a classification like this we can more quickly determine why something was added and get it to a proper owner (be it a sig or an individual)
15:10:32 <King_InuYasha> well, since SIGs can't own packages, that doesn't work :(
15:10:39 <dcantrell> we could amend policy so that packages added that fit this category that have bugs opened and that fail to have them addressed get slated for removal
15:10:58 <King_InuYasha> again, half the distro would break on that
15:11:06 <decathorpe> King_InuYasha: that's why I suggested a "nursery" user, like there's the "orphan" user :)
15:11:27 <dcantrell> something like orphan but that indicates it's still necessary
15:11:34 <King_InuYasha> I know of a couple of fairly critical examples that are effectively unmaintained or lightly maintained in RHEL and Fedora, and allowing that expectation to be accepted is going to make it worse
15:11:51 * nirik thinks this needs more thought, because right now it looks like a solution in search of a problem. ;)
15:12:08 <mhroncok> nirik++
15:12:14 <zbyszek> nirik +1
15:12:32 <Conan_Kudo> nirik++
15:12:32 <zodbot> Conan_Kudo: Karma for kevin changed to 11 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:12:55 <mhroncok> Conan_Kudo: wow, that as tedious
15:12:57 <mhroncok> *was
15:12:57 <zbyszek> Also, even if a package is not matained "with love", but has no bugs open, then what is the problem?
15:13:16 <nirik> I mean if it helps us somehow, great, but I think it needs work before it helps...
15:13:20 <dcantrell> zbyszek: no problem
15:13:31 * mhroncok maintains most of his packages "with regrets" and not "with love" TBH
15:13:42 <sgallagh> mhroncok: +1
15:14:09 <zbyszek> Right, so maybe we should just make it easier to mark packages as "help is wanted"? No matter why they were added in the first place.
15:14:23 <nirik> I wonder if it wouldn't be nice to take this from another angle... datamine bugzilla more and find out areas/maintainers/packages that need help... and try and get that help to them?
15:14:23 <mhroncok> zbyszek: again, that is all of them
15:14:24 <dcantrell> that might be the easiest thing to do
15:14:38 <nirik> mhroncok: +1
15:14:41 <zbyszek> nirik: yeah, that's my thinking too.
15:14:46 <dcantrell> nirik: it would be interesting to see that data
15:15:19 <nirik> but it's not an easy problem... I mean bug numbers would be easy, but thats not a good indicator...
15:15:23 <zbyszek> In the past I floated the idea of sorting packages by "open-bug-months". That could be useful to direct volunteer help.
15:15:24 * cverna is scared about datamining bugzilla :P
15:15:26 <nirik> we do have the 'prioritized bugs' process...
15:15:56 <dcantrell> number of bugs closed automatically due to EOL for a package would be an interesting count
15:15:57 <zbyszek> nirik: prioritized bugs are in single digits each release cycle... and we have 20k packages
15:15:59 <King_InuYasha> having a "help wanted" process is probably better than assuming no help will come
15:15:59 <decathorpe> apparently entire working groups are ignoring bugzilla, so that would be a good place to start, I guess
15:16:27 <King_InuYasha> yeah, Workstation WG (despite my objections) has the general policy of ignoring RHBZ
15:16:43 <sgallagh> dcantrell: Interesting, but not always useful.
15:16:47 <nirik> well, we have also talked about takling that someday, but never have
15:17:01 <dcantrell> sgallagh: cross reference with the count of open ones at the beginning of said release, for instance
15:17:24 <sgallagh> For example, I often end up with MANY Node.js bugs closed EOL because I literally cannot keep up with the number that get filed vs. what gets fixed in each release,.
15:17:42 <zbyszek> sgallagh: but that clearly means that help would be useful...
15:18:04 <mhroncok> and if we identify nodejs or other package as "has many bugz", what useful can be done with that information exacly?
15:18:10 <sgallagh> I guess help with bug management, sure.
15:18:16 <nirik> I wish we could do per package templates in bugzilla. ;(
15:19:18 <zbyszek> Would it be possible to extract this data through public bugzilla api?
15:19:29 <nirik> I would think so...
15:19:52 <bcotton> nirik: we can do per-component BZ templates, it's just a manual process :/
15:20:05 <nirik> but we aren't sure what data is best... so it would just take some tinkering and dataviz skills
15:20:09 <bcotton> i did this for FCOS earlier this year
15:20:21 <nirik> bcotton: component yeah, but not package. :)
15:20:44 <bcotton> okay, fair
15:20:49 <sgallagh> nirik: Aren't those synonyms in BZ?
15:20:53 <nirik> ie, I would like to have all the gnome packages say "You probibly want to file this at gitlab.gnome.org unless you really think it's a fedora packaging bug"
15:21:32 <bcotton> we'd just need to define a list of the components for that. because that's not a single package either
15:22:31 <bcotton> in my dream world, we'd have a team of triagers who would go through new bugs and file them upstream on behalf of the user when it's an upstream bug. but i also want a pony
15:23:01 <dcantrell> yes but what color stable should the pony be kept in?
15:23:23 <bcotton> dcantrell++
15:23:38 <zbyszek> bcotton: I think it'd be easier for upstreams to also look at the bugzilla. When packagers are also involved in upstream there isn't really that much difference.
15:23:43 <nirik> I was told by bz folks that you couldn't do per package termpaltes... but ok. Anyhow, I think we are drifting off topic here.
15:24:00 <nirik> proposal: close this ticket and discuss more on devel for a concrete proposal
15:24:09 <cverna> +1
15:24:10 <dcantrell> +1
15:24:12 <mhroncok> +1
15:24:15 <zbyszek> wait please
15:24:30 * mhroncok waits
15:24:43 * dcantrell idles in neutral
15:24:47 <zbyszek> Is "concrete proposal" something along the dataviz lines we were just discussing, or more on the previous approach with metadata?
15:25:20 * zbyszek doesn't want to ask people to iterate on the original proposal just to shoot it down again
15:25:35 <nirik> well, something we can vote on and implement? dunno what it might be in the end.
15:26:04 <mhroncok> IMHO we need to figure out what do we try to accomplish
15:26:09 <King_InuYasha> yeah
15:26:09 <zbyszek> OK, +1 then.
15:26:20 <King_InuYasha> I'm in favor of an idea to create a "help wanted" process
15:26:24 <sgallagh> +1
15:26:29 <decathorpe> +1
15:26:31 <King_InuYasha> that could also help with getting new folks to figure out where to get started
15:26:31 <nirik> yeah, the problem isn't clear either.
15:26:33 <sgallagh> (to nirik)
15:26:42 <dcantrell> +1
15:27:08 <zbyszek> #agreed Close this ticket and discuss more on devel for a concrete proposal (+7, 0, 0)
15:27:08 <dcantrell> getting new contributors involved was part of my motivation behind the idea in the first place
15:27:08 <King_InuYasha> the problem here is I don't know what problem we're trying to solve and what kind of constraints we're assuming
15:27:13 <sgallagh> A "help wanted" process could also be useful, except for the fact that the Venn Diagram of "packages in the distribution" and "packages seeking additional helpers" would be a circle
15:27:44 <King_InuYasha> sgallagh: yes, but establishing some criteria to populate this for something like the Join SIG to use for folks is better than nothing
15:27:46 <zbyszek> sgallagh: don't forget the 0-surface-area subset of packages who don't want anyone else to touch their package
15:28:01 * King_InuYasha grumbles
15:28:06 <King_InuYasha> I hate those folks
15:28:17 <zbyszek> Anyway....
15:28:24 <zbyszek> #topic #2501 F34 System-Wide Change: Remove and deprecate nscd in favour of sssd and systemd-resolved
15:28:27 <zbyszek> .fesco #2501
15:28:27 <zodbot> zbyszek: Error: '#2501' is not a valid integer.
15:28:28 <nirik> the orig problem in the ticket was talking about java and modules... so thats another case I guess
15:28:37 <zbyszek> .fesco 2501
15:28:38 <zodbot> zbyszek: Issue #2501: F34 System-Wide Change: Remove and deprecate nscd in favour of sssd and systemd-resolved - fesco - Pagure.io - https://pagure.io/fesco/issue/2501
15:29:17 <sgallagh> I'm somewhat biased here, as this was my original goal when I wrote SSSD all those years ago...
15:29:21 <dcantrell> I'm not caught up on this one on devel, my only concern so far is about handling existing nscd users
15:29:40 <mhroncok> I'm not caught up on this one on devel either, sorry :(
15:29:51 <nirik> +1 from me.
15:30:00 <nirik> (I can vote in ticket if it's not decided today)
15:30:02 <sgallagh> I read most of the devel thread.
15:30:28 <cverna> I did not follow that change too
15:30:30 <sgallagh> 90%+ of the complaints are coming from people who decided 8-10 years ago to hate SSSD and have assumed that it has remained unmodified in that time.
15:30:59 <sgallagh> Another 5% are people who are complaining about issues that are caused by their own configuration choices.
15:31:08 <King_InuYasha> and the remaining 5%?
15:31:18 <sgallagh> There remainder have valid concerns
15:31:41 <decathorpe> At least that's a better ratio than for the vi / nano Change
15:31:47 <King_InuYasha> imho, I'm actually fine with this change, though I am annoyed that we say "deprecate" when we mean "remove"
15:32:03 <King_InuYasha> so wording aside, +1
15:32:18 <nirik> yeah, drop or remove would be more accurate.
15:32:20 * King_InuYasha has a pet peeve of people misusing the word "deprecate"
15:32:21 <decathorpe> ngompa: I agree, this needs to say "remove" when it means "remove"
15:32:38 <sgallagh> King_InuYasha: My eye twitches when they use "depreciate" also
15:32:49 <King_InuYasha> ah, I'm glad it's not just me!
15:32:57 <decathorpe> "send to a farm upstate"
15:33:17 <zbyszek> I edited the title in the wiki.
15:33:35 <sgallagh> So, I'll summarize my opinion (in favor of this Change):
15:34:16 <sgallagh> 1. The SSSD is under active maintenance and is the only supported mechanism for LDAP users in RHEL 8, to general satisfaction of RHEL customers.
15:35:00 <sgallagh> 2. The glibc team is maintaining nscd on a bare-minimum level. They publicly state that there are architectural problems with it that they don't see a reason to fix with SSSD as a viable alternative.
15:36:04 <sgallagh> In particular, the cache is *very* simplistic; it is unaware of temporary failures vs. permanent ones.
15:36:39 <zbyszek> I'll server as the devil's advocate then:
15:36:43 <sgallagh> Some reservations: nscd is the default mechanism for simple hostname caching.
15:36:56 * nirik recalls many times killing nscd to make things work. I am glad it's going away. :)
15:37:04 <zbyszek> 1. nscd is in a separate package, so it causes no harm whatsoever to people who don't use it
15:37:06 <sgallagh> There are concerns that systemd-resolved is not a sufficient replacement for that
15:37:23 <dcantrell> still reading through messages, but based on what I've read on the change proposal and comments from sgallagh, I would request that at least for one release cycle the nscd subpackage remain but be changed to not install by default.  existing users of nscd get a one release period to migrate over to sssd
15:37:26 <sgallagh> (alternatives such as dnsmasq and unbind have been floated)
15:37:40 <sgallagh> I think we already don't install it by default.
15:37:53 <zbyszek> Yeah, it's not installed by default, afaik.
15:37:59 <decathorpe> Could we mark the package as "Provides: deprecated()" for one release and remove it in the next one?
15:37:59 <dcantrell> alright, then don't remove it for at least one release cycle
15:38:17 <zbyszek> 2. we don't know if there are users out there
15:38:22 <sgallagh> It's not installed and not in the systemd presets
15:38:36 <King_InuYasha> it hasn't been installed by default for several cycles, iirc
15:38:38 <zbyszek> decathorpe: would anyone see that?
15:38:39 <sgallagh> 2. We *do* know there are users out there.
15:39:03 <mhroncok> zbyszek: we could make sure it's clearly marked deprecated (real meaning) in the release notes
15:39:04 <decathorpe> zbyszek: at least it prevents new packages from depending on it, it's checked by fedora-review
15:39:11 <mhroncok> zbyszek: there is not much more to be done
15:39:41 <zbyszek> So... I'm leaning towards marking it like decathorpe said and saying in Release Notes that it'll be dropped next release.
15:39:44 <nirik> I'm assuming they are going to drop it upstream too? or is this just fedora land?
15:39:54 <dcantrell> zbyszek: +1
15:39:58 <zbyszek> That'll give people a heads-up and a bit more time to adjust.
15:40:01 <mhroncok> libuser.src depnds on this, nothing else
15:40:04 <sgallagh> nirik: That was unspecified.
15:40:41 <King_InuYasha> I assume they want to drop it upstream
15:40:49 <King_InuYasha> but we should ask to be certain
15:41:18 <mhroncok> if this was packaged separately, would there be maintainers to take it?
15:41:20 <nirik> I'm not sure we should dictate development to them...
15:41:39 <sgallagh> mhroncok: It literally cannot be packaged separately
15:41:49 <dcantrell> there's nothing currently on the glibc 2.33 page about nscd
15:41:51 <sgallagh> It's deeply tied to glibc
15:41:55 <mhroncok> sgallagh: ack
15:41:56 <dcantrell> expected release is 2021-02-01
15:42:19 <mhroncok> what about a modular glibc version?
15:42:20 * mhroncok hides
15:42:32 * sgallagh calls down lightning on mhroncok
15:42:54 * King_InuYasha slaps mhroncok with a fish
15:43:38 <dcantrell> actually, more details...the only things I see in recent releases and HEAD for glibc NEWS are nscd bug fixes
15:43:43 <nirik> so perhaps we ask them to clarify when/if it's being dropped upstream and if a cycle of 'depeciated' is possible/ok?
15:43:57 <dcantrell> I think that's reasonable
15:44:03 <zbyszek> Agreed.
15:44:09 <King_InuYasha> Makes sense to me.
15:44:10 <mhroncok> makes sense
15:44:18 <decathorpe> +1
15:44:51 <sgallagh> nirik: You did that on purpose.
15:45:09 <zbyszek> OK, I'll put those questions in the ticket so Arjun can answer them.
15:45:12 <sgallagh> But I'm good with that
15:45:26 <dcantrell> sgallagh: for all intensive porpoises, I think nirik was correct
15:45:41 <zbyszek> Let's mow on
15:45:51 <sgallagh> Wait, I want to axe another question!
15:45:57 <sgallagh> (kidding)
15:46:11 <zbyszek> kweekly
15:46:13 <zbyszek> #topic Next week's chair
15:46:16 <nirik> ha
15:46:38 * nirik will not be around next week... how many other us folks will be out?
15:46:39 <sgallagh> I'll be on PTO next week, but as I haven't done it in a while I should probably volunteer for the first one in Dec.
15:46:52 <dcantrell> I will likely be on PTO as well
15:46:59 <decathorpe> is it time for turkey day again?
15:47:15 <nirik> yep.
15:47:22 <dcantrell> indeed and in these uncertain times that means during PTO I just sit in a different chair in a different room of my house than work days
15:47:33 <decathorpe> ah. sorry, lost track of time, have not left my house in 6 weeks
15:47:34 * nirik nods sadly.
15:47:55 <King_InuYasha> yay turkey day
15:47:59 <King_InuYasha> but possibly no turkey :(
15:48:33 <zbyszek> So... should we cancel next week's meeting and plan for 2nd December?
15:48:42 <mhroncok> I can do next week if we don't cancel it
15:50:29 <zbyszek> #action mhroncok will chair next meeting (either next week or on 2nd December)
15:50:32 <zbyszek> ok?
15:50:36 <mhroncok> nope
15:50:44 <mhroncok> I cannot commit to 2nd dec
15:50:44 <zbyszek> #undo
15:50:44 <zodbot> Removing item from minutes: ACTION by zbyszek at 15:50:29 : mhroncok will chair next meeting (either next week or on 2nd December)
15:50:48 <mhroncok> sorry
15:51:00 <sgallagh> I volunteered for 2nd December
15:51:09 <zbyszek> #action mhroncok will chair next meeting (if it happens)
15:51:16 <zbyszek> #action sgallagh will chair two weeks from now
15:51:20 <mhroncok> ack
15:51:25 <sgallagh> ack
15:51:26 <zbyszek> #topic Open Floor
15:52:03 <dcantrell> this affects no one here, but I had to get COVID tested over the weekend due to possible exposure.  test came back negative.  my first test since all this started.
15:52:36 <decathorpe> well that's good news
15:52:38 <zbyszek> dcantrell: good to hear that
15:52:52 <mhroncok> BTW good luck in the elections everybody (also defolos)
15:53:33 <decathorpe> is it just me, or are there few nominees for the number of open spots?
15:53:52 <mhroncok> decathorpe: N+1
15:54:15 <decathorpe> I guess it could be worse
15:54:59 <zbyszek> Oh, voting starts tommorrow.
15:55:30 <zbyszek> If nothing else, I'll close in a minute...
15:56:14 <zbyszek> #endmeeting