[04:28:04] --- shadow@gmail.com/owl712C143C has become available
[04:36:27] --- pod has become available
[05:56:03] --- reuteras has left
[06:57:33] --- Simon Wilkinson has left
[07:04:25] --- deason has become available
[07:30:36] --- haba has become available
[08:33:43] --- sxw has become available
[08:34:23] <sxw> Is it worth me putting together a 1.4.12.2 branch?
[08:35:55] <deason> are we going to include something about 127554?
[08:35:57] --- ktdreyer has left
[08:36:00] <shadow@gmail.com/owl712C143C> well, i'd do it if the people who say what exists now doesn't work
would confirm that what was suggested does work
[08:36:12] --- sxw has left
[08:36:25] --- sxw has become available
[08:36:57] <sxw> Does anything exist now?
[08:37:09] <shadow@gmail.com/owl712C143C> i assume so. basically, a whole slew of releases are "due". my goal is
to put everything together at ~the same time so binary builders can be
nagged once
[08:37:26] <shadow@gmail.com/owl712C143C> > Does anything exist now?

er, for 1.4.12.2? or for 127554? or?
[08:37:35] <sxw> Speaking as a binary builder, that's a bad idea.
[08:37:47] <sxw> For 1.4.12.2
[08:37:58] <shadow@gmail.com/owl712C143C> for 1.4.12.2, no. 
[08:38:12] <shadow@gmail.com/owl712C143C> not beyond 1.4.12.1. and why do you not want a lump?
[08:38:52] --- ktdreyer has become available
[08:38:53] <sxw> Because builds take a long time, and while they're happening kernel updates can't get built,
[08:39:37] <sxw> I'd much rather have a month with one release a week, than deal with a day where there are 4 new products needing built and tested.
[08:39:38] <shadow@gmail.com/owl712C143C> well, 127554's resolution needs your feedback. i have a plan lacking
any feedback, but.
[08:40:07] <sxw> 127554 is give up all callbacks?
[08:40:20] <shadow@gmail.com/owl712C143C> nil. it's in rt and you should look at it.
[08:40:32] <deason> 127554 is something I don't want to mention what it is here
[08:40:34] <sxw> (rt isn't talking to me at present)
[08:40:41] <sxw> Okay.
[08:41:08] <sxw> Ah. That.
[08:41:14] <shadow@gmail.com/owl712C143C> yes.
[08:41:27] <sxw> Doesn't belong in 1.4.12.2
[08:41:27] <shadow@gmail.com/owl712C143C> like, your bailiwick.
[08:41:44] <sxw> Might be a reason to do 1.4.13
[08:42:00] <deason> if you release a platform thing for 1.4.12.2, and soon after do something for 127554, I would quesetion why anyone would want to run 1.4.12.2
[08:42:12] <shadow@gmail.com/owl712C143C> well, no. the ? is 1.4.13? and if 1.4.13, do we skip 1.4.12.2 and do
1.4.13.1 with 1.4.13 being 1.4.12 plus 127554, and 1.4.13.1 being
1.4.13 plus the patches for new kernels?
[08:42:37] <sxw> That depends on how we evaluate the various risks.
[08:42:56] <shadow@gmail.com/owl712C143C> which other risks?
[08:43:40] <sxw> 1.4.12.2 is easy because it's confined to Linux and the new code is, iirc, limited to kernels we don't currently work on.
[08:44:15] <shadow@gmail.com/owl712C143C> sure. but if we do that, we could then do 1.4.12.2, 1.4.13 and
1.4.13.1, (or 1.4.14) which seems.... confusing
[08:44:28] <sxw> It does.
[08:44:51] <sxw> I don't think we do 1.4.13.1
[08:44:54] <shadow@gmail.com/owl712C143C> i'd pose we need one release, 1.4.13, for 127554 regardless. the
question is what else.
[08:45:14] <shadow@gmail.com/owl712C143C> and 1.4.13 would contain exactly that
[08:45:27] --- haba has left
[08:45:58] <sxw> I think 1.4.13 could be that, plus kernel fixes
[08:46:14] --- haba has become available
[08:46:28] <shadow@gmail.com/owl712C143C> it could be. we've tried to avoid that before
[08:46:53] <sxw> We'd need to review the impact of the kernel fixes.
[08:47:22] <sxw> If they only change things where we didn't previously work, I'd be happy with that
[08:48:59] <sxw> We're also overdue a release from the tip of the 1.4 branch. But I'm not convinced we have the effort to make that happen.
[08:49:24] <sxw> And, IMHO, 1.6 is more important at this point.
[08:49:49] <shadow@gmail.com/owl712C143C> well, danger #1: DEFINE_MUTEX(afs_linux_alloc_sem);
happens past 2.6.16, where DECLARE_MUTEX worked before
[08:50:40] <asedeno> Oh hi.
[08:50:49] <sxw> Got a sha1?
[08:52:07] <shadow@gmail.com/owl712C143C> for?
[08:52:08] <sxw> My iToy needs a git browser.
[08:52:30] <shadow@gmail.com/owl712C143C> the DECLARE/DEFINE thing?
[08:52:33] <asedeno> ce71b095240fb2b07175cee47f6cc7b3ef438a30
[08:52:48] <sxw> The code you're talking about - I assume that's from a patch proposed for 1.4.12.2
[08:53:11] <sxw> Ta. Just need to break out a real computer.
[08:53:11] <asedeno> That's from openafs-stable-1_4_x
[08:53:47] <shadow@gmail.com/owl712C143C> we could rescope it to apply only above 2.6.36 for 1.4.13
[08:54:20] <asedeno> Why? afs_global_lock switched at 2.6.16.
[08:54:48] <sxw> Yuck. I wish that I'd read that patch at the time.
[08:54:49] <shadow@gmail.com/owl712C143C> if the goal is to change nothing but only work where we did not
previously, ...
[08:55:58] <asedeno> Actually, no, that makes a bigger mess.
[08:56:03] <sxw> It really should be using feature tests rather than kernel version numbers.
[08:57:08] <asedeno> mutex_lock and mutex_unlock are defined around the same tests.
[08:58:43] <sxw> Yeah. Still not ideal, though.
[08:58:54] <sxw> Anyhow, that's beside the point now.
[09:00:23] --- jaltman/FrogsLeap has become available
[09:02:03] <sxw> I'm inclined not to spend too much time making changes to existing 1.4 patches to reduce their risk.
[09:02:47] <shadow@gmail.com/owl712C143C> well, we could do a 1.4.13 off the 1.4.12.1 branch, with just the
needed further kernel patches and the 554 fix
[09:03:35] <sxw> My feeling is that we should do a 1.4.13 which includes kernel updates plus 127554, and provide 127554 on it's own for the risk adverse.
[09:03:54] <shadow@gmail.com/owl712C143C> well, we always provide such in an announcement
[09:03:56] <deason> which would be... a 1.4.12.2 ?
[09:04:29] <sxw> People will scream. But people will scream whatever we do, and I don't fancy doing n^2 releases to keep everyone happy.
[09:04:29] <sxw> Thoughts?
[09:04:36] <shadow@gmail.com/owl712C143C> we could do it that way. i'm not sure it's worth bothering with a
tarball but it's easy enough to make one
[09:05:05] <shadow@gmail.com/owl712C143C> if people want to scream, we should add in GiveUpAllCallBacks :)
[09:06:44] <sxw> I think it's 1.4.13, because it's a change across all platforms,
[09:06:44] <sxw> And I'm not going to rise to shadow's bait...
[09:07:07] <shadow@gmail.com/owl712C143C> well, i think he means issue just 554 as 1.4.12.2
[09:07:48] <sxw> Ah. That doesn't work within our current numbering scheme.
[09:08:17] <deason> hm? why not?
[09:08:22] <shadow@gmail.com/owl712C143C> well, ignoring that... if it's just 1.4.12.1 plus a patch, i'd be happy
to say "here's the patch. go nuts"
[09:09:06] <sxw> Because 4th digit releases are purely platform compatibility releases.
[09:10:18] <sxw> If you're running 1.4.12, there's nothing in 1.4.12.1 that interests you, unless 1.4.12's client doesn't build.
[09:10:21] <shadow@gmail.com/owl712C143C> it has worked out that way, yes
[09:10:28] <jaltman/FrogsLeap> based on our past practice we should 1.4.13 for 127554 and then 1.4.14 for anything else that needs to be taken care of at the moment. 
[09:10:42] <sxw> Nope.
[09:11:01] <deason> hmm, and why did we way "no" to 1.4.13 554 and 1.4.13.1 for 554+kernel stuff? too confusing?
[09:11:11] <shadow@gmail.com/owl712C143C> only if "other things" are global. otherwise, 1.4.13.1 (linux only)
[09:11:39] <sxw> Too confusing, I think. But I guess we could if we have to.
[09:11:43] <deason> (that is, assuming we said "no" to that; I think we did, but I was on a call for most of the previous conversation)
[09:11:55] <jaltman/FrogsLeap> there is already a new CellServDB and I'm sure there are other fixes that need to be pushed from rx
[09:12:19] <jaltman/FrogsLeap> in particular, Andrew's timeout patch
[09:12:22] <sxw> Both of those are irrelevant for this discussion
[09:12:40] <deason> well, they're relevant in that they are reasons we want a 1.4.14
[09:13:03] <sxw> Yes. But we're not going to manage to deliver that before Feb.
[09:14:00] <jaltman/FrogsLeap> that doesn't change the order.  1.4.13 for 127554 and 1.4.13.1 for any platform specific change that can't wait until 1.4.14 and then you issue a 1.4.14-pre1 immediately with the other changes
[09:14:55] <sxw> I don't think we want a pre-release cycle for 1.4 running at the same time as 1.6
[09:15:22] <sxw> I also think all of this will just confuse everyone.
[09:15:40] <jaltman/FrogsLeap> its not like every other open source project doesn't do it
[09:15:46] <deason> I dunno, I think most people will just go for the highest number
[09:15:52] <deason> the risk-averse will try to pay more attention
[09:16:49] <deason> I mean, the main difference is just three new 1.4 versions as opposed to two new 1.4 versions, right? I'm not sure how much difference it'll make; both will be confusing to some degree
[09:17:44] <deason> the 1.4.9/1.4.10 thing wasn't too bad, was it?
[09:17:58] --- sxw has left
[09:23:35] <jhutz@jis.mit.edu/owl> Wait, how do these meet the criteria that the only differences in a
fourth-level release (in this case, 1.4.12.1) are those needed for
portability to a new platform/kernel/etc ?

495fda4... fix other oldtvix typo
5960468... Initialize oldvtix
d4e724e... Recover from afs_GetVolSlot errors
[09:24:21] <jaltman/FrogsLeap> they wouldn't be.   a fork would be made from the last tag
[09:25:57] <jhutz@jis.mit.edu/owl> Jeff, was that intended as an answer to me?  Because it doesn't make
sense as one.  Those are commits that are in
openafs-stable-1_4_12..openafs-stable-1_4_12_1

That is, they first appeared in 1.4.12.1
[09:26:55] <deason> I'm not sure, but the justification there _might_ have been that those were to fix a platform-specific issue
[09:27:53] --- sxw has become available
[09:27:54] <shadow@gmail.com/owl712C143C> that was an issue seen only on (s390x?) linux, iirc?
[09:28:13] <deason> no, sles 10.mumble SP mumble, or something along those lines
[09:28:49] <shadow@gmail.com/owl712C143C> ok. well, it was something linux with an "s"
[09:29:18] <sxw> Sorry, OneTeam hung on me...
[09:29:44] <sxw> There was a lot of head scratching about 1.4.9, 1.4.10
[09:29:55] <shadow@gmail.com/owl712C143C> yup. i remember that
[09:29:58] <deason> do you have scrollback? or do you need a summary on what was said?
[09:30:15] <shadow@gmail.com/owl712C143C> oneteam does scrollback, the ? is whether he got it all. sometimes the
conference server is weird
[09:30:21] <sxw> I have scroll back. Just lost what I'd been typing.
[09:30:39] <shadow@gmail.com/owl712C143C> (oneteam is the only iOS app i've found that does conferences)
[09:31:41] <sxw> My feeling is that releases take time. Time is something we're very short on, so we should do as few releases as we can get away with.
[09:32:12] <shadow@gmail.com/owl712C143C> releases which don't include builds are not that hard.
[09:32:29] <sxw> Yeah, they're just confusing.
[09:32:35] <shadow@gmail.com/owl712C143C> this is not to say i want to do as many as possible. yeah, that too
[09:33:29] <sxw> I think we should put together a candidate for a single 1.4.13 release, and have a look at how invasive it is.
[09:33:56] <shadow@gmail.com/owl712C143C> you mean just the cherry-picks and the 554 fix?
[09:34:20] <sxw> Yup.
[09:34:46] --- haba has left
[09:35:15] <sxw> I'm happy to put a branch together.
[09:35:32] <shadow@gmail.com/owl712C143C> i'll push the one i have in a moment
[09:35:42] <sxw> Ah. Cool.
[09:36:13] <deason> non-554 changes are just affecting linux kernel stuff, right?
[09:36:29] <sxw> Yes.
[09:37:00] <deason> I don't see additional risk then; the 554 fix doesn't affect clients, so if you're upgrading just for the 554 fix, you don't need to even build the client
[09:37:09] <deason> so, +1
[09:37:37] <sxw> Anyone got a RHEL6 box they could test on?
[09:38:11] --- haba has become available
[09:38:50] <deason> I can offer you rhel6 beta; but I've been waiting on someone for a real rhel6 for other reasons... might have one soon
[09:39:34] <sxw>  They changed the kernel between beta and GA, sadly.
[09:39:35] <shadow@gmail.com/owl712C143C> (redacted) may be buying openafs a rhel6 license
[09:39:46] <shadow@gmail.com/owl712C143C> but their wheels turn slowly
[09:40:01] <shadow@gmail.com/owl712C143C> 3514-3521
[09:40:08] <sxw> Is this the same (redacted) as offered one when RHEL5 came out?
[09:40:23] <deason> between which one? the kernel changed between betas; the newest one fixes the ima thing
[09:40:24] <shadow@gmail.com/owl712C143C> that offer was never tendered, they explored it. yes
[09:41:24] <sxw> You know that if you push to refs/for/master/topic you can flag all of your commits as belonging to the same patch series?
[09:44:04] <shadow@gmail.com/owl712C143C> refs/for/master would be bad. 
[09:44:08] <shadow@gmail.com/owl712C143C> but, point taken
[09:44:35] <sxw> Master is a lot easier to type on this keyboard
[09:44:51] <shadow@gmail.com/owl712C143C> understood
[09:45:09] <shadow@gmail.com/owl712C143C> oh, and 3522
[09:46:24] <deason> okay, so we do want to update the whole thing? there's a fix for the specific issue in 554
[09:47:03] <shadow@gmail.com/owl712C143C> what is there is testable. we can choose to not release it as-is, but
for now i am comfortable with that being in gerrit
[09:48:03] <shadow@gmail.com/owl712C143C> i apologize if i seem like i am being circumspect.
[09:49:46] <deason> not sure if I'm being clear; I mean, if we have the goal to change as little as possible while fixing the issue, there's a targeted patch
[09:50:05] <shadow@gmail.com/owl712C143C> yes. and i don't want to put that in gerrit right now.
[09:50:09] <deason> but if 'upgrading' the whole ticket5 thing is a good idea, we can do that
[09:50:14] <deason> oh okay, yes
[09:59:31] --- mdionne has become available
[10:02:47] <mdionne> Any reason not to include the llseek fix for 2.6.37?  Need something more targeted? 
[10:05:11] <shadow@gmail.com/owl712C143C> did i not pull it in? hm
[10:05:50] <shadow@gmail.com/owl712C143C> done
[10:07:16] --- sxw has left
[10:07:37] --- sxw has become available
[10:13:49] <sxw> All of those look good, bar one change which has unmatched locking of the BKL
[10:14:49] <shadow@gmail.com/owl712C143C> 3527?
[10:16:34] --- haba has left
[10:17:19] <sxw> 3526 shouldn't be in this patch series
[10:17:36] <shadow@gmail.com/owl712C143C> we shouldn't do a new release with old CellServDBs imo
[10:19:35] <sxw> It's tricky. The new CellServDB is neither a security fix, nor a platform compatibility change.
[10:20:23] <shadow@gmail.com/owl712C143C> it's also not forced down your throat, just incidental to being in the
source tarball
[10:20:30] <sxw> Anyone know when llseek appeared in struct file_operations?
[10:21:26] <sxw> The way we build Linux packages means that we'll pick up the new one there. But that's because the tar ball isn't the source.
[10:21:45] <shadow@gmail.com/owl712C143C> sure.
[10:22:57] <jhutz@jis.mit.edu/owl> Don't ship CellServDB in the source tarball, and you won't have this
problem.  In the meantime, please don't do a release with a stale one.
[10:23:20] <jhutz@jis.mit.edu/owl> At least, not a stale one that's actually used anywhere.
[10:23:53] <mdionne> I think llseek is fairly old.  We could do a safer version for older kernels.  Just define it when we have to 
[10:25:17] <sxw> As written, that patch seems to need llseek on every kernel we still support. I think 1.4 still builds on 2.2.mumble, so we need to know that it is safe there.
[10:28:49] <mdionne> Yeah at least an ifdef for 26.  I forget we don't have 2.6 split off in 1.4
[10:29:00] --- mdionne has left
[10:29:00] --- mdionne has become available
[10:29:03] --- mdionne has left
[10:43:48] <andersk> llseek has been around since at least v2.4.0.
[10:44:20] <sxw> Cool. I wonder if we care about kernels older than that in 1.4
[10:45:52] <andersk> In fact, it’s in v2.2.0, even.
http://git.kernel.org/?p=linux/kernel/git/davej/history.git;a=blob;f=include/linux/fs.h;hb=refs/tags/2.2.0
[10:49:13] <sxw> No default_llseek in that header, though.
[10:49:13] <sxw> Must clone that tree when I'm on better network.
[10:58:44] --- sxw has left
[11:04:53] --- sxw has become available
[11:08:28] --- sxw has left
[11:12:10] <andersk> Yeah, default_llseek comes from 2.3.99pre6.
[11:20:37] --- sxw has become available
[11:25:33] --- sxw has left
[11:41:29] --- sxw has become available
[11:53:02] --- sxw has left
[12:51:55] --- ktdreyer has left
[13:17:26] --- jaltman/FrogsLeap has left: Replaced by new connection
[13:17:27] --- jaltman/FrogsLeap has become available
[13:17:28] --- Russ has become available
[13:51:58] --- meffie has left
[13:52:20] --- meffie has become available
[14:31:32] --- jaltman/FrogsLeap has left: Disconnected
[14:31:41] --- jaltman/FrogsLeap has become available
[14:34:17] --- jaltman/FrogsLeap has left: Disconnected
[15:00:48] --- jaltman/FrogsLeap has become available
[15:35:03] --- deason has left
[17:15:42] --- deason has become available
[20:50:29] --- Russ has left: Disconnected
[21:01:22] --- jaltman/FrogsLeap has left: Disconnected
[21:25:01] --- deason has left
[21:43:08] --- Russ has become available
[22:17:36] --- jaltman/FrogsLeap has become available
[00:00:19] --- reuteras has become available