Home
release-team@conference.openafs.org
Friday, November 1, 2019< ^ >
Room Configuration
Room Occupants

GMT+0
[12:01:55] mbarbosa joins the room
[12:19:36] mbarbosa leaves the room
[12:19:38] mbarbosa joins the room
[13:00:32] meffie joins the room
[14:15:51] meffie leaves the room
[14:55:45] wiesand joins the room
[15:00:08] <wiesand> Hello
[15:00:47] <kaduk@jabber.openafs.org/barnowl> I'm running a few minutes behind schedule...
[15:02:37] meffie joins the room
[15:03:03] <wiesand> We're not quite complete anyway it seems… take your time while I have a look at the recent churn in gerrit
[15:03:13] <meffie> good day
[15:03:42] <meffie> it's not churn, it is updates :)
[15:03:56] <wiesand> Oh, hello Mike… I kind of expected you to be sleeping with the head on your keyboard after working all night on 1.6.x ;-)
[15:04:25] <wiesand> a lot of updates
[15:04:36] <meffie> ha! sorry i didnt get to the rebasing until thursday afternoon. i was not too bad.
[15:05:07] <wiesand> Looks like you gave 1.6.x a future?
[15:05:09] <meffie> there are a few that need to be decided if we should abandon.
[15:05:24] <wiesand> Saw some of those.
[15:05:31] <meffie> ok, thanks.
[15:05:43] <wiesand> Like the old "backup manpage fixes".
[15:06:29] <wiesand> Yes, that stack ended up being depndent on libcmd changes we most likely don't want to backport to 1.6
[15:06:40] <meffie> that one can be spit and we can take the man pages fixes. the issue is the 'param alias' -dryrun
[15:06:57] <wiesand> And I just left it sitting there because there actually was a doc issue worth fixing.
[15:07:02] <meffie> agree, i dont think we want to backport them. good
[15:07:40] <wiesand> That's why they were still lingering.
[15:08:00] <meffie> i will fix the man page fixes an resubmit it.
[15:08:56] <wiesand> I'll have to read through your comments and the changes-to-the-changes you made to get a more complete picture.
[15:09:09] <kaduk@jabber.openafs.org/barnowl> [okay, back in front of a computer]
[15:09:48] <meffie> Stephan, can you abandon 11676?
[15:10:08] <wiesand> Are there any *major* decisions to be taken (the "between a rock and a hard place" kind?)
[15:10:19] <meffie> i dont think so.
[15:11:29] <meffie> the other issue is the des logging warnings...
[15:11:57] <meffie> 10833 and 10834
[15:12:19] <meffie> i feel the should just be abandoned
[15:12:48] <wiesand> abandoned 11676
[15:13:17] <meffie> 10834 is 1.6.x only but needs 10833, which is not included in master/1.8.x
[15:13:23] <meffie> yay! thank you
[15:13:49] <meffie> i'll update the man page one and resubmit.
[15:14:53] <meffie> we could abandon 10833, and i could look to see if i can redo the 1.6.x one. but it just adds log messages, so maybe it's not worth the change.
[15:15:12] <wiesand> 10833/4 can only be abandoned by the owner (Andrew) or Ben though
[15:15:13] <kaduk@jabber.openafs.org/barnowl> I guess the real question is whether 10831 should go into master or
not
[15:15:23] <kaduk@jabber.openafs.org/barnowl> (since that's the master analogue of 10833)
[15:15:31] <kaduk@jabber.openafs.org/barnowl> I will try to look at it this week
[15:15:52] <meffie> ah i was wondering why there was a duplicate!
[15:16:22] <meffie> i assume it was an error? they have the same Change-Id string (i think)
[15:16:53] <kaduk@jabber.openafs.org/barnowl> Huh, I thought the gerrit we were running at that time was very
unhappy about duplicate change-Ids
[15:17:47] <meffie> but maybe both can be abandoned :)
[15:18:02] <kaduk@jabber.openafs.org/barnowl> It is a possibility :)
[15:19:27] <wiesand> Gerrit could already cope with duplicate change-ids, as long as they were on different branches, when I started out here.
[15:19:40] <meffie> ah! ok.
[15:20:21] <wiesand> But yes, this change was submitted to 1.6 and master at the same time, which is one reason for my -2 on it.
[15:20:27] <meffie> (that could explain why the ssh tools have the --branch option in addition to the change-id)
[15:22:09] <wiesand> So, what are the obstacles to a 1.6.25pre1?
[15:22:38] <meffie> just reviews and news update
[15:23:24] <meffie> it's nice to be able to build a 1.6.x version, since this has updates for linux 5.x
[15:23:38] <wiesand> review review review then… I should be able to take care of NEWS
[15:23:52] <meffie> thank you.
[15:23:59] <wiesand> speaking of which - any news on Linux 5.4?
[15:24:57] <wiesand> mike: the changes that should go into 1.6.25 are organized as a single stack now?
[15:25:48] <meffie> as far as i know openafs is ok on linux 5.4. our ubuntu based builldbots are waiting for ubuntu packaging fixes not related to openafs.
[15:26:03] <wiesand> ah ,ok
[15:26:18] <meffie> cwills has been building on gentoo in the mean time.
[15:26:33] <meffie> just to be sure we are ok.
[15:26:36] <wiesand> btw, during your work on the 1.6 backlog, did you spot what I did wrong or didn't get?
[15:27:56] <kaduk@jabber.openafs.org/barnowl> (I'm kind of curious how the ubuntu issues manifest, though it sounds
like I don't need to know)
[15:28:23] <meffie> there were some merge conflicts i had to resolve. is that what you mean?
[15:30:19] <wiesand> mike: probably - how did those come about? merge conflicts not trivial to resolve shouldn't ever happen on the stable branch unless something went seriously wrong before - I believe
[15:30:25] <meffie> (i'll ask cwills for the ubuntu ticket number)
[15:32:08] <meffie> wiesand: there was some code skew for the ih_sync_thread stuff. we has some 1.6.x specific scaffolding for --sync "delayed" option in 1.6.x
[15:33:07] <meffie> (cwills tells me the ubuntu ticket is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849348 )
[15:33:32] <kaduk@jabber.openafs.org/barnowl> thanks!
[15:34:23] <meffie> any help to get some attention would be much appreciated ;)
[15:35:44] <wiesand> ah, I see - does the way you resolved this change the default sync behaviour in 1.6.x?
[15:36:28] <meffie> good question! let me check.
[15:38:29] <wiesand> (I'll still have a closer look - need to understand why a change could be pulled up and verified by buildbot but later couldn't be rebased on top of other seemingly innocious changes without major rework)
[15:38:49] <meffie> if it does, we should just abandon 9407
[15:43:12] <wiesand> sounds like it actually does if 9407 is in the stack - and yes I think it's questionable to change something like that at this point in time in the 1.6 series…
[15:44:58] <meffie> it does not change the -sync default.
[15:45:55] <meffie> it just removes the ability to turn off the sync thread (which is super dangerous).
[15:46:33] <meffie> but yes, i think we could just abandon 9407 and tell people to upgrade to 1.8.x :)
[15:47:16] <meffie> correction: it removes the ability to turn *on* the sync thread.
[15:49:06] <meffie> (the sync thread was our "idledead" if that helps ;)
[15:51:12] <wiesand> well we never removed (client side) idledead, did we ;-)
[15:51:44] <kaduk@jabber.openafs.org/barnowl> something about some sites being reliant on it?
[15:52:43] <wiesand> it's even still on by default with no option to switch it off
[15:55:15] <meffie> i dont remember all of the ihandle sync options. i know the thread was removed in 1.8.x and later.
[15:55:31] <meffie> and i think is is optional (but dangerous) in 1.6.x
[15:55:36] <kaduk@jabber.openafs.org/barnowl> Yeah, I don't remember much about this either.
[15:56:00] <wiesand> always|delayed|onclose|never
[15:56:19] <meffie> it may be moot at this point
[15:58:49] <wiesand> 9407 seems to change the semantics of "delayed" to become those of "onclose"
[15:59:40] <meffie> yes
[16:00:30] <meffie> the alternative is to remove the option. i guess that's better than lying.
[16:01:29] <wiesand> It's a non-default option not recommended in the documentation. And BTW 9407 doesn't change the documentation. I've been bashed before for even considering such a change in the middle of a stable series…
[16:02:04] <meffie> ah good point, i'll do an update to fix the documentation!
[16:02:55] <meffie> and remove the "delayed" option from the list of available -sync options.
[16:04:10] <kaduk@jabber.openafs.org/barnowl> Yeah, the tradeoff between "no drastic changes on stable" and "don't
let users shoot their feet off" is not always clear
[16:04:51] <wiesand> "This was the only behavior allowed in OpenAFS releases starting
               from 1.4.5 up to and including 1.6.2."
[16:06:23] <kaduk@jabber.openafs.org/barnowl> (where is that quote from?)
[16:09:14] <wiesand> We never ever had data corruption with 1.4.x servers (x >= 7), and we had a lot of those for a long time, and we did check regularly. Except that client side idledead *did* cause data corruption on busy fileservers. Maybe the ih_sync bug is what it actually triggered after all.
[16:09:32] <wiesand> That quote is from the 1.6.24 fileserver(8) manpage.
[16:10:00] <wiesand> fieserver(\8\)
[16:13:13] <meffie> anything else today? lunch is calling :)
[16:14:05] <kaduk@jabber.openafs.org/barnowl> I got nothing useful done this week, so nothing here :(
[16:15:06] <meffie> ok, thanks
[16:15:15] <wiesand> Let's briefly discuss the time slot
[16:15:32] <meffie> ok
[16:15:49] <wiesand> we're back on "winter time" here, so today's meeting was an hour earlier for me
[16:16:14] <wiesand> I think you'll be back on "winter time" next week?
[16:16:21] <meffie> correct
[16:17:15] <wiesand> So shall we move the meeting to keep the usual time slot (in local time) for US participants?
[16:18:05] <wiesand> (shift it back 1h in UTC)?
[16:18:33] <kaduk@jabber.openafs.org/barnowl> I'm not awake enough to do timezone math, but I think that sounds like
the least-disruptive option
[16:18:54] <kaduk@jabber.openafs.org/barnowl> (and thank you for taking the meeting at a different time this week; I
had forgotten that we were in the DST skew window)
[16:19:20] <meffie> yes, thank you.
[16:19:49] <wiesand> If so, we should announce it. It's a pity Yadavendra hasn't participated for a couple of meetings, but we shouldn't make it veen harder for him - India is wise enough to forego the DST nonsense altogether…
[16:21:42] <wiesand> I think I'll contact him by PM, asking about our plan to keep the meeting at the same local time for US folks.
[16:22:12] <meffie> thank you
[16:22:40] <wiesand> So unless you hear from me before, see you same (US local) time next week.
[16:23:06] <kaduk@jabber.openafs.org/barnowl> Okay.  Thanks!
[16:23:41] <meffie> ok, thanks!
[16:23:45] <wiesand> Thanks a lot everybody! (And in particular to Mike for his work on the messy 1.6.x branch!)
[16:23:59] <meffie> my pleasure
[16:25:04] <meffie> have a good weekend
[16:25:09] meffie leaves the room
[16:25:31] wiesand leaves the room
[16:25:58] <kaduk@jabber.openafs.org/barnowl> You too!
[21:20:34] mbarbosa leaves the room