- Wednesday, February 17, 2016

release-team@conference.openafs.org

Wednesday, February 17, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[14:02:35] meffie joins the room
[14:25:37] mvita joins the room
[14:59:50] <mvita> good morning!
[14:59:50] shadow@gmail.com/barnowlABEE2063 leaves the room
[14:59:50] shadow@gmail.com/barnowlABEE2063 leaves the room
[14:59:50] shadow@gmail.com/barnowlABEE2063 leaves the room
[15:00:20] <meffie> hi
[15:00:27] <mvita> howdy mike
[15:02:30] <mvita> hello Jeffrey, jhutz, kaduk - I hope you'll be able to participate today
[15:03:28] <mvita> first, 1.6.x
[15:04:06] <mvita> I was thinking about looking for important master commits that should be cherry-picked to 1.6.x
[15:04:40] <mvita> but then I looked in gerrit and we already have a number of things under review for 1.6.x
[15:04:50] <meffie> good.
[15:05:05] <mvita> so we should probably focus on getting those reviewed
[15:05:20] <mvita> and start identifying candidates for 1.6.17
[15:06:05] <mvita> since Linux 4.4 is still unsettled, it doesn't make sense to hold for a .1 release for Linux 4.4 until we actually have it in a working state
[15:07:03] <mvita> I pulled down hot threads because it seemed applicable to a ticket I'm working on
[15:07:20] <mvita> and could potentially help others as well
[15:07:48] <mvita> do we want to do any additional testing or benchmarking for that one?
[15:08:16] <Jeffrey Altman> morning.
[15:08:16] <mvita> (12190)
[15:08:25] <mvita> morning Jeffrey
[15:08:34] <mvita> tx for joining
[15:08:57] <mvita> (btw Stephan is still out)
[15:09:00] <Jeffrey Altman> the hot threads change behavior is platform specific and very sensitive to the rx lock contention behavior.
[15:10:42] <mvita> can you give details on any particular platforms?
[15:10:43] <Jeffrey Altman> The rule about stable branches is that they are not supposed to used to pull arbitrary changes.  They are supposed to be low churn bug fix only to avoid introducing instability
[15:10:55] <kadukoafs@gmail.com/barnowl2F6B45A5> Sorry I'm late.
[15:11:23] <meffie> greetings
[15:11:51] <Jeffrey Altman> master has a lot of changes that alter the lock contention hot spots.  as a result disabling hot threads makes sense there.   1.6 does not have any of the changes that alter the lock contention hot spots.
[15:12:47] <mvita> so you would prefer to hold this for 1.8 instead
[15:14:54] <kadukoafs@gmail.com/barnowl2F6B45A5> It seems more natural for 1.8, yes.
[15:15:09] <Jeffrey Altman> yes. wearing a release manager hat you should be extremely skeptical of anyone that suggests "lets just do this little innocuous change to rx on a stable branch".
[15:15:36] <mvita> okay, fair enough
[15:15:38] <Jeffrey Altman> pretty much, if you touch rx you will break it
[15:17:00] <mvita> well.
[15:19:01] <Jeffrey Altman> I know you think I'm exaggerating but there is 25 years of rx breakage to prove my case.
[15:20:19] <meffie> heh. yes, i agree with ben and jeffrey, it would be prudent to wait until 1.8.
[15:20:20] <mvita> I've seen it.  Doesn't mean it can never be attempted.
[15:20:20] <Jeffrey Altman> including much breakage that I introduced and had to undo
[15:20:31] <Jeffrey Altman> not on a stable branch
[15:20:47] <meffie> for this 12190, that is.
[15:21:28] <mvita> I come from closed source commercial mainframe software development and certainly have caution and conservativism baked into my dna
[15:23:19] <mvita> okay.
[15:23:30] <mvita> moving on to 1.6.x linux 4.4
[15:23:49] <mvita> what do we need to move forward there?
[15:26:40] <Jeffrey Altman> in the context of release-team?  has anyone submitted a proposed fix?
[15:27:06] <mvita> I guess I'm trying to identify who might be willing and able to do that
[15:27:13] <kadukoafs@gmail.com/barnowl2F6B45A5> I haven't seen anything submitted.
"Someone needs to do the research to understand the ERESTART failure
modes and submit a patch."
[15:27:15] <mvita> so we can avoid duplicate effort
[15:29:41] <mvita> ben, can you think of anyone who would be qualified to do that, so we could ask them?
[15:30:42] <mvita> I know marc's unavailable
[15:30:51] <mvita> deason is also probably unavailable
[15:30:53] <kadukoafs@gmail.com/barnowl2F6B45A5> Maybe Anders.
[15:31:06] <mvita> don't know him...
[15:32:51] <kadukoafs@gmail.com/barnowl2F6B45A5> But in some sense I would be happier if a scary email was sent to
-users that prompted someone who would actually be affected to take an
interest and book up on what is needed.  I don't think relying on the
"old guard" is sustainable.
(Of course, there is no guarantee that such a hypothetical scary email
would actually have the desired effect.  We still don't have a windows
builder, for example.)
[15:33:43] <meffie> maybe start with -devel ?
[15:33:53] <mvita> yeah.
[15:34:31] <mvita> are there any sympathetic VFS folk on the Linux kernel side?
[15:34:32] <kadukoafs@gmail.com/barnowl2F6B45A5> sure
[15:36:11] <mvita> okay.  I can send an email to -devel that asks for someone to research and/or fix the issue
[15:36:37] <kadukoafs@gmail.com/barnowl2F6B45A5> I don't even know who the VFS folks are on the Linux side :-/
[15:37:08] <mvita> it's important to maintain current platform support in the stable branch
[15:37:11] <meffie> following linux dev is a full time job.
[15:37:29] <mvita> I can ask deason if he knows anyone as well
[15:37:56] <Jeffrey Altman> From the Linux vfs perspective if the code is not in-tree then it is not their responsibility.   This is why AuriStor, Inc. builds and tests the nightly Linux trees from Linus, significant vfs devs and from red hat.  As necessary we respond to the submitter of a change that breaks our code within 48 hours in the hope of getting a change implemented.
[15:37:56] <meffie> next topic?
[15:38:34] <Jeffrey Altman> The most recent change was in the networking stack that badly broke rx.
[15:38:40] <meffie> ouch
[15:39:21] <Jeffrey Altman> We discovered it, submitted a fix to the dev that broke it, and a revised change went upstream before 4.4 was released.
[15:40:22] <kadukoafs@gmail.com/barnowl2F6B45A5> That is much appreciated.
[15:41:13] <mvita> 1.6.x os x packaging and binaries - nothing new to report, upstreaming work is in progress with one of our engineers
[15:41:19] <Jeffrey Altman> The ERESTART behavior change is not a bug.  In fact, one can argue that the change fixes a bug in the vfs which is why the change went upstream and is being backported to earlier kernels.
[15:42:45] <mvita> 1.8.x anything you need Ben or would like to discuss?
[15:43:49] <kadukoafs@gmail.com/barnowl2F6B45A5> I have basically no changes since last week -- I drove up to visit my
parents this weekend, so there was not much extra time.
[15:44:09] <mvita> okay.  that's all I had on the agenda.
[15:44:23] <meffie> ben, are there doc changes i can do for the "death to -noauth"?
[15:44:38] <meffie> and the recent set of new g.c.o. tickets?
[15:45:43] <kadukoafs@gmail.com/barnowl2F6B45A5> It's probably worth grepping through QuickStartUnix for -noauth.
I didn't even try to touch the AdminGuide; that's pretty large.
[15:46:17] <meffie> i'll do that.
[15:46:31] <kadukoafs@gmail.com/barnowl2F6B45A5> I didn't look at the new RT tickets closely enough to have specific
guidance on what to do with them, but taking a closer look is probably
worthwhile.
[15:46:54] <kadukoafs@gmail.com/barnowl2F6B45A5> Thanks
[15:48:04] <mvita> speaking of tickets - I see rt.central.org has got some spam - cleaning it out now
[15:48:47] <kadukoafs@gmail.com/barnowl2F6B45A5> There's always spam.  A few of us go through and clear it out from
time to time.
[15:49:01] <mvita> yeah, me too.  anything else before we adjourn?
[15:49:14] <meffie> already got it mvita.
[15:49:24] <mvita> okay, tx mike
[15:49:34] <kadukoafs@gmail.com/barnowl2F6B45A5> Just that Chas -1'd your 11934 ;)
[15:49:48] <mvita> yup, I saw it and will fix it
[15:49:55] <kadukoafs@gmail.com/barnowl2F6B45A5> Thanks.
[15:50:04] <mvita> it won't take mumble weeks this time
[15:50:23] <jhutz@jis.mit.edu/owl> > I don't even know who the VFS folks are on the Linux side
Ted might
[15:50:42] <meffie> hey jhutz
[15:50:47] <mvita> Ted ....
[15:51:40] <jhutz@jis.mit.edu/owl> Note that if you're cleaning out spam, you should actually delete the
affected tickets.  That's about the only time you should delete a ticket.
[15:51:59] <jhutz@jis.mit.edu/owl> tytso
[15:52:20] <jhutz@jis.mit.edu/owl> Anyway, can't stay.
[15:52:32] <mvita> tx jhutz
[15:53:34] <mvita> okay, thank you everyone - I'll post notes to the list in a day or two
[15:53:40] <meffie> have a good day. i'm going outside to build a snow fort.
[15:53:57] <kadukoafs@gmail.com/barnowl2F6B45A5> Have fun
[15:54:22] <Jeffrey Altman> enjoy the snow
[16:27:07] meffie leaves the room
[17:13:01] meffie joins the room
[17:13:58] meffie leaves the room