- Thursday, May 12, 2022

release-team@conference.openafs.org

Thursday, May 12, 2022< ^ >

kaduk@jabber.openafs.org/barnowl has set the subject to: openafs release team

Room Configuration

Room Occupants

GMT+0
[09:18:14] mvitale leaves the room: Replaced by new connection
[09:18:15] mvitale joins the room
[15:53:39] meffie joins the room
[15:57:00] Cheyenne joins the room
[15:58:20] wiesand joins the room
[15:58:35] <wiesand> Hello
[16:00:01] <Cheyenne> hello all
[16:00:05] <kaduk@jabber.openafs.org/barnowl> greetings
[16:00:22] <mvitale> hello
[16:00:51] <Cheyenne> Ben, my wife and I will be out in your neck of the woods next week (though we have a pretty packed schedule visiting some family)
[16:02:27] <kaduk@jabber.openafs.org/barnowl> Oh fun, it should be a great time to visit
[16:03:32] <meffie> greetings. (dealing with an internet outage here, currently on my phone)
[16:03:32] <wiesand> Ok, since last time I convinced myself that merging the prepare-14387 stack (https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_8_x+topic:prepare-14387) would be a reasonable next step, whether towards a 1.8.8.2 or a 1.8.9
[16:05:08] <meffie> excellent news, thank you
[16:06:10] <wiesand> next could be some of the FBSD ones, but I need another check for clashes (probably none, at least not real ones)
[16:06:53] <kaduk@jabber.openafs.org/barnowl> (great time to visit the region in terms of the weather/climate, that
is, though I'm of course willing to try to meet up if there becomes an
opening in the packed schedule)
[16:07:22] <wiesand> that would get us closer to pulling up the LINUX_ENV cleanup changes w/o much editing (and wo/much editing in the future either)
[16:08:26] <Cheyenne> wiesand: I have a stack that I'm still reviewing (but I've pushed to github) that includes the 5.17 stuff plus some other changes that prevent some drift.  I'll rebase that stack on what you have there
[16:08:52] <Cheyenne> https://github.com/CheyenneWills/openafs/commits/openafs-stable-1_8_x/linux-5.17-ALT
[16:09:21] <wiesand> the alternative is what we discussed last week: go for Cheyenne's stack of what's needed for an immediate 1.8.8.2 - with those "minimal adjustments" I'm really afraid would get us into conflict hell
[16:09:47] <Cheyenne> it pulls in some of the prereqs and avoids some of the conflict hell
[16:10:02] <wiesand> Cheyenne: thanks
[16:10:45] <Cheyenne> I think if I pull in your stack as well it removes one very minor conflict.
[16:10:48] <wiesand> avoiding some of the conflict hell is achieved by "minor code adjustments"?
[16:11:43] <wiesand> well the stack I'm proposing to merge today is just in preparation of the more complicated pullups…
[16:11:48] <Cheyenne> there were 2 conflicts, one is a LINUX_ENV related the other was a small block of code isn't in 1.8.x (and it's for the fallthrough changes so it's not a biggie)
[16:12:39] <wiesand> the low hanging fruit, just to remove some complexity
[16:12:40] <Cheyenne> the other conflict I ran into was because a commit was already in 1.8.x and the order between master and 1.8.x were different
[16:13:18] <wiesand> which is exactly what I'd like to avoid (and in this case, obviously failed)
[16:14:07] <Cheyenne> and that conflict was very very minor
[16:14:11] <kaduk@jabber.openafs.org/barnowl> It is bound to happen occasionally as we change our mind on whether we
want something in 1.8 or not
[16:15:16] <meffie> this is true.
[16:15:41] <wiesand> change A is not immediately required for stable, change B is merged out of order (typically with a "minor adjustment"), later you try pulling up some change C and that fails because it requires change A
[16:16:36] <meffie> yes, that bound to happen sometimes.
[16:17:11] <meffie> at that point change C needs to be backported to stable.
[16:17:13] <Cheyenne> In this case it was Change B was merged out of order (with the minor adjustement), then change A gets pulled in and fails
[16:17:25] <Cheyenne> so a minor adjustment to A
[16:17:43] <meffie> ah, ok. thanks
[16:18:36] <wiesand> yes, but if we let that happen too often, those "minor conflicts" grow exponentially - we should not let it happen if it's easy to avoid, for example by pulling in some indentation fix
[16:18:40] <Cheyenne> So the "bulk" of what I have in the ALT stack is some extra autoconf updates and the fallthrough updates
[16:20:21] <wiesand> I can deal with pullups. But too much skew, and very quickly every pullup becomes a real backport. And those are often beyond me.
[16:21:13] <wiesand> The fallthrough updates are marked "CAN OF WORMS" in my notes.
[16:21:46] <Cheyenne> I think the ALT stack I have addresses some of the skew, and the tweaks have been fairly simple/minor
[16:22:03] <meffie> that's good news. thanks Cheyenne
[16:22:07] <wiesand> Maybe I'm just too simple-minded, or simply lack experience with and a grip on a code base and product as complex as openafs.
[16:23:49] <meffie> does gerrit show real merge conflicts before a patch is merged, or just the maybe merge conflict "path conflict" thing?
[16:23:49] <Cheyenne> I'm still trying to wrap my head around it as well..
[16:24:27] <wiesand> It's also a problem for me that those edits most often are not noted in a change comment or somewhere else, but since they have caused me pain in the past, I'm spending time on comparing the 1.8.x "edition" of changes with the master ones.
[16:25:05] <Cheyenne> Oh.. I have a little script that helps with that..
[16:25:18] <kaduk@jabber.openafs.org/barnowl> I think gerrit just shows a "cannot merge" notification, and I don't
remember if there's clear documentation of what exactly that means.
[16:26:04] <meffie> ok, just curious.
[16:26:05] <kaduk@jabber.openafs.org/barnowl> I think the "git cherry" tool can help automate the comparing of
commits.  I will often just do a `diff <(git show master-commit) <(git
show stable-commit)` to look at the diff-of-diffs
[16:27:12] <Cheyenne> https://gist.github.com/CheyenneWills/f601ee40f68ca15105f955c6fdb3f67f
[16:27:19] <wiesand> not sure how to do that for changes not yet merged
[16:27:56] <kaduk@jabber.openafs.org/barnowl> you can fetch specific commits from gerrit, like `git fetch gerrit
refs/changes/23/14923/5`
[16:28:16] <meffie> yes, i do that frequently
[16:28:50] <meffie> (you can get all of them too ;)
[16:28:56] <Cheyenne> git commit-diff <sha1> <sha2>   --or-- git commit-diff <sha1>   .. which will compare against the last (cherry pick line)
[16:29:14] <wiesand> er, no, thanks
[16:29:59] <wiesand> but thanks for those hints
[16:30:40] <kaduk@jabber.openafs.org/barnowl> I have a separate repo that fetches all of them, to not "clutter up"
my primary workspace.
[16:30:56] <meffie> all of the gerrits are just commits on branches so you have fetch them on in a sandbox repo.
[16:31:23] <meffie> what was the git config for that ben? i dont have my sandbox handy.
[16:32:15] <kaduk@jabber.openafs.org/barnowl> [remote "origin"]
        url = ssh://gerrit.openafs.org/openafs.git
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = +refs/changes/*:refs/remotes/origin/changes/*
[16:32:34] <meffie> thanks!
[16:33:40] <wiesand> So, how to proceed?
[16:36:05] <meffie> should cwills push his stack based on 1.8.x to the "changes for 1.8.x" branch in gerrit?
[16:36:46] <meffie> then those could be reviewed and merged in order?
[16:37:43] <kaduk@jabber.openafs.org/barnowl> Looking over Cheyenne's linux-5.17-ALT branch, I think I'm okay with
using that as the basis for 1.8.x-next
[16:39:08] <meffie> reading the scroll back, didnt cwills say he could rebase on ...
[16:39:11] <Cheyenne> I'll send out a note with my "notes" on that branch and I can push it to gerrit for review.  It gets us to fedora 34/35 level (I believe -- and I can double check)
[16:39:48] <Cheyenne> and I could rebase it on what wiesand has for the linux_env cleanup as well -- shouldn't be difficult
[16:40:09] <meffie> yes, that's i the linux_env changes.
[16:40:16] <meffie> that is it.
[16:40:32] <wiesand> in that case we should probably just abandon what I've pulled up so far, and return to the mode we initially started out with - you pull stuff up, you review, and I click the submit button - which didn't work out either, because that click is just not going to work very quickly
[16:41:41] <meffie> what if we do a mode where we have the changed in a fixed batch (in some time interval)?
[16:42:08] <meffie> the changes (sorry my fingers are not working well)
[16:43:00] <wiesand> as long as there's always just single fixed batch, that would work ;-)
[16:43:27] <meffie> yes, thats what i mean. just one batch at a time, like this one.
[16:43:50] <meffie> maybe give them a single gerrit topic or something.
[16:44:00] <kaduk@jabber.openafs.org/barnowl> I think we can arrange our workflow to have a single batch (or topic)
at a time, with wiesand directing what that topic is
[16:44:56] <meffie> that sounds really good. we can prep the batch in github and then get the ok to push the batch into gerrit when it is ready.
[16:45:11] <wiesand> hmm, that would require a strict rule that nothin is pulled up ever, expect on top of that stack
[16:45:18] <meffie> yes
[16:45:36] <meffie> but that is because we dont want merge commits ;)
[16:46:05] <wiesand> and always merge in order - a single change for which you can't get timely review, and everything grinds to a halt
[16:46:32] <meffie> and we can try to minimize backports, but in some case we will not be able to avoid minor changes to patches
[16:46:39] <Cheyenne> I think having a step/place where potential changes for 1.8.x can be batched up and "pre-reviewed" would be helpful
[16:46:40] <kaduk@jabber.openafs.org/barnowl> Well, isn't that why we have this weekly meeting -- to strongarm
people into doing timely reviews of the current blockers?
[16:47:19] <meffie> oh. good point. :)
[16:47:32] <Cheyenne> And maybe use the whiteboard as a holder for the wish list items
[16:48:26] <meffie> for the order of the gerrits, i was thinking it could be possible to create a "order" number based on git log of the gerrits in the various branches. not sure how to make that available.
[16:48:49] <meffie> maybe it could be just on the wiki, like the other gerrit patches.
[16:50:37] <wiesand> I'm more and more afraid that the problem is just me, and I'm simply not up to the job.
[16:50:43] <kaduk@jabber.openafs.org/barnowl> The `git describe sha1` output includes a "order" number among other
components
[16:52:10] <meffie> well, i dont think backports are a developer responsibility. the release manager is important for setting direction and making sure we are on track
[16:52:29] <meffie> er, i think backports are a developer responsibility
[16:52:41] <Cheyenne> BTW -- the newer versions of gerrit have some features that might also be helpful (WIP changes, and private changes)
[16:53:14] <kaduk@jabber.openafs.org/barnowl> Yes, we are overdue for some gerrit upgrades
[16:53:50] <meffie> Cheyenne deployed the new version here for us to try and use for testing buildbot changes.
[16:54:15] <meffie> maybe he can help when it comes time to upgrade.
[16:54:29] <Cheyenne> the UI is different and the syntax for adding a topic to a commit is also different
[16:54:40] <Cheyenne> but yes -- I could help out with an upgrade
[16:55:42] <kaduk@jabber.openafs.org/barnowl> ok, thanks
[16:55:54] <meffie> oh, and the batches idea....
[16:56:17] <kaduk@jabber.openafs.org/barnowl> Before we move over to master/1.9, I just wanted to get a sense for
whether we think we actually know the next steps for 1.8
[16:56:31] <meffie> i think it would be nice for the batch to come with the text for the NEWS file :) to do that in chunks too.
[16:56:52] <kaduk@jabber.openafs.org/barnowl> It sounded like the stuff wiesand already pulled up is good and should
go in, and then once that goes in Cheyenne can push the new batch to
gerrit for review?
[16:56:54] <Cheyenne> I will rebase my ALT stack on top of the LINUX_ENV stack that wiesand has in gerrit
[16:57:05] <Cheyenne> and push to gerrit for review
[16:58:12] <kaduk@jabber.openafs.org/barnowl> That seems okay to me; Stephan, is that okay for you?
[16:59:39] <wiesand> that stack does *not* yet contain the LINUX-ENV stuff, and there are a few nontrivial clashes to resolve before
[17:00:09] <kaduk@jabber.openafs.org/barnowl> Oh, whoops, I missed/forgot that.  So Cheyenne should wait?
[17:00:35] <wiesand> please
[17:00:40] <kaduk@jabber.openafs.org/barnowl> ok
[17:01:04] <Cheyenne> acj
[17:01:05] <Cheyenne> ack
[17:01:05] <meffie> i missed that as well, thank you for explaining again.
[17:02:21] <kaduk@jabber.openafs.org/barnowl> And because the caffeine hasn't kicked in yet, if I'm reviewing stuff
in gerrit I want the "prepare-14387" topic?
[17:02:25] <wiesand> if you can't hold your horses, go ahead and I'll just revert to "give directions, click upon sufficient review, if it doesn't work 'strongarm' folks into fixing it" mode
[17:05:42] <kaduk@jabber.openafs.org/barnowl> And since we're past the hour, I'll note that the macos/apple-silicon
stack all has +2s except for 14938 which was just a complaint about
the commit message, and I pushed an updated commit message during the
meeting.  So in theory that should be landing real soon now
[17:05:43] <wiesand> yes, that topic contains the easy part of getting 14387 (and later, 14388 and 14389) pulled up without (much) editing *nor* potential for the A/B/C problems later on
[17:05:59] <kaduk@jabber.openafs.org/barnowl> Excellent, thanks
[17:07:32] <kaduk@jabber.openafs.org/barnowl> I don't have a hard stop, but shouldn't spend too much more time than
the 1-hour timeslot.  Other topics for today?
[17:08:04] <Cheyenne> I have some work to do on the linux 5.18 -- but it appears to be mostly "cosmetic" or some refactoring
[17:08:35] <Cheyenne> And.. there are some new clang/gcc related patches that were fairly minor to fix, but there is some feedback I need to go through
[17:08:39] <kaduk@jabber.openafs.org/barnowl> *nods*
[17:08:55] <kaduk@jabber.openafs.org/barnowl> I saw some of that clang/gcc discussion go by -- thank you and Andrew
for the work and review
[17:09:10] <meffie> just to mention the foundation created a draft schedule for the workshop and i'm putting into the workshop pages. i'll need a vos release when it is ready (soon i hope)
[17:09:37] <Cheyenne> dang compilers are getting too smart for their own good
[17:11:07] <Cheyenne> on a personal note.. I'm on vacation next week
[17:11:39] <wiesand> I have no other topics. Sigh, I'm beginning to feel like Beaker. mee-mee-mee-mee…
[17:12:32] <mvitale> heh, Beacker!
[17:14:29] <wiesand> Adjourn? Time to go for a walk, and then get to bed early.
[17:14:49] <Cheyenne> 2nd
[17:15:35] <mvitale> concur
[17:15:47] <wiesand> Enjoy your vacation.
[17:17:12] <Cheyenne> thanks :)
[17:18:18] meffie leaves the room
[17:21:07] <kaduk@jabber.openafs.org/barnowl> thanks everyone :)
[17:35:52] mvitale leaves the room: Replaced by new connection
[17:35:54] mvitale joins the room
[17:56:34] wiesand leaves the room
[20:11:05] mvitale leaves the room: Replaced by new connection
[20:11:07] mvitale joins the room
[21:32:47] mvitale leaves the room
[21:35:43] mvitale joins the room