15:00:18 <zbyszek> #startmeeting FESCO (2020-03-23)
15:00:18 <zodbot> Meeting started Mon Mar 23 15:00:18 2020 UTC.
15:00:18 <zodbot> This meeting is logged and archived in a public location.
15:00:18 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:18 <zodbot> The meeting name has been set to 'fesco_(2020-03-23)'
15:00:18 <zbyszek> #meetingname fesco
15:00:18 <zodbot> The meeting name has been set to 'fesco'
15:00:18 <zbyszek> #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell
15:00:18 <zodbot> Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:21 <zbyszek> #topic init process
15:00:26 <contyk> .hello psabata
15:00:27 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:27 <nirik> morning.
15:00:28 <bookwar> .hello2
15:00:30 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:00:32 <zbyszek> .hello2
15:00:33 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:45 <ignatenkobrain> .hello2
15:00:45 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Raits' <i.gnatenko.brain@gmail.com>
15:01:03 <decathorpe> .hello2
15:01:04 <dcantrell> .hello2
15:01:04 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:01:07 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
15:01:11 <zbyszek> ignatenkobrain: new name?
15:01:27 <ignatenkobrain> yeah, should have done this update long ago :)
15:02:02 <contyk> I'd even call it an old name by this point.
15:02:05 <contyk> You should change it again.
15:02:36 <zbyszek> The name changes, FAS nick never. Just ask churchyard.
15:03:24 <zbyszek> mhroncok coming?
15:04:08 <zbyszek> We have just one item, let's start.
15:04:11 <zbyszek> #topic #2353 Request to become a provenpackager (FAS: gerd)
15:04:11 <zbyszek> .fesco 2353
15:04:12 <zodbot> zbyszek: Issue #2353: Request to become a provenpackager (FAS: gerd) - fesco - Pagure.io - https://pagure.io/fesco/issue/2353
15:04:26 <mhroncok> hey. sorry for being late
15:04:30 <sgallagh> Sorry, I'm here. Forgot to chime in
15:04:59 <zbyszek> Hi mhroncok, sgallagh.
15:05:22 <zbyszek> So... it feels like the OP is not trying to make a big effort.
15:05:38 <mhroncok> indeed
15:05:47 * sgallagh nods
15:05:51 <dcantrell> I agree.  followup comments sort of move in to "yeah, ok, but here's a thing I could update because it could be updated"
15:06:16 <ignatenkobrain> I'm -1 on this, sorry.
15:06:40 <nirik> well... does this mean we need a good list of reasons for provenpackagers?
15:06:44 <mhroncok> yes
15:06:46 <nirik> and what are they?
15:06:51 <mhroncok> that's the general idea IMHO
15:07:09 <mhroncok> to provide the list of reasons for evaliation
15:07:13 <dcantrell> at the very least I'd like provenpackagers to not self-nominate
15:07:22 <mhroncok> not for us to provide "good list", sorry for confusing the two
15:07:29 <nirik> long ago before we had them (everyone was one) we moved to the current model with the idea that "trusted" "experenced" people could be added into provenpackager
15:07:36 <mhroncok> dcantrell: self nominate is totally OK if there is a legitimate reason
15:07:55 <nirik> well, what are good reasons anymore?
15:08:28 <sgallagh> The good reasons are basically for mass rebuild updates
15:08:34 <dcantrell> ok, self-nominate is fine.  I guess what I'd prefer more is to have some other package maintainers give references or something.  at least to back up the why
15:08:38 <mhroncok> "I need to bump 200 packages becasue i maintain a library and cooridnating this is a pain every time I do it"
15:08:53 <mhroncok> reasons like this
15:08:54 <nirik> what about "I want to help out other packagers" ?
15:08:54 <sgallagh> Or for things like the ability to create bodhi updates for many pacakges (like FreeIPA's ecosystem)
15:09:06 <bookwar> to be honest, i think proven packages need to be replaced by pull-request workflow
15:09:17 * nirik is just worried we are setting the bar really high and will stop having new provenpackagers.
15:09:20 <mhroncok> bookwar: with hundreds of packages?
15:09:41 <mhroncok> nirik: the bar is quite low currently: you have a reason that makes sense, you ge it
15:09:50 <dcantrell> nirik: that's where I'd like to see some comments from the packagers they want to help out.  not every package is created equal and some workflows may differ from other packages
15:10:04 <mhroncok> "I want to help" doesn't require being a provenpackager
15:10:17 <dcantrell> right, I want to help could very easily be a PR
15:10:18 <bookwar> mhroncok: in this case you are going to do hundred of patches anyway, and you need a review from package owner
15:10:34 <mhroncok> bookwar: in case of e.g. pytohn 3.9 rebase I don't
15:10:36 <nirik> how about "I want to help merge stale PR's and build those packages" ?
15:10:38 <bookwar> mhroncok: i shouldn't have said this as radically as i did, but on the concept level
15:10:53 <bookwar> mhroncok: if people want to generally help maintaining other packages
15:11:00 <zbyszek> bookwar: I very much disagree (having done this kind of action a few times).
15:11:01 <mhroncok> nirik: sure, show us the PRs you talk about
15:11:04 <bookwar> that's what pull requests are for
15:11:11 <decathorpe> nirik: I don't think that should happen without package admin's agreement
15:11:19 <mhroncok> exactly
15:11:24 <decathorpe> and if they need to agree, you could do PRs instead as well ....
15:11:37 <nirik> I fear this sort of specific requirement means we will have no new provenpackagers that help around the distro. Everyone will be in their little area and ignore the rest.
15:12:26 <dcantrell> I think it depends on the project.  For a lot of things where we are the upstream, the dist-git repo is effectively meaningless since a new upstream release is made.  so a provenpackager's contributions would be more useful upstream
15:12:37 <dcantrell> which would still be working with the same people, but a different workflow
15:13:18 <dcantrell> I dunno, provenpackager is special case enough to me and packages all vary wildly that I don't think we can just let anyone be one for just wanting to help.  But I don't know how best to direct people to help on the projects they want to help on
15:13:33 <decathorpe> provenpackagers are also useful for the "this package needs help, is basically unmaintained, but not orphaned" case
15:13:59 <dcantrell> maybe we could come up with an never ending TODO list type thing with work like that
15:14:17 <dcantrell> the kernel either still has or had a kernel-janitors list for things that need doing and people looking to help
15:14:21 <nirik> I wonder if it would make sense to move to a 'trial period' type thing... give the permissions for 6 months or whatever and at the end have to show what you did to be made perm?
15:14:23 <decathorpe> dcantrell: you mean a ToQueue? ;)
15:14:23 <dcantrell> we certainly have plenty of that work
15:14:46 <mhroncok> nirik: the PRs tehy open are the trial period
15:14:48 <dcantrell> decathorpe: hehe
15:15:12 <mhroncok> nirik: if they don't show anything of that sort and just say "I want to help" -- that isn't much effort
15:15:15 <dcantrell> in addition to a trial period, I'd say new provenpackagers should be matched with an existing one for a mentor
15:15:17 <nirik> mhroncok: ok, but currently I don't think we have any PR requirement?
15:15:24 <decathorpe> mhroncok: yeah, that would make sense
15:15:31 <mhroncok> provenpackager isn't a reward, it's "I need it to do stuff, this kind of stuff"
15:16:11 <pingou> I would like to do stuff?
15:16:18 <mhroncok> what stuff?
15:16:20 <nirik> or perhaps it would make since to write up the things we do expect them to do... but then anyone applying will say those things. ;)
15:16:59 <zbyszek> > My general intention is to help out across the collection.
15:17:05 <nirik> anyhow, I didn't mean to drag this out... ;)
15:17:11 <cyberpear> (example of a "stale" PR: https://src.fedoraproject.org/rpms/dnf/pull-request/18 )
15:17:44 <decathorpe> still, the examples they gave for what they wanted to do were not good examples.
15:18:34 <dcantrell> given the access a provenpackager has, are we not also concerned about security implications?  we should probably know who we're giving it to
15:18:39 <nirik> so, I guess close and say 'come back when you have specific things you need to do blocked by not being a provenpackager' ?
15:18:47 <bookwar> i think we don't have a common understanding what proven packager role is. If it is a "person can be trusted" thing - it is a reward. If it is a "person wants to do X" - it is an assignment
15:18:48 <zbyszek> We had +2, -8 in the ticket
15:19:10 <zbyszek> bookwar: both things you quoted apply
15:19:17 <dcantrell> bookwar: I think it ends up being both
15:19:21 <nirik> dcantrell: well, sure, but if you are a packager it's already assumed we trust you... also we have a trail of commits, etc... if someone misbehaves
15:19:34 <bookwar> then we need an assignment
15:19:56 <zbyszek> bookwar: no, people work on what they want, no assignment is done.
15:19:57 <nirik> it's not a reward... or shouldn't be IMHO.
15:21:12 <mhroncok> exactly
15:21:17 <zbyszek> +1 to nirik's "close and say"
15:21:27 <sgallagh> Proposal: provenpackager status requires the applicant to provide a justification for why those privileges are needed beyond sending pull-requests. FESCo decides at its sole discretion whether to approve based on this justification.
15:21:52 <zbyszek> sgallagh: re the second sentence: sponsors get to vote
15:22:15 <sgallagh> I thought that was only for new sponsors. Am I misremembering?
15:22:23 <nirik> we have a policy on it: https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/
15:22:44 <sgallagh> OK, my mistake
15:22:48 <sgallagh> I'll amend:
15:23:05 <sgallagh> Proposal: provenpackager status requires the applicant to provide a justification for why those privileges are needed beyond sending pull-requests. FESCo decides at its sole discretion whether to send the request to the sponsors list based on this justification.
15:23:17 <sgallagh> So FESCo at least decides whether or not to waste the sponsors' tim e
15:23:26 <dcantrell> that reads well
15:23:43 <mhroncok> I'm -1 to change the policy
15:23:51 <mhroncok> I'm +1 to close this one for now
15:24:08 <mhroncok> we see that sponsor themselves were quite capable of deciding this
15:24:14 <mhroncok> it works quite fine
15:24:19 <zbyszek> I'd just remove the second sentence. It constrains us, and doesn't really change much, because anything we vote on we vote according to our discretion.
15:24:43 <zbyszek> But the first sentence reads OK.
15:24:51 <nirik> I'm not for changing the policy without more thought/discussion. ;)
15:25:04 <mhroncok> not on  ameeting anyway
15:25:09 <sgallagh> Fair enough
15:25:24 <zbyszek> OK, so let's return to nirik's proposal
15:25:31 <dcantrell> I'm ok wither way
15:26:27 <dcantrell> *either
15:26:36 <dcantrell> w is next to e
15:26:43 <dcantrell> maybe I should go back to dvorak
15:27:05 <zbyszek> I understood "wither" to be short for "with either"
15:27:27 <bookwar> should we vote?
15:27:45 <dcantrell> I vote we vote
15:27:53 <contyk> Can we re-state the proposal?
15:28:04 <zbyszek> nirik, please restate.
15:28:05 <dcantrell> zbyszek: ahh, that works too
15:28:14 * nirik looks back up to see what he typed.
15:28:47 <nirik> close request and ask reporter to come back when they hit specific issues that they need provenpackager status to solve.
15:29:02 <contyk> +1
15:29:04 <decathorpe> nirik: +1
15:29:07 <dcantrell> +1
15:29:18 <zbyszek> +1
15:29:25 <bookwar> +1
15:29:28 <sgallagh> +1
15:29:39 <mhroncok> +1
15:30:30 <zbyszek> #agreed Close request and ask reporter to come back when they hit specific issues that they need provenpackager status to solve (+8, 0, 0)
15:30:35 <zbyszek> #topic Next week's chair
15:30:54 <zbyszek> volunteers?
15:31:26 <sgallagh> I haven't done it in a while.
15:31:36 <zbyszek> Thanks.
15:31:37 <zbyszek> #action sgallagh will chair next meeting
15:31:41 <zbyszek> #topic Open Floor
15:32:12 <bookwar> please review https://pagure.io/fesco/fesco-docs/pull-request/28
15:32:18 <bookwar> zbyszek already did
15:32:43 <bookwar> mhroncok: i wonder if it is the level of details you expect or more is needed
15:32:57 <mhroncok> bookwar: the details level si wuite fine
15:33:07 <mhroncok> q is next to w
15:33:12 <bookwar> :)
15:33:24 <nirik> +1 here. looks good.
15:33:55 <contyk> Ack.
15:34:16 <decathorpe> looks good
15:34:22 <dcantrell> +1 looks good
15:34:47 <bookwar> so, i am not sure how we merge these things, are votes here good enough?
15:35:08 <mhroncok> we have approved the policy change on princile already
15:35:27 <mhroncok> so this does not need a formal vote. enough people said it's OK -> ship it
15:35:28 <zbyszek> Yeah, we're just proofreading and sanity-checking here.
15:35:33 <zbyszek> It's shipped now.
15:35:37 <bookwar> ok, thanks
15:35:47 <bookwar> and then the other topic is the alternative buildroot change update, it is coming to Fedora devel mailing list hopefully today, if Ben has time for it https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
15:35:50 <bookwar> so just that you know it is coming
15:36:05 <sgallagh> All aboard the SS ShipIt!
15:36:10 <decathorpe> I think most people will be confused by ELN :)
15:36:26 <bookwar> decathorpe: that's sort of expected, like RDO and stuff
15:37:02 <bookwar> the naming was hard, sgallagh has the explanation, several of them, but it is complicated )
15:37:03 <dcantrell> sgallagh: no way am I getting on a cruise ship now
15:37:23 <nirik> hum... is this different/another instance, or the same as the https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update ?
15:37:37 <dcantrell> what does ELN stand for?
15:37:37 <zbyszek> nirik: it says "supersedes" in the page
15:37:41 <sgallagh> nirik: It's a proper superset
15:37:55 <nirik> ok, cool.
15:38:05 <mhroncok> enterprise linux nomads
15:38:11 <sgallagh> dcantrell: https://fedoraproject.org/wiki/ELN
15:38:28 <zbyszek> sgallagh, bookwar: "in the way which resembles the CentOS and RHEL build process" — this explains very little for people who are not familiar with RHEL/Centos
15:38:46 <sgallagh> But I lost the fight, so now it's ELN (like how KFC doesn't actually stand for Kentucky Fried Chicken anymore)
15:38:56 <mhroncok> bookwar: also, I'd really like to see the code snipped int eh FPC ticket
15:38:59 <mhroncok> *snippet
15:39:05 <mhroncok> *in the
15:39:09 * mhroncok is so sorry
15:39:12 <bookwar> mhroncok: sgallagh works on it
15:39:29 <sgallagh> mhroncok: It's on my TODO list for today.
15:39:35 <sgallagh> Once I get out of meetings :)
15:39:45 <mhroncok> bookwar: I am worried that it will be a mess when thins are importe with eln dist conditionals to another distro
15:39:49 <dcantrell> sgallagh: so wait, is this an entire other rawhide?
15:39:56 <zbyszek> Scope section: it's missing punctuation a lot.
15:40:06 <bookwar> dcantrell: except the srpms
15:40:12 <sgallagh> mhroncok: tl;dr version: `%{eln}` will exist but shouldn't be used in nearly all cases.
15:40:20 <dcantrell> bookwar: but you can't do that
15:40:29 <sgallagh> We're going to be defining the `%{rhel}` macro
15:40:45 <mhroncok> in that case, I don't really get the FPC ticket at all
15:41:03 <sgallagh> It was filed before we had the conversation about the best way to do things.
15:41:06 <mhroncok> .fpc 955
15:41:07 <zodbot> mhroncok: Issue #955: F33 Change: ELN compose and disttag - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/955
15:41:08 <sgallagh> (That conversation happened this morning)
15:41:23 <mhroncok> sgallagh: oh. ok.
15:41:41 <sgallagh> The situation is evolving rapidly
15:41:47 <bookwar> dcantrell: what do you mean?
15:41:57 <dcantrell> bookwar: GPL violation to start with
15:42:21 <sgallagh> dcantrell: She means it's not a whole new branch. It's going to build from Rawhide
15:42:31 <sgallagh> So Rawhide's SRPMs are the same and we don't need to host them twice
15:42:56 <dcantrell> ok that makes more sense.  so it's a conditional build from the master branch?
15:43:00 <sgallagh> Yes
15:43:14 <dcantrell> sorry if I'm late to the party on this one, but this is the first I've heard of ELN
15:43:19 <nirik> and composes I thought were not really distributed? just tested?
15:43:22 <sgallagh> It's the first anyone has :)
15:43:31 <sgallagh> nirik: That's the plan.
15:43:39 * nirik has, but then he watches the wiki RSS feed. ;)
15:44:37 * mhroncok would be much happier if those things emerge in public rather than behind a corporate wall
15:44:44 <bookwar> mhroncok, sgallagh i created a place to talk before thinking actually what we need to talk about there, sorry for that. But update is coming
15:44:49 <sgallagh> mhroncok: Which things?
15:45:03 <bookwar> mhroncok: they did, i posted the idea 2 months ago on a mailing list
15:45:06 <bookwar> it is the same idea
15:45:09 <mhroncok> bookwar: FPC tickets about thinks that nobody has ever heard of for exaple
15:45:14 <mhroncok> *things
15:45:42 <bookwar> mhroncok: i can not setup fpc ticket before the change is created, where i describe what is about
15:46:02 <dcantrell> I don't remember seeing anything about this on fedora-devel
15:46:04 <bookwar> i created change today, and created ticket today as well
15:46:17 <mhroncok> what dcantrell says
15:46:58 <bookwar> dcantrell: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3Z5SMF6CPL3MK2CNYPUW4OZYMA6TZJBN/#MKXPMQOZNLECPPWRM6UBUMR2WHVG5DL6
15:47:11 <sgallagh> The FPC ticket should probably have waited until the Change discussion happened. We jumped the gun on that one
15:47:34 <mhroncok> sgallagh++
15:47:41 <bookwar> sgallagh: i though it is _where_ discussion happens
15:47:44 <sgallagh> It's causing confusion, in part because we didn't have the right conversations before filing it.
15:47:59 <bookwar> but ok, let's rework it
15:48:00 <dcantrell> bookwar: I do remember that thread, but was not connecting it to this ELN stuff
15:48:04 <dcantrell> sorry
15:48:29 <sgallagh> bookwar: FPC tickets should probably be more for asking for specific changes. If we were requesting input, we probably needed to provide more information and guidance.
15:48:44 <bookwar> sgallagh: good point
15:48:51 <zbyszek> FWIW, I would like to see a lot more detail in the Change page.
15:49:10 <sgallagh> Anyway, I don't think continuing down this path is productive. I'll provide more info on that ticket after this meeting and lunch
15:49:33 <mhroncok> so for example, as a Python maintainer... (right, sorry but that's what I do), when i bootstrap new Python upgrade in a side tag, how is this ELN thing gonna take it?
15:49:56 * nirik guesses after it lands in rawhide.
15:49:59 <bookwar> mhroncok: it won't, it is only rebuilding fedora rawhide right now
15:50:18 <mhroncok> bookwar: but will it "see" rawhide content?
15:50:22 <bookwar> not even right now, it is _about_ rebuilding rawhide
15:50:42 <sgallagh> mhroncok: I don't understand the question
15:50:42 <mhroncok> aka if it builds from master, how do we bootstrap things in it?
15:51:08 <sgallagh> You bootstrap in Rawhide.
15:51:16 <bookwar> https://pagure.io/releng/issue/9154#comment-631088
15:51:21 <mhroncok> sgallagh: yes. and what happans in ELN?
15:51:22 <sgallagh> Think of this as us running mass-rebuilds using different flags
15:51:55 <mhroncok> sgallagh: is the rawhide content available in the eln buildroot?
15:52:08 <sgallagh> Ah, I see what you're asking now. Yes, it will be.
15:52:52 <sgallagh> We plan to have the buildroot inherit from current Rawhide
15:53:04 <sgallagh> So once things are rebuilt, they supersede, but until then stuff comes from Rawhide
15:53:25 <mhroncok> sgallagh: so the ELN rebuilds would onyl ahppen after we merge Python 3.9 side tag into rawhide?
15:53:30 <sgallagh> Right
15:53:47 <sgallagh> That's something we could look at improving on in a Phase 2, but it's out of scope for this effort
15:54:15 <mhroncok> sgallagh: this kind of things is explained in the proposal? (I've only skimmed trough it, as this is the frst time I read it)
15:54:36 <bookwar> we can consider adjusted inheritance paths later, but we'd like to start simple
15:54:54 <sgallagh> mhroncok: I think zbyszek is right that we may need to increase the level of detail in the Change Proposal
15:54:54 <zbyszek> sgallagh: "once things are rebuilt, they supersede, but until then stuff comes from Rawhide" — if the eln rebuild fails, do packages with higher EVRA from rawhide again supersede the ones from eln?
15:55:28 <sgallagh> zbyszek: I don't actually know the answer to that off the bat. I don't know how Koji does inheritance with that level of detail.
15:55:56 <contyk> I don't think they do.
15:56:05 <mhroncok> higher nevr always win
15:56:15 <contyk> That's not true.
15:56:18 * nirik isn't sure he's parsing the question right.
15:56:30 <sgallagh> I'll provide an example:
15:56:37 <bookwar> just to be clear: this change was proposed today, i literally created it several hours ago, so i am not asking you to provide right now the full feedback on it. I just wanted to mention it so you are not surprised that much to see it on a mailing list. So the fact you have not heard about it before is ok. It didn't exist before.
15:56:40 <nirik> if you try a build and it fails in eln... then the rawhide one would still be 'newest' because that eln build failed.
15:56:41 <sgallagh> libfoo-0.1.0 is built successfully in Rawhide and rebuilt in ELN
15:56:56 <mhroncok> contyk: IIRC both builds are available in the repo, so you get a higher nevr if both packages satisfy the deps
15:57:07 <dcantrell> bookwar: we're all very anxious for details  :)
15:57:13 <sgallagh> libfoo-0.2.0 is released and builds successfully in Rawhide but fails in ELN.
15:57:21 <bookwar> dcantrell: that's a good thing
15:57:28 <sgallagh> Which libfoo package is in the Koji buildroot for ELN at this point?
15:57:34 <contyk> mhroncok: I'm not totally sure but I think only one package is available if you use inheritance this way (it's not using the external repo mechanism).
15:57:40 <nirik> it depends on how the koji inheritence is setup. ;)
15:57:48 <sgallagh> .fire nirik
15:57:48 <zodbot> adamw fires nirik
15:57:52 <contyk> mhroncok: And regarding NEVRA, whatever is tagged the last wins, regardless of it.
15:57:55 <mhroncok> contyk: to be clear, I'm mostly guessing from memory, so I'm not 100 % sure
15:58:02 <mhroncok> contyk: right
15:58:11 <sgallagh> nirik: In other words, we can decide which one we want and do that?
15:58:12 <contyk> And in the case of inheritance, I think only packages from the tag directly are considered if they exist.
15:58:25 <mhroncok> do we care that "eln" < "fc33"?
15:58:29 <contyk> So a Rawhide update wouldn't propagate if there's at least one build tagged in ELN.
15:58:35 <contyk> But neither I am 100% sure :)
15:58:37 <nirik> koji doesn't know anything about versions.
15:58:44 <nirik> it operates on src packages
15:58:51 <nirik> and whats tagged last
15:58:59 <contyk> Yes.
15:59:38 <zbyszek> Hmm, so that's going to be very painful, because every failed build can completely destroy the eln compose
16:00:25 <zbyszek> I mean: bump so and rebuild, rebuild dependent packages, one fails in eln — kaput, while rawhide is OK.
16:01:05 <zbyszek> A fire-fighting team will be required to keep this up, like with koji-shadow.
16:01:11 <contyk> If there are ELN rebuilds, they need to be rebuilt too in that case.
16:01:20 <contyk> But that should be automated by the ELN effort.
16:01:26 <sgallagh> OK, so this conversation is useful, but it would be better if we did this on devel list once the Change is announced.
16:01:48 <sgallagh> bookwar and I can try to add some more details to the Change page based on this discussion shortly.
16:02:02 <sgallagh> But I think this is getting rat-holed really fast.
16:02:21 <mhroncok> I agree
16:02:23 <mhroncok> this is not the place
16:02:25 <zbyszek> sgallagh and bookwar: yeah, this is potentially a very useful thing
16:03:30 <bookwar> zbyszek: we may change things as we go forward. If we can not get the stability we expect for example. but we'd like to try and measure how much fire-fighting it actually is going to be
16:03:49 <bookwar> so yes, let's continue on mailing list and me and sgallagh will update the pages and tickets as we go
16:03:58 <zbyszek> Let's move on.
16:04:04 <zbyszek> Anything else for open floor?
16:04:20 <zbyszek> If not, I'll close in a minute.
16:05:16 <zbyszek> Thanks for coming and the lively discussion ;)
16:05:17 <zbyszek> #endmeeting