15:14:03 #startmeeting Stewardship SIG Meeting (2019-10-29) 15:14:03 Meeting started Tue Oct 29 15:14:03 2019 UTC. 15:14:03 This meeting is logged and archived in a public location. 15:14:03 The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:14:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:14:03 The meeting name has been set to 'stewardship_sig_meeting_(2019-10-29)' 15:14:10 #meetingname stewardship-sig 15:14:10 The meeting name has been set to 'stewardship-sig' 15:14:13 decathorpe: \o 15:14:28 hey! sorry, DST is messing up my schedule 15:14:33 decathorpe: You're fine. :) 15:14:59 #chair cipherboy 15:14:59 Current chairs: cipherboy decathorpe 15:15:02 #chair mhroncok 15:15:02 Current chairs: cipherboy decathorpe mhroncok 15:15:06 hey 15:15:33 #link https://pagure.io/stewardship-sig/issue/57 15:15:45 what do you want to talk about first? 15:17:17 I think the first item we all agree we've looked at and there's no immediate action on our part, correct? 15:17:20 maevn/ant 15:17:42 yes, I think it should not impact our packages. mizdebsk confirmed as much 15:17:53 bytecode should be compatible with OpenJDK 8 15:18:03 mhroncok: Do you have any concerns about the migration? 15:18:45 my main concern is that it keeps me totally confused 15:19:00 they want to change the default stream for this openjdk 11 build 15:19:06 but ti should be parallel installable? how? 15:19:32 I've looked at the maven spec. it provides different *binary* packages 15:19:43 e.g. maven-3.6-maven or something, vs. non-modular maven 15:19:48 but does it block maven form being installed? 15:20:03 according to mizdebsk, it should not. 15:20:18 once that work is finished, anyway. 15:20:56 So then `BuildReq: maven` will just work and should pull in ursine Maven even with modularity / Ursa {Prime,Major,*} installed? 15:21:04 *s/?/./ 15:21:08 I think so. 15:21:27 "enabling uras major now will amke everything FTBFS" 15:21:32 *make 15:21:53 yes, right now. because the "making things install in parallel and not block stuff" isn't done yet, IIUC 15:22:03 ah 15:22:36 but don't quote me on that ... I barely understand whats going on anymore 15:24:15 that's my main issue 15:24:21 +1 15:24:53 I don't get the "make things simpler for packagers" angle of modularity :D 15:25:11 decathorpe: Its for the owner of the module only I think. 15:25:51 * decathorpe shrugs 15:26:06 anyway, as a sig, we ocntinue to miantain the stuff that was promissed to be fixed eventually in modularity but never will, correct? 15:26:53 mhroncok: I don't think it's a long-term solution, but until then, yes 15:27:45 Yeah, I think we need to keep pruning deps. 15:28:09 ok, move n... nothing to o here but cry 15:28:16 :') 15:28:23 :') 15:28:29 yeah ... 15:29:06 #topic Breaking glassfish-jaxb 15:29:33 I've opened a PR to minimize the glassfish-jaxb build. it drops subpackages that are currently only in use by already broken packages ... 15:29:42 I don't like kicking dead packages more than we need to, but at the same time, there's more than just our few packages that need to be maintained for this. 15:30:20 right. I mean, we can wait a bit longer, until it doesn't matter anymore for the affected packages (because they're going to be retired or fixed) 15:30:39 decathorpe: One question: does glassfish-jaxb continue to build fine or is this minimization required for subpackages to keep building? 15:31:06 the package is fine. it just pulls in a lot of deps 15:32:38 Hmmm, ok. Let's leave it alone until the other packages FTBFS due to other missing deps, then we can prune ours. 15:32:54 yeah, I agree 15:32:59 Well, see what is happening and if those maintainers are picking up the deps or not. If they're not in say, ~2 weeks, then we can prune glassfish-jaxb. 15:33:09 * decathorpe shrugs 15:33:28 #topic resteasy and its deps 15:34:05 So picketbox can be retired, and a few others you mentioned. So you want me to just hand off all the listed packages to the SIG and we can re-run our leaf check? 15:34:11 cipherboy: I've got a script running that will tell me which packages you can orphan right away. the rest you can sign over to the SIG, and we'll do the rest of the cleanup 15:35:03 ACK, PM me the list and I'll send the rest over. 15:35:21 great :) 15:35:25 #topic Open Floor 15:36:22 I don't think we need to talk about open PRs in the meeting, do we? 15:36:43 (sorry, got disctracted, reading the log) 15:37:05 Nope, I think we're good on that. 15:37:08 mhroncok: you didn't miss much 15:37:28 yeah. I marked the "bad" ones as WIP, the rest is ready for review 15:39:06 ACK, ty. Will do. 15:39:54 great, thanks :) 15:40:00 anything else? 15:41:10 Something crossed my mind but I got distracted by my other meeting and I forgot what it was. 15:41:15 Give me a second to try and recall. 15:41:28 oh meeting is here. Hello \o 15:41:37 hello :) 15:41:41 #chair sillebille 15:41:41 Current chairs: cipherboy decathorpe mhroncok sillebille 15:42:02 decathorpe: Ah, JBoss stuff. Should I still poke Packit + JBoss teams to see about adding Packit to some of our non-leaf JBoss packages? 15:42:25 is that an upstream thing? 15:42:30 They've been waiting for about a month for us to packge resteasy. The first question is if JBoss supports our version of resteasy or if we need to update that too. 15:42:59 decathorpe: Packit needs to be integrated in upstream JBoss packages and then we can hopefully use it in the SIG to simplify packaging when they release new versions. 15:43:17 define simplify. I've never used packit before 15:43:26 decathorpe: Now, mhroncok wasn't thinking it'd be that helpful, but at least having a single package to test with would be nice. :) 15:43:59 can it file PRs for new releases? 15:44:23 decathorpe: My understanding is that we can take our existing spec, Packit will merge it with new upstream sources and do test builds, so upstream knows if they break something. I think it'll also help us and do part of the work of rebase for new releases, but I'm not sure if that's as automatic as a PR against dist-git or if we have to run the tool manually and then do the PR ourselves. 15:44:40 heh. okay 15:44:51 if you want to try, go ahead 15:45:14 decathorpe: So as we keep pruning deps (and upstream keeps adding them), we'll at least know what failed at a time closer to "when" it occurred -- so we hopefully can find out what failed sooner, but again, this is off my reading. 15:45:33 decathorpe: Having an example of what it can do would be nice, which is why I want to try it on at least _one_ JBoss package. :) 15:45:45 We can always say "no thanks" later and JBoss can remove it and we can ignore it. 15:45:53 cipherboy: yeah, that sounds like a plan 15:46:02 if it helps, keep it. if it doesn't, drop it 15:46:11 decathorpe: ACK, ty. :) 15:46:45 by the way, I've added `jgit` as one of the packages we want to keep working, as per mbooth's request 15:47:01 IMHo thay have asked at the upstream project github issue to onboard it at packit and there was no reply 15:47:07 but I might have missed it 15:47:21 mhroncok: that wouldn't surprise me 15:47:50 mhroncok: Right, JBoss sent me a mail internally about it, I told them we were still waiting on resteasy to finish up, which is well, now. :) 15:48:32 mhroncok: So I'll tell Packit and JBoss that we're done fixing up resteasy and we can try Packit now. 15:48:42 ack 15:48:50 cipherboy: do these people actually want a working JBoss / WildFly stack on fedora? 15:49:18 because most of it has been retired already 15:49:29 decathorpe: Largely the answer is that they don't have that as a goal. 15:49:54 decathorpe: In other words, they don't care either way. 15:50:09 * decathorpe sighs 15:50:16 well then I don't care either :) 15:50:30 :) Right, I don't think we ever wanted a full JBoss / WildFly stack. 15:51:24 right. because we only need a small subset of their libraries 15:51:49 So I think that about covers it from my end. :) 15:51:58 me too 15:52:11 mhroncok, sillebille: anything you want to mention before we end the meeting? 15:52:40 not really 15:52:41 no sir. Everything looks good to me :-) 15:52:54 ACK 15:52:59 thanks guys :) 15:53:02 #endmeeting