14:00:24 <mhroncok> #startmeeting FESCO (2021-03-17)
14:00:24 <zodbot> Meeting started Wed Mar 17 14:00:24 2021 UTC.
14:00:24 <zodbot> This meeting is logged and archived in a public location.
14:00:24 <zodbot> The chair is mhroncok. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:24 <zodbot> The meeting name has been set to 'fesco_(2021-03-17)'
14:00:29 <mhroncok> #meetingname fesco
14:00:29 <zodbot> The meeting name has been set to 'fesco'
14:00:29 <dcantrell> .hello2
14:00:30 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
14:00:32 <nils> .hello nphilipp
14:00:32 <mhroncok> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
14:00:32 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
14:00:32 <nirik> morning
14:00:33 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:00:35 <mhroncok> #topic init process
14:00:41 <sgallagh> .hello2
14:00:42 <Eighth_Doctor> .hello ngompa
14:00:42 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:00:45 <mhroncok> .hello churchyard
14:00:45 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
14:00:47 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
14:01:04 <mhroncok> hello nils, thanks for joining us!
14:01:24 * Eighth_Doctor waves
14:01:40 <nils> \o
14:01:47 <mhroncok> I see dcantrell, nirik, sgallagh, Eighth_Doctor and me
14:01:51 <mhroncok> that is a quorum
14:02:01 * sgallagh wonders who is setting up the steel cage...
14:02:03 <mhroncok> decathorpe and zbyszek are excused
14:02:30 * dcantrell waves
14:02:44 <mhroncok> we have only one topic in the agenda, so let's get that started
14:03:03 <mhroncok> #topic #2582 F35 Change: rpmautospec - removing release and changelog fields from spec files
14:03:10 <mhroncok> .fesco 2582
14:03:11 <zodbot> mhroncok: Issue #2582: F35 Change: rpmautospec - removing release and changelog fields from spec files - fesco - Pagure.io - https://pagure.io/fesco/issue/2582
14:03:22 <mhroncok> we have nils here who is one of the change owners
14:03:35 <mhroncok> we unfortunately don't have decathorpe
14:04:01 <mhroncok> (who is the main "naysayer")
14:04:17 <dcantrell> what were his objections?
14:04:39 <dcantrell> (I'm digging through previous meeting logs too, but if anyone remembers off the top of their head)
14:04:45 <nirik> there were some more comments in the issue this morning.
14:04:50 <mhroncok> that the source for the release number calculation should not be Koji but git history only
14:05:05 <dcantrell> ah, right
14:05:06 <nils> I think he felt our approach of emulating what maints do for the release field is too complicated
14:05:17 <mhroncok> I must say that I agree with decathorpe but I don't want to block the improvement just becasue of this
14:05:41 <dcantrell> that feels like something that could evolve over time as well, like we're not locked in to this method of computing a release number
14:05:48 <Eighth_Doctor> indeed
14:05:51 * nils nods
14:06:14 <mhroncok> well, we should ensure at least that if we do it this way, we won't have to drag this for backwards compatiblity reasons forever
14:06:19 * cverna waves
14:06:24 <mhroncok> hello cverna
14:06:26 <sgallagh> It's certainly better than my idea to just increment epoch every time Koji does a build :-P
14:06:26 * nirik doesn't like that ths src.rpm spec and git are divergent... and that we are putting a layer on top of rpm instead of working with rpm to get things better...
14:06:46 <Eighth_Doctor> well, apparently we're going to set the value in the spec file as part of prepping the SRPM
14:06:47 <nils> One thing I miss about "only use an integer" is how to tackle prereleases and snapshots. Right now the release field is "abused" for this.
14:07:05 <mhroncok> nils: it can be, but there are better ways
14:07:06 <Eighth_Doctor> This is something that is going to be separately tackled by FPC
14:07:08 <dcantrell> but there's really no better way to handle that now if we want strverscmp() to work
14:07:21 <dcantrell> we are encoding a lot in the Release field
14:07:26 <Eighth_Doctor> we're now at a point where pre-release and post-release information can be reasonably moved to Version
14:07:33 <mhroncok> nils: and even in release field, the autorelease macro can be used as part of something more complex
14:07:38 <Eighth_Doctor> since RHEL 8 got post-release modifier "^" backported
14:07:39 <nils> mhroncok, yeah, this was mentioned way back when, but we said then (and do now) that we don't plan to change the policy ourselves there
14:08:05 <mhroncok> the policy doe snot block the adoption of this, it just makes it easier
14:08:11 <nils> Eighth_Doctor, can "^" cater for git snapshots?
14:08:14 <Eighth_Doctor> Yes
14:08:18 <mhroncok> 1) there is no policy that prevents using ^ versions
14:08:21 <Eighth_Doctor> that's why it was added
14:08:41 <mhroncok> 2) even for packagers who want to use the "old fashioned" way of doing this, they can
14:08:49 <Eighth_Doctor> there's a draft of the policy update by tibbs to detail how to use it: https://fedoraproject.org/wiki/User:Tibbs/TildeCaretVersioning
14:09:43 * mhroncok 'd happily speed up the ^ policy approval if that is the only blocker for using git history
14:09:48 <Eighth_Doctor> The FPC meeting is tomorrow, and if I don't forget, I'll probably bring up taking that up
14:09:52 <mhroncok> unfortunatelly, it is not
14:09:52 <nils> ah there's tilde and caret now, I wasn't aware (and which is good)
14:10:13 <mhroncok> the main problem here is: multiple builds from the same commit: yes or no
14:10:31 <mhroncok> if we want to allow that, we cannot use git commit history as the source of the number
14:10:48 <Eighth_Doctor> well, we can't use that alone
14:10:49 <mhroncok> if we don't allow that, we cannot rebuild packages without (at least empty) commits
14:11:02 <mhroncok> Eighth_Doctor: right, I mean alone
14:11:18 <nils> one reason to allow that was to let people without commit right to the repo initiate mass rebuilds
14:11:37 <nils> i.e. you wouldn't have to have provenpackager to be a member of releng kicking that off
14:11:41 <Eighth_Doctor> as I said in the ticket, a big part of why I want this feature is because I want us to get provenpackagers out of the path for ordered rebuild cycles and mass rebuilds
14:12:03 <Eighth_Doctor> it's grunt work and should just happen in side-tags or whatever
14:12:03 <dcantrell> I agree with this.  multiple builds per commit should be allowed
14:12:06 <mhroncok> nils: that also means that packagers can accidentally rebuild any package, even repeatedly
14:12:39 <nils> that was (is) true before :) I think I'm guilty of that once or twice
14:12:53 <sgallagh> nils: Which part?
14:13:00 <mhroncok> nils: now you can only do that if the latest commit was not yet built on that dist-tag
14:13:10 <nils> accidentally rebuilding a package I didn't mean to
14:13:11 <mhroncok> and only once
14:13:36 <mhroncok> otherwise you need to commit and that is harder to do by accident and cannot be done by non-provenpackagers non-maintainers
14:13:40 <nils> ACK that the conditions under which that could be done where fewer
14:13:52 <mhroncok> anyway, here's my idea
14:14:07 <nils> flip-side, how much harm is there in accidental rebuilds?
14:14:13 <mhroncok> not sure
14:14:50 <sgallagh> That may depend on what changes in the buildroot in the meantime
14:14:54 <nirik> well, for rawhide: mirror churn and churn on end user machines?
14:15:14 <nirik> and confusion if buildroot changed.
14:15:15 <dcantrell> mostly infrastructure impact then, which is not to say accidental rebuilds are ok
14:15:23 <nils> nirik, still negligible in the grand sea of intentional builds in Rawhide I guess
14:15:31 <mhroncok> or ELN
14:15:34 <mhroncok> anyway...
14:15:37 <nirik> foo-1.0-1 and foo-1.0-2 have no commits between them and act differently
14:15:42 <nils> mhroncok, your idea :)
14:15:43 <mhroncok> as I see it, there are 3 opinions a fesco member can have at this point assuming we all want some form of this
14:16:11 <mhroncok> option 1) change as it is proposed is better than what decathorpe and mhroncok want
14:16:24 <mhroncok> option 2) what decathorpe and mhroncok say is better than the change proposal
14:16:37 <mhroncok> option 3) both options are equally good
14:17:05 <sgallagh> option 3 is more "both options have advantages and disadvantages"
14:17:22 <sgallagh> (Which is the fence I'm sitting on)
14:17:27 <mhroncok> sgallagh: option 3 means "I don't have a strong preference"
14:17:31 <nils> I think that's true for all three :o)
14:17:50 <nils> no option has only (dis)advantages
14:17:51 <mhroncok> I think that "both options have advantages and disadvantages" has been established as a fact
14:17:59 <sgallagh> OK, sorry
14:18:02 * nirik is wanting this in rpm. ;( but I guess thats not happening anytime soon.
14:18:05 <Eighth_Doctor> I'm firmly in the option 1 camp (sorry mhroncok and decathorpe)
14:18:28 <nils> nirik, RPM has little way to know about build history -- in koji or in git
14:18:49 <dcantrell> I feel like a lot of us are stuck on the side of wanting minimal to no impact to workflow, but this is a change and we'll probably see more work showing up.  I feel the advantages to this proposal outweigh disadvantages for the general packager.
14:18:52 <sgallagh> I'm leaning to option 1 mostly on the grounds that any improvement is better than no improvement, there's an implementation available, and we can tweak it as we go.
14:18:52 <nils> so all I see there is an interface/hooks that we could plug into
14:19:07 <mhroncok> I propose that I summarize 1/2/3 in the ticket in better words and we let fesco members vote on this so we see where everybody stands. than we can vote on the most popular option from 1/2 or let the change owners decided if both are equally popular
14:20:36 <nirik> nils: I'm not sure there's not a solution that would work in rpm... at least for the orig problem of allowing multiple PR's to not conflict
14:20:36 <mhroncok> that however is only possible if the change owners would be OK to implement 2 if that is what the majority of fesco wants
14:20:37 <Eighth_Doctor> nils: btw, my objection to %autochangelog is that I am generally not a fan of git commit noise being used wholesale for changelogs
14:20:37 <nils> we discussed this the other day and think that option 2) would take more time for us, just because of the change in algorithm (even if it's simpler)
14:20:47 <dcantrell> mhroncok: should we first vote on your original option list?
14:21:10 <nils> Eighth_Doctor, a keyword to "skip this from %changelog" isn't off the table
14:21:29 <mhroncok> dcantrell: I wanted to ask nils if it even makes sense. if they say "take the proposal as is, or reject it" the vote is moot
14:21:39 <Eighth_Doctor> nils: no, it isn't, but that hasn't been figured out yet :/
14:21:47 <dcantrell> mhroncok: understood
14:21:59 <nils> yeah pingou and I agreed not to be stubborn just for the sake of it ;)
14:22:03 <mhroncok> nils: the question is: is this something you would consider to work on if fesco agrees on it, or not?
14:22:07 <sgallagh> nils: I'd personally prefer the reverse, a keyword for the changelog message, ignore the commit otherwise.
14:22:54 <dcantrell> sgallagh: I've started doing that in my projects and it's nice, because the resulting log for the spec file looks "cleaner" and I don't pick up all the silly housekeeping commits that follow up to a feature commit, for instance
14:22:55 <sgallagh> Because I guarantee you that 20% of changelogs would be "Add the tarball to the lookaside cache this time"
14:23:07 <Eighth_Doctor> sgallagh: the problem is the inability to edit the changelog
14:23:25 <Eighth_Doctor> my suggestion was annotating the commits and allowing annotations to be editable
14:23:25 <nils> which inability
14:23:25 <sgallagh> Eighth_Doctor: I'm not following
14:23:36 <Eighth_Doctor> sgallagh: commit messages themselves are immutable in dist-git
14:23:40 <Eighth_Doctor> we cannot amend commits
14:23:43 <sgallagh> Oh, wait. I see what you mean
14:23:53 <sgallagh> Hmm, I hadn't considered that.
14:24:04 <Eighth_Doctor> right now, we have no working strategy with that constraint
14:24:06 <nils> but we can amend/overwrite the changelog (I hope we haven't missed putting that in the proposal text :o)
14:24:09 <Eighth_Doctor> that's why I don't want autochangelog
14:24:48 <sgallagh> As nils says, the proposal allows us to hand-edit the spec
14:25:02 <Eighth_Doctor> right, but once you detach the changelog and use autochangelog, that's gone
14:25:04 <sgallagh> Which I think is probably good enough for the rare case when it needs editing.
14:25:07 <sgallagh> No, it's not.
14:25:07 <nils> Eighth_Doctor, nah
14:25:11 <Eighth_Doctor> no?
14:25:19 <nils> "rpmautospec will include the changelog as is in the %changelog section and will use all the commits made to the repository after the last change of the changelog file to generate the changelog."
14:25:22 <sgallagh> Reread the proposal, that's in there :)
14:25:23 <nils> that works
14:25:28 <nils> we've tested it :o)
14:25:45 <nils> not being able to edit the %changelog would be a no-no to us, too
14:25:54 <Eighth_Doctor> hmm, so then we'd need a workflow for refreshing the changelog to not lose entries, but sure at least it's technically there
14:26:02 <sgallagh> nils++ for forethought
14:26:02 <zodbot> sgallagh: Karma for nphilipp changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:26:20 <nils> sgallagh, we tried to get all bases covered :)
14:26:31 <Eighth_Doctor> I'm less hesitant on autochangelog, but I'm rather cautious there
14:27:00 <Eighth_Doctor> I think autorelease will be fine, but I think we need to hammer out workflows for changelogs before allowing autochangelog
14:27:01 <mhroncok> ok
14:27:07 <mhroncok> I'd like to vote on 1/2/3 asynchronously, since we don't have everybody here and I don't think this is urgent.
14:27:22 <mhroncok> does that sound good, or do you want to do a different thing?
14:27:34 <Eighth_Doctor> isn't everyone but decathorpe here?
14:27:55 <sgallagh> I don't think those 1/2/3 covers everything
14:28:08 <sgallagh> Since there's at least some question about a line-item veto on autochangelog.
14:28:31 <nils> Eighth_Doctor, mhroncok mentioned zbyszek being absent, too
14:28:37 <Eighth_Doctor> ah
14:28:38 <mhroncok> Eighth_Doctor: ignatenkobrain and zbyszek is missing.
14:28:45 <nils> oh igor too
14:28:57 <dcantrell> asynchronously sounds better in this case
14:28:58 <Eighth_Doctor> welp
14:29:00 <mhroncok> sgallagh: I don't follow, is this something to discuss here?
14:29:01 <Eighth_Doctor> yeah
14:29:16 <sgallagh> mhroncok: What Eighth_Doctor and I were just discussing
14:29:43 <mhroncok> yes, but I mean, is this something you'd not approve in the current form?
14:29:44 <nils> One thing: from my POV (and I think pingou's as well), having only autorelease but not -changelog isn't very worthwhile to have
14:29:53 <mhroncok> nils: I agree
14:30:14 <sgallagh> *I* am in favor, but I'm not sure where Eighth_Doctor stands right now
14:30:26 <nils> we wouldn't get easier PRs, nor easier mass rebuilds
14:30:28 <sgallagh> And whether that needs to be discussed/voted on independently
14:30:37 <mhroncok> my undrstanding was that Eighth_Doctor is not fully satisfied but he is OK with it
14:30:40 <sgallagh> nils: +1
14:30:44 <Eighth_Doctor> mhroncok: correct
14:30:57 <sgallagh> OK, then. I just wanted that on record :)
14:30:59 <Eighth_Doctor> I'd like to see workflows with `%autochangelog` hammered out and documented
14:31:09 <sgallagh> Reasonable
14:31:11 <Eighth_Doctor> because I don't fully understand the workflows around it based on the Change
14:31:26 <nils> and we have to take the blame for not having that documented last time, since we discussed a lot about it
14:31:45 <Eighth_Doctor> yeah, I remember us having a lot of convos about it
14:31:54 <Eighth_Doctor> because we've made it hard for ourselves :)
14:32:14 <nils> and with "us" I mostly mean myself and pingou
14:32:27 <Eighth_Doctor> I disagree that %autorel is not useful without %autochangelog though
14:32:40 <nils> it's a lot less useful without
14:32:41 <Eighth_Doctor> but I'm okay with being in the minority there
14:32:48 <mhroncok> #action mhroncok to summarize the three options in the ticket, fesco members to vote until the next meeting where we formally approve/reject the most popular option
14:32:50 <mhroncok> ack?
14:32:58 <nils> I wouldn't say it's "not useful" at all
14:33:08 <dcantrell> mhroncok: +1
14:33:10 <Eighth_Doctor> nils: well if your objective is to make rebuilds work without human interaction, then %autorel is sufficient :)
14:33:14 <Eighth_Doctor> mhroncok: +1
14:33:37 <nils> Eighth_Doctor, point taken, but our other primary objective was easier PRs :)
14:33:41 <sgallagh> mhroncok: ack and thank you
14:33:42 <nirik> mhroncok: +1
14:33:52 <mhroncok> ok
14:34:05 <mhroncok> nils: thank you very much for joining us here, I know this must be tedious :D
14:34:13 <mhroncok> nils++
14:34:13 <zodbot> mhroncok: Karma for nphilipp changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:34:16 <cverna> thanks mhroncok
14:34:23 <nils> thanks for having me, and no worries :)
14:34:27 <mhroncok> anything else for this topic?
14:34:51 <nils> thanks mhroncok++
14:35:02 <mhroncok> #topic Next week's chair
14:35:09 <nils> churchyard++ even?
14:35:16 <mhroncok> nils: :/
14:35:24 <nils> -EOUTOFCOOKIES
14:35:31 <mhroncok> I guess
14:35:40 <mhroncok> who wants to chair the meeting next week
14:36:25 <mhroncok> I guess "wants" is too strong :D
14:36:38 <mhroncok> who is able to chair the meeting next week?
14:36:49 <dcantrell> I can
14:37:27 <mhroncok> #action dcantrell will chair next meeting
14:37:29 <mhroncok> dcantrell++
14:37:33 <mhroncok> thank you
14:37:37 <dcantrell> sure thing
14:37:39 <mhroncok> #topic Open Floor
14:38:50 <mhroncok> I guess nobody has a topic
14:38:59 <dcantrell> I got nothing
14:39:01 <mhroncok> how are you all doing?
14:39:07 <dcantrell> I've been better
14:39:28 <dcantrell> covid anxiety is getting at me
14:39:34 <nirik> hanging in there. ;)
14:39:53 <dcantrell> miss the office
14:39:54 <nirik> dcantrell: hopefully things will be better later in the year... we can only hope
14:40:02 <dcantrell> nirik: yes, hoping so
14:40:43 <mhroncok> hang on and hopefully it will not get much worse before it gets better
14:41:03 <mhroncok> see you, ending the meeiting in couple secs
14:41:29 <mhroncok> #endmeeting