15:00:41 <sgallagh> #startmeeting FESCO (2019-04-01)
15:00:41 <zodbot> Meeting started Mon Apr  1 15:00:41 2019 UTC.
15:00:41 <zodbot> This meeting is logged and archived in a public location.
15:00:41 <zodbot> The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:41 <zodbot> The meeting name has been set to 'fesco_(2019-04-01)'
15:00:41 <sgallagh> #meetingname fesco
15:00:41 <zodbot> The meeting name has been set to 'fesco'
15:00:42 <sgallagh> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:42 <sgallagh> #topic init process
15:00:42 <zodbot> Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:46 <sgallagh> .hello2
15:00:47 <zbyszek> .hello2
15:00:47 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:50 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:51 <otaylor> .hello2
15:00:56 <jforbes> .hello2
15:00:56 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:00:59 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:01:05 <contyk> .hello psabata
15:01:06 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:10 <nirik> morning
15:02:02 <sgallagh> OK, that's quorum at least.
15:02:12 <sgallagh> We have zero open tickets on the agenda this week.
15:02:34 <sgallagh> Based on an informal poll in #fedora-devel, we opted to open the meeting for Open Floor topics.
15:02:39 <sgallagh> But first:
15:02:45 <sgallagh> #topic Next week's chair
15:02:54 <sgallagh> #action sgallagh to chair next week's FESCo meeting
15:03:02 <sgallagh> I'll chair again next week
15:03:09 <sgallagh> #topic Open Floor
15:03:11 <mhroncok_cell> Hey
15:03:13 <jforbes> thanks sgallagh
15:03:38 <mhroncok_cell> I guess I'm late, sorry about that
15:03:48 <sgallagh> mhroncok_cell: We have no agenda, so it's hard to be late for that :)
15:04:01 <zbyszek> mhroncok_cell: you're one week early
15:04:09 <sgallagh> zbyszek++
15:04:19 <mhroncok_cell> Also, I thought it's 1500 utc
15:04:25 <zbyszek> it is.
15:04:26 <sgallagh> mhroncok_cell: The meeting just started.
15:04:33 <sgallagh> You aren't actually late.
15:04:41 <mhroncok_cell> Oh. It looked like it just ended, good
15:04:46 <sgallagh> We just have no agenda, so we jumped straight to Open Floor
15:05:32 <contyk> :))
15:05:34 <sgallagh> All of the tickets are awaiting updates except for the Blocking Media ticket which was resolved
15:06:04 <sgallagh> #info We have no active tickets this week, so we jumped directly to Open Floor
15:06:20 <sgallagh> Does anyone have anything they'd like to discuss?
15:06:42 <sgallagh> contyk: Do you want to talk at all about the Ursa Major alternative or should that bake a few more days?
15:07:15 <contyk> is there anything new to discuss?
15:07:38 <sgallagh> contyk: Well, you have that draft document that's been shared to a limited audience
15:07:43 <sgallagh> Do you want to share it out more broadly?
15:08:28 <contyk> I shared it publicly in the ticket :)
15:08:39 <contyk> I don't know what else to add there
15:08:52 <contyk> the proposal is about having a separate small compose with the default streams
15:09:13 <contyk> koji would be constructing the non-modular buildroot from the tagged package set + this external repo
15:09:33 <contyk> this compose would also be made public so that third parties, including mock, could just reference it
15:09:59 <mhroncok_cell> That seem to be a good solution to the problem
15:10:00 <contyk> there's still one unknown when it comes to handling default streams in MBS
15:10:18 <contyk> the rest will need changes in createrepo/mergerepo that sgallagh is working on
15:10:23 <mhroncok_cell> Yet I'm still not sure we should encourage nonmodular content to depend on modules
15:10:40 <contyk> so that koji can merge the buildroot repos, preserving the modular metadata which the dnf in the buildroot will use
15:10:56 <contyk> what are your concerns?
15:11:28 <sgallagh> mhroncok_cell: I don't think that is avoidable.
15:11:46 <sgallagh> As Java, meson and several other build-tools have already converted to modules
15:12:00 <sgallagh> (And I plan to move Node.js that direction once this is in place)
15:12:30 <otaylor> sgallagh: How woudl this work for something that is *runtime* like node.js ?
15:13:13 <otaylor> sgallagh: do we think that nonmodular content runtime-depending on modules is OK?
15:13:24 <mhroncok_cell> I have my concerns drafted, will try to approach fesco by the end of week
15:13:33 <sgallagh> otaylor: That's the entire purpose of a default stream, so yes
15:13:37 <mhroncok_cell> I don't think it's ok
15:13:55 <sgallagh> OK, that's overstating.
15:14:03 <sgallagh> It's *a* primary purpose of default streams
15:14:09 <mhroncok_cell> Yet I don't know whether we are past a point where it is too late to reconsider
15:14:11 <otaylor> sgallagh: I thought the point of a default stream is to not make Fedora look smaller - to keep packages in the default available set sa they are moved to modules
15:14:51 <contyk> yeah, I believe the point of defaults was to maintain the user experience, so that people don't have to care whether they install from a module or not
15:15:01 <sgallagh> otaylor: "default available set" implies heavily that it's usable by other pacakges.
15:15:02 <contyk> only having to care if they want alternative content
15:15:21 <contyk> but making those packages available as runtime deps to non-modular content is related
15:15:29 <otaylor> sgallagh: but the idea that non-modular packages could depend on modular packages at runtime -that hurts my head a bit, and seems like we could get in a situation where we're effectively pinning a set of streams
15:15:51 <mhroncok_cell> Yet it was IMHO side effect, not a purpose or the purpose
15:16:02 <otaylor> there has to be some limits - we can't have glibc effectively through transitive dependencies depending on nodejs:10
15:16:13 <mhroncok_cell> Exactly
15:16:19 <sgallagh> otaylor: I'm not sure how that would happen
15:18:19 <otaylor> sgallagh: that's probably an extreme example - but say I tried to make mozjs a module with mozjs:60, etc, streams, and had gnome-shell depend on mozjs:60 - that would be somewhat less useful
15:18:55 <otaylor> sgallagh: any usage of non-default streams of mozjs could *only* happen in a container that didn't depend on gnome-shell.
15:19:13 <sgallagh> hmm
15:19:33 <contyk> and that could be fine
15:19:45 <contyk> in such a world it's impossible to make all possible combinations work
15:19:48 <sgallagh> We're already kind of in this situation with Java though. Do we require that all packages that require Java to build or run must be in modules?
15:19:59 <contyk> if you use alternative streams, you can break some things; but you should know about that
15:20:37 <mhroncok> sgallagh: the java packages are still there
15:20:47 * nirik worries we might not notice these... perhaps just good reporting might help out.
15:20:52 <mhroncok> you don't have to care about modules to depnd on them
15:20:55 <sgallagh> mhroncok: In the sense that we had to create an emergency SIG to deal with it...
15:21:00 <mhroncok> yes
15:21:11 <mhroncok> an emergency created by this idea
15:21:33 <mhroncok> modularizing stuff that is essential for other parts of the distro
15:21:51 <otaylor> contyk: maybe that one is fine ...  we are trying to move apps to containers, after all, and gnome-shell will never be in a container. But I feel we have some limits or understanding on what is OK
15:22:00 <mhroncok> I have concerns that this was never the stated plan
15:22:34 <mhroncok> I have concerns that anybody modularizes anything based on whatever they think is better for them
15:22:48 <mhroncok> without considering other package maintainers
15:23:01 <sgallagh> mhroncok: I agree. That shouldn't be happening and we need stronger guidelines.
15:23:12 <mhroncok> we are inventing technical solution to a people problem
15:23:29 <mhroncok> sgallagh: exactly
15:23:44 <mhroncok> and we should consider not doing this at all, not allowing this
15:23:55 <mhroncok> only have modules as goodies, addons, extras
15:23:57 <nirik> thats hard in a volenteer world
15:24:06 <mhroncok> or modules that are an alternative to nonmodular content
15:24:10 <sgallagh> mhroncok: That ship has effectively sailed with the RHEL 8 Beta, for the record.
15:24:17 <contyk> I don't see this is an issue, to be honest
15:24:18 <mhroncok> rhel 8 beta is not fedora
15:24:30 <contyk> once we have the mechanisms for the buildroot in place
15:24:33 <sgallagh> mhroncok: No, but any divergence we make means twice the maintenance
15:24:44 <mhroncok> sgallagh: maybe for a red hatter
15:24:45 <contyk> the modular repo is part of the distro, it's not optional
15:24:58 <mhroncok> sgallagh: but what we do now means X-times the maintaince for everybody else
15:25:01 <contyk> whether a package is in a module or not should be irrelevant, to developers and to users
15:25:06 <sgallagh> Far better if we maintain the same code where we are effectively guaranteed that our sponsor will be funding that maintenance
15:25:28 <contyk> then whether you use an alternative stream, as a user, not everything in your system might work but you should understand that
15:25:30 <contyk> and that's all
15:25:46 <sgallagh> Not even if you use an alt stream
15:26:15 <sgallagh> Just as now (with RPM-level conflicts), it's understood that installing some packages may mean you can no longer install certain other ones.
15:26:24 * nirik wonders what the error message(s) are there.
15:26:31 <sgallagh> nirik: Where?
15:27:04 <nirik> you have foo installed that depends on module bar (default stream), you try and install baz that depends on module bar2 (alt module stream)
15:27:37 <mhroncok> Core dumped
15:27:44 <contyk> baz needs to be in a module to do that
15:27:58 <nirik> I guess we are saying that shouldn't happen now because... yeah, it would have to be modular
15:28:06 <sgallagh> mhroncok: You're probably hitting the zchunk issue. Unrelated
15:28:39 <mhroncok> sgallagh: that was an attempted joke, sorry about that
15:28:57 <sgallagh> contyk, nirik: That *is* still possible, actually
15:29:28 <nirik> if it is thats fine, as long as the error(s) are good... ie, it tells you whats happening so you can decide what you want to do
15:29:32 <sgallagh> baz could depend on mbar (default stream) which in turn depends on bar2 (alt module stream)
15:30:04 <contyk> yeah, but that's modular content depending on modular content
15:30:06 <sgallagh> At which point you'd get a conflict from DNF and be told no
15:30:15 <nirik> anyhow, I'm ok with the buildroot plan, not sure we are going to solve all the corner cases today.
15:30:26 <sgallagh> Sure, I just wanted to mention that it's possible to hit the scenario nirik mentioned
15:30:35 <contyk> it's indeed all about error reporting; you can get in all kinds of situations, with or without modules
15:30:37 <sgallagh> Just ursine->module->module rather than ursine->module
15:31:30 <otaylor> contyk: its not just about error reporting, it's about making sure there's a clear path forward ... that people can do what they need to do
15:33:40 <otaylor> contyk: if a developer ships  a module that depends on a non-default stream, there has to be some way of running it that doesn't involve directly installing it on your system - in a container / Flatpak.
15:34:27 <otaylor> contyk: (and we have to make sure that core packages that that container / Flatpak would depend on don't have module dependencies on default streams that would cause problems)
15:34:51 <otaylor> contyk: and we have to make sure that the user can find that alternate way of running it, and it seems natural and convenient
15:36:01 <otaylor> with default modules, in fact, we've basically reinvented Fedora Rings :-)
15:36:30 <mhroncok> except stuff from the inner ring depends on the outer ring
15:37:33 <smooge> and the outer ring depends on stuff we don't ship
15:37:33 <otaylor> mhroncok: I'm saying that we actually need to keep stuff from the inner(most) ring from depending on the outer ring - we need implicit structure to the distro
15:38:45 <mhroncok> yes, we do
15:40:19 <mhroncok> anyway, I have a ticket drafted from friday, but I haven't got time to propose it yet
15:40:32 <mhroncok> it touches those topics
15:42:20 <sgallagh> OK, we've been on this topic a while and aren't really getting anywhere. Punt until mhroncok provides his counter-proposal?
15:43:07 <mhroncok> punt
15:43:43 <mhroncok> (I'm +1 to the proposal technically, iff this is what we actually want to do.)
15:43:55 <jforbes> +1 punt
15:45:10 <otaylor> contyk:  do you you feel that moving forward with a solution is being pushed off? I think there are interesting questions to be discussed, but the basic outline is fine as a technical solution
15:45:16 * nirik is +1 to the buildroot proposal. We may need more discussion/guidelines/work after that, but it's a needed and good step
15:46:08 <sgallagh> Yeah, I feel like we should solve the buildroot situation and then limit the situations where it is allowable
15:46:21 <contyk> I think we all agree with the proposal on a technical level
15:46:29 <mhroncok> pretty much, yes
15:46:39 <mhroncok> except I don't want to allow this at all
15:46:45 <contyk> if FESCo alter decides that modules should not be part of the distro on this level, I think it pretty much kills the technology
15:46:48 <mhroncok> problem is, we already have such situations
15:46:54 <contyk> but that would be a group decision
15:47:37 * mhroncok would rather kill a technology than a community
15:47:50 <contyk> so would I
15:47:58 <contyk> but I actually see this as beneficial
15:48:47 <nirik> well, the java stack maintainer sure thought it was better than maintaining the streams of non modular packages.
15:49:01 <mhroncok> for him, it was
15:50:25 <jforbes> I think that is the problem, for him it was, for everyone with deps on those streams, it was not
15:50:37 <nirik> seems to me it's only a burden on others because we don't have this solution in place?
15:50:49 <jforbes> possibly, yes
15:50:50 <sgallagh> nirik: Yeah, I think that's the case.
15:51:05 <sgallagh> Had they come to us at the time, we'd have asked them to wait until we had this solved.
15:51:24 <mhroncok> the technical solution for this is band aid
15:52:05 <mhroncok> it hopefully helps with this particular problem, yet it creates room for more problems
15:52:29 <sgallagh> mhroncok: There will always be more problems.
15:52:38 <mhroncok> sure
15:53:19 * otaylor doesn't feel he really *understands* the java modularity plan, what the design was, how it interacts with the rest of the distro, etc.
15:53:30 <sgallagh> otaylor: I don't either.
15:53:41 <sgallagh> contyk: Did they consult with you on it?
15:53:46 <mhroncok> I think I understand the plane, but I don't want to be rude :(
15:53:50 <jforbes> I am not sure "pan" is the right word
15:53:53 <mhroncok> plan
15:54:16 <contyk> nope
15:54:17 <nirik> well, the problem was there is/was 1 person doing everything... they couldn't keep doing that, so they moved to modules with all the stuff they maintained to reduce burden.
15:54:48 <mhroncok> it would be perfectly fine be me to say: I cannot handle this any longer, hence I orphan it
15:54:49 <contyk> but I think the goal is to have the common build deps for actual applications in this javapackages module
15:54:55 <nirik> I guess they might have assumed we would solve the building against modules problems before things were retired.
15:55:07 <mhroncok> yet the message was: fesco is blocking ura major, hence I orphan this and it's not my problem any more
15:55:16 <contyk> and build it just once on the oldest distro and then consume it everywhere, because bytecode
15:55:22 <nirik> contyk: yes, and not publish those, since they only intend to support them for building the applications they support
15:55:30 <contyk> yes
15:55:39 <otaylor> nirik: I understand the story, but how exactly ... is this related to openjdk versions? what's the stream strategy? do all things in the distro need the same stream? how is the default stream going to be handled?
15:56:02 <otaylor> nirik: I underrstand the story that somehow modularity is reducing the maintenance burden, I mean
15:56:09 <mhroncok> some of the packages there ar eno even in any moduel
15:56:24 <mhroncok> are not even in a module
15:56:44 <nirik> otaylor: I don't know specifics to that level... would need to ask them.
15:56:45 <sgallagh> otaylor: The default stream is set for the life of a Fedora release. So once the buildroot solution is in place, it can be relied on to be the same within a release.
15:57:00 <mhroncok> I wonder how a provenpackager doing a mass change in rawhide would solve this "one branch for everything" concept
15:58:05 <mhroncok> as currently they just wouldn't
15:58:14 <mhroncok> and that is indeed less burden for the maintainer
15:58:17 <otaylor> basically, the Java change needed a change proposal and a document, not just doing it. And I think we really need to ask for the document retroactively, at least so that we can try to figure out how we handle similar situations going forward
15:58:19 <sgallagh> mhroncok: Could you rephrase? I don't understand what problem you're seeing
15:58:20 <nirik> well, depends on the change...
15:58:37 <mhroncok> it just moves the burden to everybody else
15:58:45 <otaylor> (maybe there is such a document somewhere)
15:59:14 <mhroncok> sgallagh: so we decide we need to ditch ldconfig scriptles from the distro - and that we do it in rawhide - but we cannot do it in the modular branch
15:59:30 <nirik> we could, it would just be more work...
15:59:34 <mhroncok> because it possibly also builds for epel 5 and debian
15:59:58 <mhroncok> nirik: exactly - the burden is moved, it is not gone
16:00:32 <mhroncok> so for sure, moving my packages to modules may make sense to me - the others will need to care, I won't
16:00:36 <nirik> well, the burden has always been on people making changes...
16:00:43 <sgallagh> mhroncok: That particular problem is one that mboddu and I have been discussing.
16:00:52 <sgallagh> There are ways we can know which branches are applicable.
16:01:01 <mhroncok> ways and hacks
16:01:08 <nirik> ie, you change someones rawhide spec and they change it back because they build also on epel5 and debian. ;)
16:01:22 <mhroncok> nirik: and I can rant against them on devel
16:01:36 <mhroncok> and everybody else agrees we cannot change that but they are doing wrong
16:01:55 <mhroncok> yest with modularity, the answers is: meh
16:02:21 <sgallagh> The answer is not "meh", the answer would be "Here's a guideline on how to conditionalize your spec correctly"
16:02:46 * otaylor seems to have derailed the plan to punt this discussion to next week ...
16:02:48 <mhroncok> you should not need to conditionalize
16:02:58 <sgallagh> also, using the Straw Man Fallacy as your primary argument is tiresome
16:04:11 <mhroncok> sorry about that, it is not intentional
16:04:37 <sgallagh> mhroncok: Yes, there are many ways to solve a problem. Scrapping years of work because of an edge-case that happens to affect you more than most seems like an overreaction to me
16:04:41 <mhroncok> as said, the technical proposal is good - I just don't agree we should do this kind of stuff at all - we should limit it to very exceptional cases at least
16:05:40 <nirik> so, we would solve the retirement of java packages by... forcing stewardship-sig to maintain them forever?
16:05:51 <mhroncok> sgallagh: this didn't affect just me - I have an impression that the people we are suppose to represent here are genuinely afraid and confused
16:06:02 <otaylor> mhroncok: I dont' think we have a lot of time leeway here, so if you want to make a concrete proposal as alternative to just moving forward we should definitely vote on that next week
16:06:07 <sgallagh> mhroncok: I didn't say exclusively. I said "you more than most"
16:06:13 <nirik> yes, but because we don't have this in place... not because it's a bad idea
16:07:00 <mhroncok> nirik: probably not by forcing the stewardship sig - e.g. again we cannot force anybody to do anything
16:07:10 <sgallagh> And the Java situation is pretty much the worst-case-scenario.
16:07:23 <sgallagh> (No points for jokes about how that's not unusual)
16:07:23 <mhroncok> but we can stop people doing crazy stuff like deciding to modularize glibc
16:07:27 <nirik> well, worse would be just retiring it all.
16:07:58 <sgallagh> mhroncok: Yeah, I completely agree with you that there should be lines drawn somewhere.
16:08:22 <mhroncok> sgallagh: ok and we might have different ideas about where the line should be
16:08:26 <sgallagh> But we *know* from past experience that no firm lines are possible
16:08:39 <sgallagh> We tried that with Modularity 1.0 and had to abandon it because it wasn't realistic.
16:08:49 <sgallagh> Too many things are interrelated
16:09:21 <mhroncok> my understanding of modularity 2.0 always was that such line would move further away from "the core" not that it goes away
16:09:25 <sgallagh> Maybe the answer is "nothing ursine can *runtime* depend on a module stream". Maybe it's somewhere else.
16:09:50 <mhroncok> and my concern is that I think we should (at least attempt to) draw that line
16:09:50 <sgallagh> mhroncok: The disaster that is sphinx is a good metaphor for the problem.
16:09:55 <mhroncok> before it's too late
16:10:04 <smooge> I think the issue is that java is a canary. we have various other languages which are on a 'few' maintainers who are overburdened and looking for anything to cut down maintenance.
16:10:21 <sgallagh> mhroncok: Half the distro depends on sphinx at build-time, indirectly
16:10:27 <smooge> perl could have been just as easily gone all modular
16:10:44 <sgallagh> And did, in RHEL 8.
16:10:59 <smooge> and now for EPEL-8 I need to look at making all the rest modular
16:11:06 <nirik> along with python and many other things. ;)
16:11:33 <otaylor> smooge: I'm still uncertain on the mechanism where modularity cuts maintenance  for a language -  it is it just stream expansion to cut (many packages) * (many branches) work?
16:11:55 <sgallagh> otaylor: That's one example
16:12:02 <smooge> otaylor, the idea is that I will work on stream0 and it will build for F29/F30/F31
16:12:07 <nirik> that and ease to moving to new streams without committing...
16:12:15 <sgallagh> otaylor: In the case of a lot of golang stuff, you only need to build it once and tag it to run on multiple releases
16:12:32 <nirik> or rust
16:12:39 <sgallagh> Right
16:13:15 <otaylor> Which shows there is another intersection with the idea of distribution structure - since core stuff *should not* just update across all streams of Fedora
16:13:27 <smooge> so for a maintainer who has hundreds of packages (*spot*) it would make sense to put it all in a module and deal with it once
16:14:43 <otaylor> while we don't have hard-and-fast rules about backports, it would be pretty bad if there suddenly started to be a pile of Python updates in F28 because F28 was pulling a default stream of Python that is being updated
16:14:46 <smooge> the issue is that stuff depends on a growing mass of more stuff
16:15:10 <nirik> would a 'spots-grab-bag' module be allowed? I think we now require them to be a application/lang/something related? or do we?
16:15:31 <mhroncok> AFAIk we don't require anything at all
16:15:36 <nirik> otaylor: sure, but you can leave f28 on an old stream and make a new one for newer
16:16:10 <sgallagh> nirik: I don't think we should allow that situation, no.
16:16:22 <sgallagh> A module should be logically linked somehow.
16:16:33 <nirik> huh, I don't actually see the java ones in rawhide...
16:16:40 <sgallagh> e.g. it makes sense to link 389ds, kerberos, SSSD and dogtag together as FreeIPA
16:17:00 <smooge> so spots grab-bag would be 'everything I need to make chromium'
16:17:21 <sgallagh> Well, anything that fit into "deps and builddeps of chromium" makes sense.
16:17:26 <otaylor> smooge: but something needed to make chromium could end up being a dependency of a bunch of stuff in the distro
16:17:30 <sgallagh> But I'm pretty sure that's a subset of spot's packages
16:17:38 <smooge> yes it is.
16:18:00 <mhroncok> so we can stick python2 in that module and retire it form rawhide?
16:18:03 <smooge> but some of the things he has are build-deps of build-deps of build-deps of chromium
16:18:04 <mhroncok> for example
16:18:14 <sgallagh> otaylor: right, and best practice would be to try to keep the module contents limited to those things that are exclusively for chromium
16:18:19 <sgallagh> But you're right, we need better documentation about this
16:18:38 <otaylor> smooge: if they are chromium specific , they can be in  a chromium module, but they then probably *should not* be in the buildroot for non-modular packages
16:18:57 <sgallagh> mhroncok: Short answer: no. Longer answer: we need to describe things better.
16:19:15 <smooge> otaylor, sgallagh so let me use strawman-spot a bit further
16:19:49 <smooge> for strawman-spot he only wants those packages so he can build chromium.. so to him they ARE chromium specific
16:19:49 <mhroncok> poor spot
16:19:59 <smooge> this is what happened in java
16:20:37 <smooge> and could happen with other packages where a person has a specific end leaf and got all these other packages because no one else took them and they needed them
16:20:48 <sgallagh> The answer there is that if someone wants to maintain them for additional purposes, they should “adopt” them from spot and take over their maintenance.
16:21:19 <otaylor> smooge: I think it's pretty clear that the Java peopel were aware that there were a lot of more packages in Fedora that used java as build dependencies, and they weren't trying to say that 'ant' or whatever was just for them
16:21:36 <otaylor> smooge: or that they wanted to give up maintenance of 'ant'
16:21:49 <otaylor> they just didn't want to maintain it, *as is*
16:22:45 <smooge> I didn't see it that way but I will accept I am probably mis-seeing it
16:24:18 <smooge> sgallagh, the issue is that if people should adopt such packages, we need to make it clear to packagers in both tools and policies what they should do
16:24:31 <sgallagh> I do not disagree.
16:24:42 <smooge> at the moment we have the horse about 40 feet behind the cart
16:24:47 <sgallagh> I am also not prepared to decide what those policies are in the next five minutes
16:24:53 <sgallagh> (And I have another meeting to get to then)
16:25:08 <nirik> well, not sure we can force people to maintain things beyond the scope they want to...
16:25:34 <nirik> is it better to orphan something or to 'maintain' it and ignore everything about it except what you need to build your other package?
16:25:41 <sgallagh> If someone wants to take over as chair, feel free to keep running around this track.
16:26:09 * nirik isn't sure what thing we are trying to solve now anyhow. :)
16:26:22 <sgallagh> nirik: Putting a package into a module and not listing it as "api" of that module is meant to be how you indicate the latter.
16:26:31 <smooge> sorry for another run around the track. I will get off the track now
16:26:31 <sgallagh> So that people understand it's not in the distro for general usage
16:27:10 <nirik> now it is sure... but thats not been an option until very recently
16:27:19 <sgallagh> If it's truly build-time-only, it should also be added to the "filter" list so it doesn't end up in the compose
16:27:43 <sgallagh> Hooray for improving on that?
16:28:36 <sgallagh> Anyway, I need to be going. Does someone want to take over or shall I close the meeting?
16:28:48 <mhroncok> +1 to closing
16:30:07 <nirik> +1 to close
16:30:17 <contyk> and sgallagh volunteered to chair the next meeting because there was nothing to discuss today
16:30:23 <contyk> +1 to close
16:30:51 <jforbes> +1 close
16:31:05 * sgallagh snickers
16:31:08 <sgallagh> #endmeeting