15:00:00 #startmeeting FESCO (2018-11-19) 15:00:00 Meeting started Mon Nov 19 15:00:00 2018 UTC. 15:00:00 This meeting is logged and archived in a public location. 15:00:00 The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:00 The meeting name has been set to 'fesco_(2018-11-19)' 15:00:03 #meetingname fesco 15:00:03 The meeting name has been set to 'fesco' 15:00:05 #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:00:05 Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek 15:00:06 #topic init process 15:00:11 morning 15:00:20 .hello2 15:00:21 maxamillion: maxamillion 'Adam Miller' 15:00:22 .hello2 15:00:24 jsmith: jsmith 'Jared Smith' 15:00:34 hi 15:01:14 .hello2 15:01:15 sgallagh: sgallagh 'Stephen Gallagher' 15:01:17 (sort of) 15:01:28 .hello2 15:01:29 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:03:03 I actually don't have a conflict in this time slot this week \o/ 15:04:29 i've got a roofer coming probably during this meeting 15:04:43 i sent my IRC-friendly agenda notes to the fesco list 15:04:48 (Apologies for missing the meeting the last couple of weeks -- ${DAYJOB} has been crazy) 15:04:51 can someone take over when/if that happens? 15:05:10 bowlofeggs: I'd be happy to 15:05:15 we have 6 so we should be able to keep quorum if i need to leave 15:05:19 cool 15:05:27 also i probably don't need to spend that much time with the roofer 15:05:35 so might just disappear for 5-15 min or so 15:05:40 alright, let's get this party started 15:05:53 #topic #1970 Long orphaned packages are not being retired after 6 weeks 15:05:56 .fesco 1970 15:05:58 bowlofeggs: Issue #1970: Action needed: Orphan packages will be retired if they remain orphaned for six weeks - fesco - Pagure.io - https://pagure.io/fesco/issue/1970 15:06:31 mhroncok: you are up! 15:06:35 thanks 15:06:46 We desperately need a volunteer to implement this 15:07:11 so, my questions is: who is responsible for delivering such policies? is it FESCo, otr FESCo just creates the policty and taht's it? 15:07:33 I don't think there's any rule that would always apply 15:07:36 are individuals allowed to act on the policy? = retiure packages 15:08:00 or do we need to formally say how is this policy implemented? 15:08:03 mhroncok: Strictly speaking, FESCo's job is to make the policy. In practice, it has usually been a FESCo member that has ended up implementing it to. 15:08:05 *too 15:08:18 i don't think it has to be fesco implementing it 15:08:26 but ACLs may be a problem for most people 15:08:29 Once the policy is created, I don't have any problems with someone stepping up to do the enforcement. 15:08:36 We should/need/do always consider implementation posibilities when setting a policy 15:08:38 (FESCo can play referee if there are disagreements) 15:08:41 sgallagh +1 15:08:57 sgallagh: +1 15:09:10 indeed. 15:09:23 In this case, it'd be good to have this automated and run by releng, so that it keeps happening without depending on a single individual 15:09:38 zbyszek: that would be nice, but should not block this 15:09:44 Yes, sure. 15:09:52 anyone can retire orphaned packages IMHO but doing so on a large scale needs to be done responsibly 15:09:53 Right, but if mhroncok wants to write the tool that releng adds to its automation, I'm all in favor 15:09:55 I know till had some script to geenrate the reports 15:10:04 I try to talk to him 15:10:32 consider me volunteering to do the thing 15:10:35 mhroncok: in particular, I think it is better to do it "manually" now, then never 15:10:37 the scripts for the reports are in the releng git repo 15:10:47 tyll: thanks 15:10:49 mhroncok++ 15:10:49 thats excellent. thank you mhroncok. 15:10:51 #action mhroncok volunteers to script the package retirements 15:10:55 mhroncok++ 15:10:55 zbyszek: Karma for churchyard changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:10:59 anything else on this topic? 15:11:00 mhroncok++ 15:11:00 sgallagh: Karma for churchyard changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:11:13 but the latest decision was to re-assing the currently orphaned packages first, there is no script for that 15:11:24 at least nothing that is fully ready 15:11:27 even tho some things have been orphaned a while, another report run would eb good. 15:11:40 sgallagh: to retire the packages (I'll start somehow manually and that see what can be automated) 15:11:52 (so nothing unexpected gets orphaned thats needed) 15:12:03 another problem is that it is not really clear if co-maintainer are properly notified if a package is orphaned 15:12:04 "but the latest decision was to re-assing the currently orphaned packages first" 15:12:15 I'ma afraid i cannot do that, don't have the powers 15:12:29 IV'e requested some rights form releng months ago, nothign happened 15:12:31 mhroncok++ 15:12:31 maxamillion: Karma for churchyard changed to 5 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:12:42 tyll: at one point we had it just reassign to one of them... perhaps that would be better than orphaning 15:12:44 mhroncok, if you provide the script I am happy to run it 15:12:57 are special powers needed to find out which packages are orphaned? 15:12:59 tyll: noted 15:13:04 #undo 15:13:04 Removing item from minutes: ACTION by sgallagh at 15:10:51 : mhroncok volunteers to script the package retirements 15:13:06 bowlofeggs: nope, taht i can 15:13:23 oh you mean to mass retire 15:13:25 also, I think that if we notify all comaintainers 15:13:26 #action mhroncok volunteers to retire the packages manually and see what can be automated 15:13:34 and they not claim the package anyway 15:13:37 yeah notification would be great 15:13:43 we shoudl retire it, not force it to them 15:13:54 +1 15:14:33 mhroncok: I think reassingment is much better, because if you are an co-maintainer of a package, you presumably care about it 15:14:53 zbyszek: well, strictly speaking it means you cared about it once upon a time 15:14:53 Just retiring it could be a rude surprise 15:14:56 mhroncok, it is not really forced on them, because they can also drop their maintainership if they do not want the package 15:15:04 tyll: exactly 15:15:46 the point I'm trying to make is: ... 15:15:58 It'd be better for the distro as a whole to encourage co-maintainers to opt-out, rather then retiring massive amounts of packages 15:16:08 i agree with zbyszek 15:16:14 likewise 15:16:36 * nirik nods. 15:16:38 if we send notifications to them (the list of orphaned packages) and they do not care enough to claim the package, they are most likely ignoring it and reassigning to them only postpones the retirement and waits for another nonrepsonsive process to happen 15:16:40 it's pretty tough to juggle all the notifications sent as it is 15:16:53 and some of them simply just aren't sent, so I'd rather err on the side of caution here 15:17:25 there are packages "maintained" by 10 nonresponsive maintainers 15:17:34 mhroncok: but if the process is running again, this would be just a few weeks more. I think that's acceptable, especially that we're starting the process again after a long break. 15:17:46 well, if there's 10 maintainers perhaps all 10 think someone else will take it... 15:17:59 zbyszek: but the package won't be orphaned, it will not run again until somebody notices 15:18:03 mhroncok, IMHO the problem with nonresponsive maintainers needs to be fixed by removing the non-responsive maintainers from all packages 15:18:30 mhroncok: You have a point. So maybe only do the reassignment if the package was committed to within last 6 months or so? 15:18:36 alright folks, I gotta jet for a few minutes 15:18:41 I'll be back in ~15 minutes or so 15:18:51 bye 15:19:02 I.e. orphan if package is "not alive", and reassign to last maintainer otherwise? 15:19:09 zbyszek: anywat the policy says somehting. I'll gladly try to help here, but we need to be on the same page of what supposed to happen 15:19:16 zbyszek, if the co-maintainers are inacurate, then it should be fixed instead of working aroud it IMHO 15:19:58 "Orphan packages will be retired if they remain orphaned for six weeks." 15:20:15 we've been on this topic for 15 minutes now - do we want to keep going, or move discussion back tot he ticket? 15:20:17 mhroncok, IMHO the hard part of the current situation is that nobody knows if co-maintainers are notified when a package is orphaned (I believe they are not) 15:20:18 if you feel that this is too bad, than fine, but change it 15:20:24 Let's continue. 15:20:27 tyll: they are not 15:20:39 therefore before surprising everyone, it should be properly communicated before retiring on a large scale 15:20:48 agreed 15:20:51 Yes, I think this is a requiremnet. 15:20:54 (and other want to mvoe on) 15:20:58 *others 15:21:02 Can we get an auto-mailer out once a week to any package that is orphaned which has comaintainers? 15:21:06 "It's OK to be disappointed, it's not OK to be surprised!" 15:21:08 That can't be too hard, can it? 15:21:39 the hard part is telling which are retired already I think... 15:21:46 what nirik wrote 15:22:02 * bowlofeggs misses pkgdb 15:22:03 nirik: why? Just look for dead.package in dist-git? 15:22:08 it is really slow to figure out which packages are only orphaned currently 15:22:12 nirik: I have a code for that 15:22:36 zbyszek: sure, but thats a pretty heavy query 15:22:54 nirik: but it runs once per week, no? 15:22:59 my idea was that the "executioner" (me?) would keep sending e-mail (once a week maybe?) with the plan for next week, CCing all the comaintainers and dependent comaintainers 15:23:13 that sounds good to me. 15:23:18 the period can be longer 15:23:23 mhroncok: i would recommend making the executioner be cron ☺ 15:23:31 bowlofeggs: sure, I meant for now 15:23:34 ack 15:23:41 * sgallagh makes a note to buy mhroncok a black hood for Christmas. 15:23:46 hahaha 15:23:47 do we first want to re-assign the currently orpphaned packages or not? If not, I can probably get the old report running again, but it affects a lot of packages 15:23:50 and if people get suprised by having a package retired, well they can unretire it 15:24:13 Honestly, I'd actually prefer we just go ahead and do the retirement. 15:24:25 If the package is actually cared-about, they have what, two weeks to unretire for "free"? 15:24:32 oh that's true 15:24:38 sgallagh: exectly 15:24:40 Then after that, if it needs to come back, I'd be happy with the re-review 15:24:41 sgallagh, unretiring is an awefule manual releng process 15:24:42 you only have to do the re-review if it's been retired for a while 15:24:50 (AFAIK) 15:25:03 ackages that are retired for Rawhide for more than two weeks need to be reviewed again before they can be un-retired. This is also true for EPEL-only packages. 15:25:06 so much of releng is manual now, due to pkgdb retirement :/ 15:25:20 mhroncok: can you wait let's say 3 weeks before retiring (with weekly email)? So that maintainers have more than a week to respond? 15:25:26 if you give me rights to do manual unretirement, I'm willing to do that as well 15:25:35 zbyszek: sure 15:25:40 couple weeks are OK 15:25:40 mboddu: Can you comment on what unretirement entails? 15:25:48 the problem here is that we have packages orpahned for years 15:25:50 needs unblocking in koji 15:25:55 which requires koji admin 15:26:09 proposal: give right to mhroncok to reassing ownership of packages and unretire packages (koji admin and whatnot) 15:26:18 it also needs some checks to ensure that the request is valid 15:26:26 i wish src.fpo had features to do this stuff 15:26:30 Also, reverting the changes in dist-git 15:26:31 that would be real nice 15:26:40 bowlofeggs, you mean it would be pkgdb? 15:26:46 I don't think we need to worry about unretirement unless it becomes a problem. 15:26:47 tyll: haha yep 15:26:47 tyll: :D 15:27:22 nirik: right, i don't think it will be an unretirement zombie apocalypse 15:27:34 nirik: with this number of packages, let's be "forward looking" and assume there will be a problem ;) 15:28:06 we are at ~500 15:28:07 so what do we need to figure out today? 15:28:21 In short, koji unblock, dist-git revert of retirement commit, giving the package to the requestor, verifying the unretirement BZ request 15:28:29 sounds like mhroncok is willing to take the lead on writing some code to help automate this 15:28:29 three months ago about 1000 pkgs were candidates to be retired 15:28:48 whoah that's so many 15:28:52 tyll: so we assume people took care of them becasue of the announcment? 15:29:24 sure they did! :) 15:29:38 mhroncok: you forgot to put a smiley 15:29:39 mhroncok, there were a lot tickets to get pacakges at releng 15:30:05 nice 15:30:10 we've now been on this topic for 25 minutes - do we want to keep going or move discussion back to the ticket? 15:30:23 bowlofeggs: I think we're 95% there 15:30:38 what remaining question(s) do we want to answer in this meeting? 15:30:58 I want an answer to my proposal above, i.e. giving permissions to mhroncok 15:30:58 are we aiming at policy change or not? 15:31:11 to me it is still unclear if we want to re-assign orphaned packages first to co-maintainers or not 15:31:23 i.e. is it reassign to comaintainer or retire (with a lot of warnings perhaps)? 15:31:54 I guess I don't object to adding mhroncok as a koji admin, but I am against changing the process without a plan. 15:31:54 I vote retire. 15:32:07 Retiring is in agreemnt with the policy, so I don't think we actually need to change any poliyc. 15:32:24 I vote retire too. 15:32:30 unless you want reassigning and in that case a policy change is IMHO required 15:33:00 No, reassign-with-warnings sounds perfectly OK and easier to implement. 15:33:10 ok let me try to state the remaining questions: 0) vote on zbyszek's proposal (can you restate it?), 1) re-assign vs. retire immediately (is this the same as "policy change"?) 15:33:12 hopefully any packages with active comaintainers would take the package in the 3 weeks of reports before they retire. 15:33:46 bowlofeggs: The current policy says "retire". 15:34:21 I just lit the microwave on fire on accident ... brb 15:34:27 Let's make sure those reports get sent to individual package-owner@ aliases? 15:34:42 it doesn't say "retire immediately" so waiting 3 weeks after announcement is perfectly fine 15:34:46 back 15:34:53 maxamillion: be safe 15:34:54 i see a lot of people voting to keep the policy the same as it is (retire) - any objectors? 15:35:23 sgallagh, my reports went to the FAS@fpo address to avoid people getting too many copies of the same e-mail 15:35:49 proposal (1): The policy to retire packages after six weeks of being orphaned is reaffirmed. At least three warnings with one-week intervals will be sent out to co-maintainers before retiring. 15:35:53 proposal (2): mhroncok gets koji admin rights to be able to drive the retirement process and any unretirements if necessary. 15:35:57 tyll: My thought was that the owner@ address is a handy reply-all so they can sort out who would take it. 15:36:05 I'd recommend suggesting that in the email sent out 15:36:19 +1/+1 15:36:20 +1 to 1... 2... I would prefer that be restated... 15:36:34 nirik: Patch for prop 2? 15:36:41 nirik: please restate then, I know nothing about the permission model here 15:37:01 mhroncok is added as a release engineer to process unretirement requests (which are still the same process as now, file ticket, it gets checked, etc) 15:37:10 (note that as a provenpackager, I can retire anything) 15:37:22 sgallagh, the thing is, that the script also reports this for depending packages, i.e. if python2 is orphaned, python2-foo maintainers are notified as well - and also everyone who maintains somehting that requirs python-foo 15:37:35 I want to avoid "unretirement process is talk to mhroncok" (which doesn't scale and is a single point of failure:) 15:37:43 I also assume there will be more unorphan requests than unretire (and I cannot do either) 15:38:07 nirik: I assume the proposal was "mhroncok is added to the list of people who can unretire" 15:38:12 sure, or any requests you want to be trained up and do. ;) 15:38:27 nice! 15:38:33 works for me 15:38:33 i'm +1 to proposal 1 and to nirik's restatement of proposal 2 15:38:43 +1 to 1, 15:38:51 +1 to nirik's restatement of proposal 2 15:38:51 (hopefully mboddu agrees...) 15:40:10 +1 to 1, and +0 for 2 (I think the idea is great but also I think it could be managed within releng instead of being decided by fesco) 15:40:13 so where are we on votes? 15:40:16 +1 to 1 and to nirik's restatement of proposal 2 15:40:26 * bowlofeggs counts 15:40:57 i see +5, +4 15:40:59 +1 to nirik's restatement of proposal 2 15:41:08 maxamillion: what's your vote on prop 1? 15:41:12 +1 to 1 15:41:18 and sgallagh? 15:41:27 ok i think that's +6, +5 15:41:42 I'm +1/+1 as above 15:41:51 ok +7, +6 15:41:59 * bowlofeggs writes up two agreed's 15:42:18 #agreed The policy to retire packages after six weeks of being orphaned is reaffirmed. At least three warnings with one-week intervals will be sent out to co-maintainers before retiring. (+7, 0, -0) 15:42:40 #agreed mhroncok is added as a release engineer to process unretirement requests (which are still the same process as now, file ticket, it gets checked, etc) (+6, 1, -0) 15:42:45 alright, ready to move on? 15:42:52 ack 15:42:54 ack 15:43:07 the next one is actually related: 15:43:10 #topic #1973 FTBFS package are not being orphaned, nor retired 15:43:12 .fesco 1973 15:43:13 bowlofeggs: Issue #1973: The FTBFS cleanup policy is not happening - fesco - Pagure.io - https://pagure.io/fesco/issue/1973 15:43:38 do we have anything to decide on this that's separate than what we just discussed? 15:43:52 mhroncok: ? 15:44:25 it's similar 15:44:34 nobody is doing it 15:44:41 I guess here we need also a volunteer who does the notifications 15:44:49 there ar eno remainderds, releng asked for a sciprt, but got me no feedback 15:45:14 well, now that f29 is out the door, mboddu might have more time... but I could be wrong 15:45:20 Also there need to be scripts to check if bugs are still wrongly open 15:45:43 tyll: that would be helpful 15:46:11 I mean i offer my help in this but there's nobody who would tell me what can I actually do 15:46:14 the reminder sounds like it could just run as a cron 15:46:14 tyll: there is a script for that 15:46:35 ignatenkobrain wrote one that is even committed to the rel-eng repo iirc 15:47:13 so basically this just needs test and added to cron? I can assist with that... 15:48:12 Hello 15:48:32 nirik: that'd be great 15:48:32 There is script in releng repo 15:48:53 yeah, will add it to my list... if all the scripts are done, should be pretty easy to just add a cron 15:49:00 https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py 15:49:33 #action nirik will add https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py to cron 15:49:43 cool, do we need anything else than adding that to cron? 15:49:56 I don't think so... 15:49:58 bugzilla weekly reminders 15:50:15 https://pagure.io/releng/pull-request/7881 15:50:17 This doesn't do the orphaning, right? 15:50:31 no, just reminders 15:50:39 yes, I was going to add both those... the cleanup script, then after that the weekly nag 15:51:26 nirik: thanks 15:51:36 cool, so sounds like we are ready to move to the next topic? 15:51:53 WORKSFORME 15:51:59 +1 15:52:08 #topic #2009 libsolv SONAME bump in stable 15:52:11 .fesco 2009 15:52:12 thank you all for this and sorry to steal your meeting ;) 15:52:13 bowlofeggs: Issue #2009: libsolv SONAME bump in stable - fesco - Pagure.io - https://pagure.io/fesco/issue/2009 15:52:23 mhroncok: thanks for pushing it forward. 15:52:23 this one actually already happened, but was on last week's agenda 15:52:37 i guess we don't really need to discuss it, unless anyone has something to say? 15:52:45 thanks mhroncok! 15:52:51 * jsmith has nothing further to add 15:53:03 I don't think there's anything to say here. It followed the policy, but we (FESCo) made a mistake and didn't ensure that those depending on it were aware. 15:53:09 Let's do better next time. The End. 15:53:13 +1 15:53:13 +1 15:53:17 +1 15:53:20 cool, let's move on then 15:53:28 #topic #2013 to strict rules for branches deletion alongside with norules for theirs creations 15:53:31 .fesco 2013 15:53:33 bowlofeggs: Issue #2013: too strict rules for branches deletion alongside with norules for theirs creations - fesco - Pagure.io - https://pagure.io/fesco/issue/2013 15:53:35 * mboddu was in a standup, but I will work with nirik with cron and scripting work 15:53:47 wut? 15:53:53 mboddu++ 15:53:53 mhroncok: Karma for mohanboddu changed to 9 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:54:03 this topic title doesn't make sense, is this about making private branches deletable? 15:54:10 ok that roofer just showed up, so i need someone to take over running the meeting for me for a few minutes 15:54:11 and allowing force pushes and what not? 15:54:14 i sent the agenda to the fesco list 15:54:39 Pharaoh_Atem: it's mostly when somebody pushed by accident, not to a fork but to the repo 15:54:47 right 15:54:58 proposal: let's wait for a volunteer to write the script, and revisit the ticket when we have an implementation proposal 15:55:03 i actualyl did this in the bodhi repo last week 15:55:05 it sucked! 15:55:07 hahaha 15:55:09 zbyszek: +1 15:55:11 i made a 3.11 branch and now it's permanent 15:55:13 hahaha 15:55:16 zbyszek: +1 15:55:27 I've done that before myself too 15:55:33 it sucks when it happens :( 15:56:02 happened to em as well in a bash for loop, so i've pushed to 8 packages at once :( 15:56:09 oh man 15:56:11 hahah 15:56:22 * zbyszek has opened a fcNN branch, and even opened a releng ticket to get it deleted, but got a reply that fNN branches cannot be deleted 15:56:33 jsmith, sgallagh, maxamillion, tyll: vote on zbyszek's proposal? 15:57:55 IMHO we can also allow the procedure and sanction manual cleanups by releng 15:58:25 +1, I guess 15:58:28 tyll: they can't realistically take the time to do it, and manual cleanup is also very risky (error prone) 15:58:29 tyll: releng does not want to do the checks manually, which is totally understandable 15:58:31 I really want to avoid releng spending a lot of time on this... they have enough to do 15:58:59 there is legal obligation here, i think we need a well tested script 15:59:07 it's deleting data after all 15:59:23 i think we are up to +4 15:59:46 bowlofeggs, if the branch is merged it is for me easier to see this in a git by hand to be sure that I have the right command to verify this 16:00:27 tyll: keep in mind that you also have to verify in koji's data 16:00:47 at least in some cases 16:00:50 bowlofeggs, if the branch is merged, then nothing expect the name of the branch is going to be deleted 16:00:57 true 16:01:11 bowlofeggs, yes, I would not check that manually... 16:01:50 i still think releng doesn't have an incentive to do this manually 16:02:03 it's manual work and the payoff is just to remove a branch that is at worst annoying 16:02:18 there's not a serious problem with these branches remaining 16:02:30 so imo does not justify dangerous and manual work 16:02:32 would it mae sense to somehow obfuscate branch creation instead? 16:03:15 to prevent the accidents I mean 16:03:28 bowlofeggs, ok, I am also happy with waiting for a volunteer 16:03:33 ok i need to go talk to the roofer for real now - someone needs to run the meeting for a few min until i can get back 16:03:42 bowlofeggs: I'll take over 16:04:44 jsmith, sgallagh, maxamillion ? 16:05:04 zbyszek: What am I being asked? 16:05:33 For #2013, proposal: let's wait for a volunteer to write the script, and revisit the ticket when we have an implementation proposal 16:05:37 * sgallagh voted "+1, I guess" above 16:05:58 You're right. 16:06:17 * zbyszek tallies the votes 16:07:10 AGREED: we'll wait for a volunteer to write the script to do the checks, and revisit the ticket when we have an implementation proposal (+5, 0, 0) 16:07:15 tyll: I counted you as +1 16:07:26 zbyszek, yes 16:07:27 OK to move on? 16:07:39 * nirik nods 16:07:49 #topic #2003 Ursa Major (modules in buildroot) enablement 16:07:52 https://pagure.io/fesco/issue/2003 16:08:19 If that's OK, I'll paste part of the earlier conversaition with sgallagh and nirik in #fedora-devel 16:08:29 fine with me 16:08:52 14:54 < zbyszek> sgallagh: I'm rereading the dicussion, and I don't understand one thing: There were proposals 16:08:55 (e.g. by nirik) to create a "builtroot" repo that would contain rpms used for building, 16:08:58 including those from the default modules and some select non-default modules (i.e. those added 16:09:01 by Ursa Major). 16:09:03 14:55 < zbyszek> So, my understaning is that this provides a set of rpms, in some specific versions 16:09:07 14:55 < zbyszek> But you also talk about allowing packages to build using a slightly older version of go compiler 16:09:10 if they are incompatible with the latest version 16:09:12 14:56 < sgallagh> zbyszek: I never entirely understood what nirik was trying to say about the buildroot repo, 16:09:15 honestly. 16:09:18 14:56 < zbyszek> I don't understand how those two things fit together (having one version of rpms and using older 16:09:21 rpms during build). 16:09:23 14:56 < sgallagh> The point of Ursa Major is specifically to allow you to create a buildroot with non-default 16:09:26 module streams so you can build something that has build-time-only dependencies on a package in 16:09:29 a non-default stream. 16:09:32 14:57 < sgallagh> If it has a runtime dependency on a non-default stream, you must build it as a module with 16:09:35 proper module deps. 16:09:37 14:57 < bowlofeggs> sgallagh, contyk: i moved ursa major to be last 16:09:39 14:58 < sgallagh> This is meant to handle the case like I described, where we might be shipping golang X as the 16:09:43 default stream (and therefore in the default buildroot), but you want to ship a package that 16:09:46 can only build with golang x-1. 16:09:48 14:58 < sgallagh> Since it doesn't need golang at *runtime*, we shouldn't force people to make that package into 16:09:51 a module. 16:09:53 14:58 < zbyszek> sgallagh: So how does the package specify that it needs the non-defaul build stream? 16:09:57 14:58 < sgallagh> Right now, that is their only option. 16:09:59 15:00 < sgallagh> Umm, good question. I haven't had to do it myself, so I'll need to look that up 16:10:02 15:00 < nirik> the repo was an attempt to allow users to build things that take advantage of ursa-major without 16:10:05 using our koji. 16:10:08 Yikes, sorry for the formatting. 16:10:10 If you stretch the window "just right", it looks OK ;) 16:10:15 My current understanding it that nirik proposal is not workable, because it'd give just one repo with a specific set of packages, but UM is about allowing different packages to have deps on different non-default modules 16:10:33 yeah, that's my understanding of the situation too 16:10:45 Hence, UM is incompatible with external builders that do not understand the module metadata. 16:10:53 * sgallagh nods 16:10:57 which is basically all of them, by the way 16:11:18 yeah, bummer. :( 16:11:20 zbyszek, not correct, ursa-major allows configuring one global module set for use in all non-modular package builds 16:11:30