18:11:00 <smooge> #startmeeting EPEL (2019-10-16)
18:11:00 <zodbot> Meeting started Wed Oct 30 18:11:00 2019 UTC.
18:11:00 <zodbot> This meeting is logged and archived in a public location.
18:11:00 <zodbot> The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:11:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:11:00 <zodbot> The meeting name has been set to 'epel_(2019-10-16)'
18:11:00 <smooge> #meetingname epel
18:11:00 <zodbot> The meeting name has been set to 'epel'
18:11:00 <smooge> #topic aloha
18:11:00 <smooge> #chair nirik smooge tdawson bstinson Evolution pgreco sgallagh
18:11:00 <zodbot> Current chairs: Evolution bstinson nirik pgreco sgallagh smooge tdawson
18:11:00 <smooge> #topic Intros
18:11:01 <smooge> #info Meeting is run from https://board.net/p/epel
18:11:11 <bcotton> .hello2
18:11:12 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
18:11:20 <pgreco> hello everybody
18:11:27 <sgallagh> .hello2
18:11:28 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:11:49 <smooge> I lost tdawson because of my tardiness
18:11:59 <nirik> morning
18:12:02 <smooge> the meeting will be in an hour next week
18:12:19 <smooge> well it will be this time GMT next week
18:12:33 <kanarip> not GMT, UTC
18:13:00 <kanarip> GMT is a timezone, UTC is an immutable accounting of time
18:15:16 <smooge> yeah.. sorry grew up in a family where GMT was an immutable accounting of time
18:15:32 <smooge> #topic Old Business
18:16:09 <smooge> #info jcpunk would like to maintain libx86 https://bugzilla.redhat.com/show_bug.cgi?id=1746062
18:16:22 <smooge> I am not sure how to add someone to an EPEL branch
18:16:38 <smooge> sorry sorry pacakgedb thought
18:16:53 <smooge> not sure how to add someone as a co-maintaienr of a packager
18:17:04 <smooge> geez mys pelling is horrible
18:17:27 <smooge> nirik, do you know what is needed for this?
18:18:01 <nirik> have they talked to the maintainer in fedora?
18:18:32 <nirik> I guess via the bug
18:19:09 <nirik> we used to have a deadline for these... 2 weeks? or something...
18:19:15 <nirik> if no answer just add them
18:19:33 <nirik> so, IMHO, we should just add them at this point?
18:19:51 <kanarip> +1 to nirik
18:20:00 <kanarip> meritocracy ftw
18:20:11 <smooge> I was going to do so.. I don't know who has rights to do that?
18:20:19 <sgallagh> I generally default to "if someone wants to maintain a thing, let them"
18:20:40 <sgallagh> If they misbehave, we go back and fix it.
18:20:55 <nirik> you can. go to the src.fedoraproject.org/rpms/whatever page, settings and users and groups and add them (they may have to login once if they haven't yet to appear)
18:21:08 <kanarip> sgallagh, that's how i "own", but not "maintain" quite a bunch of packages
18:21:12 <smooge> ok will see if I can do that
18:22:21 <smooge> ah I see where now
18:22:28 <smooge> ok done
18:23:54 <smooge> so my last question as I added them as commit rights.. is that enough or do they need admin also?
18:24:17 <smooge> thanks nirik.
18:24:30 <kanarip> iirc, they need admin to maintain the repo, not to submit builds
18:25:21 <nirik> should not need admin normally... thats for adding more maintainers, etc.
18:25:21 <kanarip> commit == comaintainer == koji == bodhi == #kthxbye
18:25:36 <smooge> #topic EPEL-6
18:25:36 <smooge> #info EPEL-6 is End of Life in 2020-11. It will be moved to archives in 2020-12
18:25:36 <smooge> #topic EPEL-7
18:25:36 <smooge> #info no news is good news
18:25:36 <smooge> #topic EPEL-8
18:25:49 <kanarip> !!
18:25:50 <smooge> sgallagh, this is where you take over
18:26:05 <sgallagh> So, we'
18:26:06 <smooge> or was there something I missed on EPEL-6 and EPEL-7?
18:26:08 <sgallagh> re getting close
18:26:38 <sgallagh> merlinm has been working with mboddu for the last few days and we're almost at the point where module builds should work
18:26:56 <sgallagh> We've hit a few snags with the stg environment being out of sync with the prod one.
18:27:08 <sgallagh> Mohan is going to do a sync and we'll see if that gets us the rest of the way.
18:27:10 <sgallagh> EOF
18:27:42 <nirik> unfortunately, we have to do some coordination since there's others using staging... but we will try
18:29:57 <kanarip> since there's not been any interaction on the topic, who triggers the build for epel-rpm-macros?
18:31:22 <smooge> ... I think everyone is pointing at me
18:31:28 <smooge> but it is hard to tell in irc
18:31:38 <smooge> what is needed for this package?
18:31:59 <kanarip> someone to trigger the build
18:32:23 <kanarip> remember, i put in the pull request, i didn't feel Kevin enough to pre-empt
18:32:44 <nirik> I can do it too, just haven't gotten around there...
18:32:45 <smooge> .. remembers hitting merge
18:32:51 <smooge> ok no I will do so
18:33:00 <smooge> don't ask me why I thought I had done that already
18:33:13 <kanarip> thanks, this will help whats-his-face with the python foo
18:33:30 <kanarip> and secondly, there's been some misunderstanding, possibly even on my part, about whether epel8-playground does or does not inherit builds in the epel8
18:34:35 <kanarip> if anything, i would suspect epel8-playground is going to be poisoned with builds in epel8-playground, whereas the packages have been promoted to epel8, but the buildroot for epel8-playground is going to use whatever was built there
18:35:09 <smooge> ... wonders if he should have built this package first for epel8  or for epel-playgorund8 first
18:35:19 <kanarip> i think i'm right, i don't need to be right, i don't care, but clarity may need to be created for epel8-playground to be all that it wants
18:35:48 <nirik> smooge: only epel8-playground
18:35:53 <kanarip> smooge, epel-rpm-macros per the pull request should be built for epel8-playground only
18:35:56 <nirik> the package should be different between the two
18:36:02 <kanarip> +1
18:36:41 <smooge> well good
18:36:47 <smooge> I did the right thing for once
18:37:10 <kanarip> you're participating... no matter the extent to which you fuck up, at least you stepped up
18:37:13 <smooge> ok so that should pop into existience in the next 10 minutes
18:37:29 <kanarip> the rest is to whining little babies who won't step up and put in the work
18:37:41 <nirik> right now I don't think pungi pulls in epel8 to epel8-playground. We could just ask people to always enable both repos... pull in the rpms from epel8 or something else. Lots of options
18:38:02 <kanarip> nirik, that's the mirror compose though, right?
18:38:11 <kanarip> i'm talking "purely koji"
18:38:41 <nirik> right. the compose... koji does have inheritence there
18:39:08 <kanarip> my point is epel8-playground will build against whatever is latest in epel8-playground, despite whatever nevra may be marked as actually stable and maintained in epel8 itself
18:39:46 <kanarip> "when promote to epel8, untag all package builds in epel8-playground"
18:40:15 <sgallagh> kanarip: By default, a build in the epel8 branch builds for both branches
18:40:27 <sgallagh> epel8-playground auto-pushes, epel8 doesn't
18:40:42 <kanarip> is that a packages.cfg thing?
18:40:55 <sgallagh> So except in cases where you have intentionally separated the branches, epel8 playground should always be >=
18:40:56 <kanarip> i don't understand
18:40:57 <sgallagh> Yes
18:41:01 <kanarip> ok
18:41:26 <kanarip> that should probably be voided as a default and become opt-in instead
18:41:50 <nirik> yeah, we could... and that would make the mergers happier
18:42:22 <sgallagh> ... why?
18:42:29 <kanarip> keep the inheritence, but allow epel8-playground to move forward independently
18:42:33 <nirik> to make the mergers happier? ;)
18:43:28 <kanarip> 'cause i might think foo-1.0 is feasible, and get it in to epel8, but need to play with foo-1.1 in epel8-playground because of the dependent packages requesting that instead of stable
18:44:04 <sgallagh> nirik: Can you explain what that means?
18:44:23 <kanarip> to default to both being the same 'fedpkg build' is to assert epel8-playground has no 'raison d'e^etre'
18:44:26 <nirik> sgallagh: people who make changes to master and 'git merge master' to all the other branches.
18:44:27 <sgallagh> kanarip: Then you delete package.cfg in the epel8 branch and break the inheritence
18:44:52 <nirik> they don't want a packages.cfg thats different in epel8 branch, it messes up their workflow
18:44:52 <kanarip> sgallagh, still not how koji inheritence works
18:44:56 <sgallagh> nirik: I'm still not following. What in the current scenario is impacted by that?
18:45:07 <sgallagh> kanarip: I'm asking why koji inheritence matters at all
18:45:32 <nirik> packages.cfg disappears if they just merge into epel8, or if they have it in master it's wrong and breaks master?
18:45:33 <sgallagh> nirik: why? They merge it a single time and then all subsequent merges are handled
18:45:55 <sgallagh> It shouldn't... that's not how git merges work.
18:45:55 <kanarip> sgallagh, in my experience, a foo-1.1 build in epel8 with an existing foo-1.0 build in epel8-playground will have dependent packages build with foo-1.0
18:46:09 <nirik> ok, I am not doing this, so I am just passing along what people have complained about. ;)
18:47:10 <kanarip> *dependent packages in epel8-playground
18:47:32 <nirik> we could get in that state, yes...
18:47:36 <sgallagh> kanarip: I'm trying to figure out what you're complaining about.
18:47:41 <sgallagh> That's... functioning as designed.
18:47:46 <kanarip> i'm not complaining
18:47:52 <nirik> but I am not sure how we would prevent it.
18:47:53 <smooge> i think we have 3 different conversations going on
18:47:58 <smooge> let us stick to 1
18:48:00 <sgallagh> If you have manually split the branches and aren't keeping one of them up... that's your own fault
18:48:01 * nirik is done with his. :)
18:48:03 <kanarip> i'm articulating the validity of epel8-playground against popular opinion
18:48:21 <sgallagh> kanarip: That sentence doesn't parse. Please try again.
18:48:41 <smooge> the problem that people are having is that they have various 'specific' workflows that the packages.cfg seem to cause conflicts on
18:49:03 <kanarip> there's a need to both have package builds promoted to epel8 (stable), while allowing future builds in epel8-playground to be independent of what is in epel8 itself
18:49:05 <smooge> sgallagh, there have been several email threads on this in the list.. I will see if I can find one of them to send you
18:49:25 <nirik> kanarip: we have that now?
18:49:31 <kanarip> there's also a need to promote what is in epel8-playground in to epel8, as the "i'm done, stable now"
18:50:15 <nirik> that step requires you to merge or cherry pick your changes into epel8 branch and build there.
18:50:16 <sgallagh> We still have that now.
18:50:20 <sgallagh> right
18:50:59 <kanarip> however, if foo-1.0 simply gets built against and promoted to epel8 today, whatever builds against foo in epel8-playground-build will only every get whatever the latest epel8-playground build, not whate
18:51:07 <smooge> trying to do it direct seemed to require changes in the buildsystem we could not do
18:51:17 <kanarip> ver may actually independently move forward in epel8 itself
18:51:27 <sgallagh> kanarip: You're describing the intentional design.
18:51:43 <sgallagh> If there's something about it that you disagree with, please describe a problematic case.
18:51:59 <kanarip> while i'm feeling like i'm not understood, i'll shut up now.
18:52:26 <sgallagh> kanarip: I'd *like* to understand you
18:52:31 <nirik> yeah, once you merge back to epel8, you should put the packages.cfg back in place and build for both again.
18:52:53 <nirik> and if you again want to use playground you should merge up from epel8 to make sure you start from there.
18:52:58 <kanarip> i'm trying to explain, but i feel i'm not asked for any clarification, but instead dismissed
18:53:02 <sgallagh> Is the problem that you think we need documentation for this? (That's probably true)
18:53:22 <sgallagh> kanarip: I'm not dismissing you, but you haven't said anything yet that isn't just a restatement of the design.
18:53:32 * nirik can shutup for a while. :)
18:53:38 <sgallagh> I'm trying to ask "what problem do you see with it?"
18:53:57 <kanarip> and perhaps i'm misunderstanding the design, but it's problematic (to understand) for package maintainers
18:54:51 <sgallagh> kanarip: So maybe what I said was right: we need to document the workflow more explicitly
18:55:02 <kanarip> i see the problem in the unexpected way koji inheritance works for build roots specifically... it doesn't take nevra between many various repositories in to account like a dnf install on a consumer system
18:55:05 <sgallagh> I'll see if I can work something up before next meeting and propose it for addition.
18:55:21 <sgallagh> kanarip: At present, there *is* no inheritance between epel8 and epel8-playground
18:55:25 <sgallagh> They're effectively disjoint
18:55:26 <smooge> kanarip, could you email me what you are seeing as the problem or what you want the design to be? I think IRC is horrid for these conversations because most of the thoughts need multiline explanations and we are all doing party talk while it is being said
18:55:43 <kanarip> sgallagh, think again: koji list-tag-inheritance epel8-playground-build
18:56:06 <sgallagh> OK, if it *is* inheriting, that's probably a mistake.
18:56:23 <kanarip> maybe here is where we get to the crux of things then ;-)
18:56:33 <sgallagh> When I proposed the design, I expected them to be disjoint
18:57:00 <smooge> i think we had to make them inherit for some reason or builds didn't work
18:57:33 <sgallagh> smooge: Were there builds in epel8 before epel8-playground existed?
18:57:54 <sgallagh> Because those probably wouldn't have been rebuilt for both platforms yet
18:58:18 <smooge> at the time I remember doing them in a
18:58:21 <sgallagh> I suspect what we actually need to do is just quietly tag over anything that only exists in epel8 into epel8-playground
18:58:23 <kanarip> smooge, you needed inheritance in order to allow the list of packages allowed to build i suppose
18:58:48 <smooge> fedpkg build; fedpkg switch-branch epel8-playground; git merge; edit; fedpkg build
18:59:05 <sgallagh> smooge: Context?
18:59:18 <sgallagh> oh, sorry.
18:59:23 <smooge> sgallagh, you asked what I was doing back then
18:59:25 <sgallagh> Just realized that was the rest of the earlier sentence
18:59:31 <smooge> again party talk
18:59:42 <kanarip> i'm still favoring epel8-playground to inherit from epel8, but that everything that gets out of -playground and gets marked stable, be untagged from -playground
19:00:02 <kanarip> but that being said, it may not very well align with the initial idea for -playground
19:00:38 <sgallagh> I think it boils down to whether we want to think of playground as an alternate repository or an add-on repository
19:00:46 <sgallagh> That's the fundamental distinction
19:01:09 <kanarip> i was thinking of -playground as the rawhide of epel
19:01:41 <sgallagh> kanarip: So... both then :)
19:01:47 <smooge> so from the various conversations I have had in the last 3 months, most developers think of it as an addon where it layers on top of EPEL-8
19:02:06 <kanarip> smooge, that's my experience in the field as well
19:02:13 <sgallagh> smooge: Is that what we *want* it to be? If so, then we need to adjust the design slightly. If not, we need to adjust messaging.
19:02:17 <kanarip> epel, but pure
19:02:21 <smooge> you stick things in there which are for playing around and should have it AND epel-8 together
19:02:38 <smooge> which has been also causing probems
19:02:57 <kanarip> sgallagh, and hence i'm raising this with EPSco finally, and let you guys set the course and policy and everything else
19:03:15 <kanarip> thanks for letting me!
19:03:41 <smooge> sgallagh, I would like a real NY reuben sandwich, but everyone keeps giving me pastrami on toast and saying that is a reuben
19:03:47 <smooge> kanarip, we will do so.
19:04:14 <kanarip> smooge, the requirement to have them both configured is a pungi-* epel8-playground.conf compose inherit boolean though
19:04:36 <smooge> so what we want and what people expect are different.. we then need to either change to what they expect or better document.
19:04:39 <kanarip> the consumer end is very, very much different from the koji end, if i may
19:04:55 <sgallagh> smooge: You just restated what I said: fix the design or the messaging
19:05:02 <smooge> in either case we are coming up to na hour.. so maybe we sould have this conversation on a mailing list after I take some headache medicine
19:05:10 <sgallagh> ack
19:05:31 <smooge> my brain is not type good anymore
19:05:43 <smooge> #info thank you all for coming
19:05:47 <smooge> #endmeeting