- Friday, May 10, 2019

release-team@conference.openafs.org

Friday, May 10, 2019< ^ >

Room Configuration

Room Occupants

GMT+0
[00:41:04] mvita joins the room
[00:42:52] mvita leaves the room
[00:42:52] mvita joins the room
[10:46:57] kaduk@jabber.openafs.org/barnowl leaves the room
[11:57:19] mbarbosa joins the room
[12:46:08] meffie joins the room
[12:58:55] wiesand joins the room
[13:00:47] <wiesand> mornin
[13:01:26] <meffie> good morning
[13:01:34] <meffie> good afternoon too.
[13:01:43] <wiesand> Thanks.
[13:01:56] <wiesand> Warning: I'm grumpy today.
[13:02:27] <meffie> oh thank you for the warning. is everything ok?
[13:03:42] <wiesand> Nothing serious, but a number of not-so-minor annoyances lately have accumulated to the point that I shouldn't take decisions, make plans etc. today.
[13:04:14] <wiesand> Do you know "Flakes" from Frank Zappa's "Sheik Yerbouti" Album?
[13:04:58] <meffie> I dont think i know it.
[13:05:11] <mvita> good morning, I am tardy
[13:05:54] <wiesand> Pity. If you find it, transpose the issues into the IT world and you know where I am.
[13:06:10] <meffie> ok, i'll look for it later today.
[13:07:53] <wiesand> https://www.youtube.com/watch?v=AgyeUHH_V0g
[13:08:24] <meffie> bookmarked.
[13:09:21] <meffie> sorry, i have not done much gerrit reviewing the last few days. did fix more invalid html in openafs-web.
[13:10:29] <mvita> heh - +1 for the faux-Dylan bridge
[13:11:56] <wiesand> Thanks for the +1 on the fix for the remove-automake stack on macOS.
[13:12:50] <wiesand> faux-Dylan bridge?
[13:12:51] <meffie> yes, we had the same issue in the rpm spec file if i recall.
[13:13:34] <wiesand> hmm, that one looked pretty macOS specific to me
[13:15:08] <meffie> oh, it wasnt the spec file... it was my script to build rpms.
[13:15:56] <meffie> the name of the version macro changed.
[13:16:24] <meffie> (I have a script to build the "sources" from a git checkout)
[13:17:25] <wiesand> Anyway, I think that's what I have for today. The remove-automake stack was fixed by rebasing it onto 13584 and would be ready to merge if a single +1 on each change was considered  sufficient.
[13:18:24] <wiesand> Which would be a minor step towards 1.8.4pre1. At that pace, it's going to take a while though.
[13:19:14] <mvita> looking at the automake stack now
[13:19:27] <wiesand> I won't look at the 1.6.x mess today, since in my current mood I'd almost certainly decide to abandon 1.6 right away.
[13:19:48] <meffie> i think that stack was vetted fairly well by ben and andrew in the master branch.
[13:19:48] <mvita> sorry for the rough day, Stephan
[13:19:56] <wiesand> rough week, rather…
[13:20:40] <meffie> yes, i dont think 1.6.x or 1.8.4pre1 are super urgent day.
[13:21:01] <meffie> thank you for the 1.8.3 release last week!
[13:21:15] <meffie> s/day/today/
[13:21:55] <wiesand> Well, I really had a swift 1.8.4pre1 in mind.
[13:22:18] <wiesand> The very first rebase failing to verify was a "minor setback".
[13:22:54] <meffie> sorry about that.
[13:22:59] <wiesand> Found the fix a couple days later.
[13:23:14] <wiesand> And got a first +1 25 minutes ago.
[13:23:26] <wiesand> Did I mention I'm grumpy?
[13:23:41] <meffie> yes, I saw the fix before, but forgot to +1 it. :(
[13:24:57] <wiesand> No worries. It's really not  due to openafs matters.
[13:25:08] <meffie> i'll avoid talking about the html validation fixes.
[13:27:19] <wiesand> If I hadn't said that I'm not going to take any decisions today, my statement would be "I'll outright refuse to even look at those before 1.8.4pre1 and 1.6.24pre1 are done (or 1.6 is abandoned)."
[13:27:35] <meffie> :)
[13:28:48] <meffie> is there anything we can do to help with 1.8.4pre1?
[13:29:00] <wiesand> review review review
[13:29:05] <meffie> ?
[13:29:24] <meffie> it's hard to know what to review though.
[13:30:28] <meffie> do we need to figure out which patches need to be pulled up to the 1.8.x branch? or just review the ones already on that branch in gerrit?
[13:30:55] <wiesand> the latter would be a (cheap start)
[13:31:23] <wiesand> check out https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_8_x
[13:31:45] <wiesand> if the "CR" column is blank, review would be helpful
[13:32:07] <mvita> okay, working on that now
[13:32:42] <meffie> ok, thanks wiesand. i'll do that as well and ask others to do so.
[13:33:26] <wiesand> and yes, if you'd like to see stuff from master appear in 1.8.4pre1 please bring it up
[13:34:07] <wiesand> or pull it up, but please avoid more path conflicts - in doubt rather just bring it up
[13:35:16] <meffie> if there is a path conflict, we can be sure it it based against the correct gerrit commit
[13:35:37] <wiesand> ?
[13:35:52] <meffie> so the patched do not have merge conflicts.
[13:36:14] <meffie> so the commits do not have merge conflicts.
[13:38:37] <wiesand> sure, basing it on the other change(s) touching the same file will avoid merge conflivts
[13:38:50] <meffie> yes, that what i was trying to say. thanks.
[13:39:11] <wiesand> but only if those other changes don't already have path conflicts themselves
[13:39:30] <wiesand> which is not true for all changes ;lined up for 1.8.x right now
[13:41:05] <meffie> ok, would it help if i rebased them so we have a linear commit history?
[13:41:34] <wiesand> please let me know the rebases
[13:42:02] <wiesand> what would help is avoiding those path conflicts while pulling up in the first place
[13:42:44] <wiesand> s/know/do/
[13:42:51] <meffie> ok, i can take some time to investigate
[13:43:02] <meffie> thanks!
[13:43:04] <wiesand> did I type that?
[13:43:16] <wiesand> really sorry for being an asshole today
[13:44:03] <wiesand> anything else to discuss today?
[13:44:05] <meffie> i'd be more than happy to do the rebases.
[13:44:32] <mvita> I would like to understand the problem better so I can avoid pulling up and creating path conflicts
[13:44:44] <wiesand> (it's slightly comforting to know that Ben's week is probably even worse than mine ;-)
[13:45:01] <mvita> I know gerrit whines if two commits touch the same file
[13:45:13] <mvita> I don't know how to avoid the path conflicts
[13:45:27] <meffie> not from me. i think i see what is needed. 1. review branch:openafs-stable status:open, 2. linear commit history for merging to 1.8.x. 3 search for more commits on master which could be pulled up for 1.8.4pre1
[13:46:12] <meffie> mvita: you cant avoid path conflicts (it's a rather silly metric imho)
[13:46:42] <wiesand> so, "simply" check all changes already pulled up, make a list fo files they change, and if the change you'd like to pull up changes any of those, base your pullup on the latest change touching the file in question
[13:46:48] <wiesand> it's "that easy"
[13:46:51] <mvita> >  wiesand> what would help is avoiding those path conflicts while pulling up in the first place
[13:47:07] <mvita> I took that as marching orders
[13:47:51] <meffie> heres the thing.
[13:48:01] <mvita> Oh, thank you for the explanation Stephan
[13:48:21] <meffie> avoid path conficts *if* the commits are not in the same linage.
[13:49:13] <mvita> so, just to make sure I've got it:  after basing your pullup on the latest change touching the file in question, you then push the whole stack?
[13:49:46] <mvita> potentially creating a new PS for the base commits?
[13:50:07] <meffie> the base commits are unchanged, unless you rebased them.
[13:50:26] <mvita> okay - that's what I would have thought, just checking
[13:50:32] <meffie> ok.
[13:50:52] <mvita> (gerrit is a harsh mistress)
[13:51:08] <wiesand> it's a configuration choice
[13:51:20] <wiesand> and I think it's the right one
[13:51:48] <wiesand> we could opt for trusting "git merge" to always do the right thing
[13:51:48] <meffie> yes, we have it setup for a "cherry-pick" workflow for a linear history with lots of small independent patches.
[13:52:22] <meffie> (not complaining, i like the linear history)
[13:52:52] <meffie> github workflow is like the complete opposite :)
[13:53:38] <wiesand> but I'm aware of at least one case where a mismerge happened (during one of those dreaded security releases where we "git merge" rather than playing along with the strict gerrit rules) - luckily it was caught before the release
[13:54:28] <wiesand> the strict mode we're running gerrit in is a guarantee that what is actually merged when I hit the "submit" button is *exactly* what was reviewed
[13:54:41] <meffie> yes, good point.
[13:54:48] <wiesand> which is good good good
[13:54:58] <wiesand> alas, a bit inconvenient
[13:56:59] <meffie> ok, so bottom line, commits should be in the same order as in the master history. avoid "path conflicts" if not on the same commit lineage.
[13:57:16] <meffie> sounds good to me!
[13:58:36] <meffie> and when stephan merges, he can do them in order and there should not be any merge conflicts.
[13:58:56] <wiesand> the case where this becomes "interesting" is when several stacks touch the same files
[13:59:21] <wiesand> commonly, acinclude.m4 (though Mike thankfully defused that one a fair bit lately)
[14:00:27] <meffie> yay!
[14:00:54] <wiesand> really helps!
[14:02:12] <meffie> excellent. well i hope you have a better weekend. we'll try to make progress on the reviews and rebases (if needed)
[14:02:25] <wiesand> "interesting" because rebases tend to become non-trivial and/or invalidate previous reviews (the latter being a major waste of our scarcest resources)
[14:02:39] <meffie> yes
[14:03:26] <wiesand> I guess we're done. Let's adjourn.
[14:03:52] <meffie> have a good weekend.
[14:03:56] <wiesand> Have a nice weekend, thanks a lot, and sorry again for being a bit harsh today!
[14:05:52] <mvita> thanks Stephan!
[14:31:34] meffie leaves the room
[14:41:24] mvita leaves the room
[16:37:35] mvita joins the room
[16:43:37] mvita leaves the room
[16:52:10] mvita joins the room
[22:07:06] mbarbosa leaves the room