- Wednesday, May 7, 2014

openafs@conference.openafs.org

Wednesday, May 7, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[00:05:36] stephan.wiesand joins the room
[00:18:23] stephan.wiesand leaves the room
[00:20:14] mvita leaves the room
[00:21:24] mvita joins the room
[00:24:16] mvita leaves the room
[00:24:17] mvita joins the room
[00:29:12] Simon Wilkinson joins the room
[00:29:13] Simon Wilkinson leaves the room
[04:01:20] Marc Dionne leaves the room
[04:01:20] Marc Dionne joins the room
[04:01:20] Marc Dionne leaves the room
[05:10:45] Simon Wilkinson joins the room
[06:47:22] ktdreyer joins the room
[09:44:12] Simon Wilkinson leaves the room
[10:15:27] mvita leaves the room
[10:35:51] wiesand joins the room
[11:12:35] Marc Dionne joins the room
[12:32:46] meffie joins the room
[13:09:11] mvita joins the room
[13:26:31] Simon Wilkinson joins the room
[13:59:15] kaduk joins the room
[15:13:32] deason joins the room
[15:14:16] <wiesand> Jeffrey, would you like to "chair"?
[15:14:51] <Jeffrey Altman> I'm not sure we need a "chair".
[15:15:24] <Jeffrey Altman> I've posted the existence of the discussion in the IRC channel in case others that wish to participate are around.
[15:15:48] <Jeffrey Altman> Andrew posted a nice summary of the possible options.
[15:16:52] <wiesand> https://lists.openafs.org/pipermail/openafs-info/2014-May/040674.html
[15:17:22] <kaduk> Under the "different release names" schemes, would we want to change just one of windows/unix, or both of them?
[15:17:36] <Jeffrey Altman> I have not had time to respond to his posting so I would like to clarify the Windows numbering issues.
[15:20:08] <Jeffrey Altman> Windows releases are usually issued on a one to two month cycle.   The primary reason for the frequency of the releases fall into three categories.  (1) addition of new functionality to better integrate the client; (2) bug fixes or interop workarounds for third party drivers (anti-virus is the typical category); (3) new OS updates from Microsoft which are now shipping as slipstream updates on a six month cycle.
[15:22:24] <Jeffrey Altman> In addition, the afs redirector is relatively young and architectural design issues internal to the redirector and userland service boundaries are not always optimal.  Changing core functionality often requires a major rewrite and I'm not comfortable just slipping such changes into a release series even if there is no impact on non-Windows modules.
[15:22:27] <wiesand> There's no way we could keep up with that pace for the Unix/Linux releases.
[15:22:58] <Jeffrey Altman> For Windows, I would rather have issued the redirector as 2.0 and the new rewrite as 3.0.
[15:24:39] <wiesand> Keeping Windows separate would make you completely free to do such things.
[15:24:54] <Jeffrey Altman> Windows version numbers are issued as 1.7.XXYY (Major, Minor, PatchLevel) and we are really abusing the PatchLevel field which makes installation more difficult.  Switching to a Major, Minor releasing numbering would make things much easier
[15:25:30] <wiesand> I like the "OpenAFS for Windows 14.06" idea.
[15:25:43] <Jeffrey Altman> That being said if we were to change the Windows numbering away from the Unix numbering I would probably start at 2.0 for the new branch
[15:26:14] <Jeffrey Altman> or I could start at 8.x and 9.x if that would be less confusing.  Just drop the 1.
[15:26:19] <kaduk> 2.0 for the new unix branch?
[15:26:25] <deason> I thought 2 might be confusing if openafs 2 (rxgk) is released in a somewhat reasonable time frame
[15:26:34] <Jeffrey Altman> For UNIX 2.x is reserved for rxgk
[15:26:56] <deason> yeah, which is why I probably wouldn't start 'openafs for windows' at 2
[15:27:20] <Jeffrey Altman> The next release which is 1.7.3100 could be released as 7.31.00
[15:27:40] <deason> in the example I picked 5 which was pretty arbitrary, but I did deliberately skip 2 (rxgk), 3 ('afs 3.6'), 4 ('krb4'), 7 and 8 ('windows 7' and 'windows 8')
[15:27:46] <Jeffrey Altman> and then the redirector rewrite would be 8.0
[15:27:55] dwbotsch joins the room
[15:28:13] <Jeffrey Altman> or switch to 17.31.00
[15:28:14] <deason> but I'm not trying to dictate the number; just mentioning possible confusions
[15:28:19] <deason> we can't really avoid them all
[15:28:27] <Simon Wilkinson> Something that maintains a link with the "older" numbers might be nice - so going from 1.7.x to 7.x
[15:28:44] <deason> like sunos -> solaris; it would feel familiar
[15:28:48] <Jeffrey Altman> From an internal Windows perspective, there is no 7 or 8 or 9.   All Windows releases are 6
[15:29:13] <deason> I meant more like, someone googling "windows 7" also finds "openafs for windows 7" because the phrase is there
[15:29:35] <deason> but it's just a minor thing
[15:29:56] <deason> or "openafs for windows 7" looks like "openafs" "for windows 7"; that kind of thing
[15:30:21] <Jeffrey Altman> I'm not in favor of the "OpenAFS for Windows" or "Kerberos for Windows" (for that matter) branding
[15:30:40] <deason> okay, yeah, I was going to suggest maybe something more distinctive if we go that route
[15:30:47] <mvita> whatever scheme we eventually choose, it should be explained in a "secret decoder ring" page linked from the downloads page(s), so people new to AFS know how to select what to download.
[15:30:48] <Jeffrey Altman> The installers for Windows can't install anywhere else
[15:31:30] <kaduk> "WinAFS: powered by OpenAFS" is probably not any better than "OpenAFS for Windows"
[15:31:36] <deason> but are you just suggesting "openafs 5.1", which is windows-only?
[15:31:37] <ballbery> WinOpenAFS? I'm a bit dubious about "OpenAFS for Windows" as well
[15:31:45] <deason> or just another name?
[15:31:57] <Jeffrey Altman> I often use WinAFS as an abbreviation but all trademarks including "AFS" require approval from IBM.
[15:32:27] <dwbotsch> personally, I like WinAFS better than OpenAFS for Windows... to me, it definitely implies the windows client is a different product
[15:33:21] <deason> you could just have a phrase with openafs in the middle somewhere and 'brand' it as the resulting acronym/initialism
[15:33:56] <deason> the windows openafs redirector -> brand as WAR everywhere
[15:34:04] <deason> or whatever; that's just a throwaway example
[15:34:13] ktdreyer leaves the room
[15:34:40] <deason> having 'openafs' in the name makes it more clear that it's still from the same codebase as openafs but it's kinda-sorta a different thing
[15:34:40] ktdreyer leaves the room
[15:34:40] ktdreyer leaves the room
[15:35:07] <Jeffrey Altman> I think there is consensus that Windows is going it own way on version numbers.
[15:35:24] <wiesand> That's my impression.
[15:36:02] <Jeffrey Altman> The next question is:   Is there any benefit to us developers to separate the client and server releases on the other platforms?
[15:36:28] <wiesand> I don't think so.
[15:36:28] <dwbotsch> separate how?
[15:36:35] <ballbery> what comes immediately to mind for me is linux kernel changes
[15:36:44] <wiesand> And on some platforms they aren't independent.
[15:36:55] <wiesand> Didn't Solaris servers need the kernel module?
[15:37:03] <deason> just for inode; it's not common anymore
[15:37:05] <ballbery> back when they used inode
[15:37:20] <ballbery> last I heard the inode server was broken anyway?
[15:37:21] <kaduk> And the NFS translator needs a kernel module, too (also not common anymore?)
[15:37:38] <Simon Wilkinson> The NFS translator is dead and buried
[15:37:40] <deason> nfs xlator would be part of the 'client'
[15:37:47] <deason> and no, that's not true, it is still used
[15:37:53] <Simon Wilkinson> On Linux?
[15:37:57] <deason> not linux
[15:38:09] <deason> well, it may be used somewhere on linux, but obviously not on newer kernels
[15:38:32] <deason> the 'inode' server is also not broken (as far as I know), but we/someone thought it was at some point on newer solaris
[15:38:44] <Simon Wilkinson> I can't see any benefit to having separate client/server versions
[15:38:55] <deason> that turned out not to be true (there was a bug due to the change to x86, but it was fixed), but I think that idea helped kill it off
[15:39:10] <Simon Wilkinson> It's just even more releases to make.
[15:39:31] <deason> separate client/server packages would let things like kernel updates for linux proceed separately, or other stuff that only impacts clients
[15:39:32] <Jeffrey Altman> what percentage of the changes in 1.6.8 and 1.6.6 were linux kernel only?
[15:39:44] <deason> I think chas's comment that there are different impacts for them makes sense, too
[15:40:24] <Simon Wilkinson> So sites can pick different upgrade cycles for their servers than for their clients. I don't think that's a good reason to double our release workload
[15:40:29] <deason> the split would also make it easier to include just the server parts in places like epel/fedora while not including the client; but that doesn't help the client
[15:40:31] <wiesand> Single digit figure I think.
[15:40:50] <deason> linux changes wasn't much recently; it looks like that is indeed slowing down so maybe isn't an issue these days
[15:41:20] <Jeffrey Altman> sounds like that idea is dead.
[15:41:32] <ballbery> yeh, it's not *that* common but I seem to recall some release for a linux kernel change getting held up somewhere in the 1.6 series because of something else
[15:41:38] <Simon Wilkinson> I don't think past performance is any indication of future results in that regard, sadly. I think there's just less churn in the VFS right now.
[15:41:51] <Marc Dionne> between 1.6.6 and current pre2, 3 of 87 changes were tagged "linux"
[15:41:52] <Jeffrey Altman> Next: do we want to maintain the odd vs even / development vs release numbering scheme?
[15:41:53] <Simon Wilkinson> We're now doing x.y.z.foo releases for things that are just Linux kernel only
[15:42:01] <deason> I think it would be a helpful goal; we do sometimes seem to push a release because of some client issue or some server issue, but we have to push a release for both at the same time because that's how we do things
[15:42:15] <deason> but "is it worth it" to split between client/server; I think we're not seeing the pain enough right now
[15:42:19] <wiesand> We had 1.6.5.1 and 1.6.5.2 for such client issues.
[15:43:16] <Simon Wilkinson> Personally, I don't think there's any value to the development branch. That's a hang over from CVS, when "master" was a dumping ground for anything anyone ever submitted, and wasn't even guaranteed to compile.
[15:44:04] <deason> the 'replacement' for devel releases could be trying to move to creating snapshot-based packages instead
[15:44:19] <deason> but work would have to be done for that to exist
[15:44:51] <deason> (that is, snapshots based on master)
[15:45:05] <Simon Wilkinson> We find it hard enough to get people to test pre's from the stable series that probably aren't going to ruin their cell.
[15:45:31] <Simon Wilkinson> I suspect that the number of people who would install snapshots from master is vanishingly small
[15:46:13] <wiesand> I'm with Simon here. No need for something like 1.9/1.10 with 1.9 being devel.
[15:46:34] <deason> I'm not saying we need to go do it now; just if people wanted 'devel' releases we would just make them from master snapshots
[15:46:38] <wiesand> And yes, getting testing for the prereleases is hard enough.
[15:46:51] <deason> so there's no reason for the separate devel releases and branch
[15:47:08] <Jeffrey Altman> Are we comfortable with an extended number of 1.8.0preXXX releases ?
[15:47:42] <wiesand> XX would hopefully suffice ;-)
[15:47:49] <kaduk> We might want to make a distinction between "alpha", "beta", and/or "pre".
[15:48:07] <deason> I would be fine with that, but I thought there may be some issues with some packaging being able to support it
[15:48:11] <deason> or maybe we don't care for pres
[15:48:32] <Jeffrey Altman> I think OSX has constraints
[15:49:22] <deason> yeah, but maybe it doesn't matter? if the packaging just says "1.8.0prewhatever" and doesn't specify which prerelease, we can get the actual version from rxdebug -version
[15:49:48] <deason> installing prereleases I'd assume was somewhat manual and requires someone to be paying attention anyway
[15:52:07] <wiesand> "Note that macos kext
    can be of form XXXX.YY[.ZZ[(d|a|b|fc)NNN]] where d dev, a alpha,
    b beta, f final candidate"
[15:52:13] <Jeffrey Altman> What I am hearing is that we want to propose to the list that the next UNIX release series will be 1.8 in order to avoid confusion with the Windows release series but that if there is another pre-rxgk release series that will be 1.9
[15:52:37] <kaduk> I think that's what I'm hearing as well.
[15:52:51] <wiesand> Me too
[15:53:09] <Jeffrey Altman> is there anything else to discuss on this subject?
[15:53:29] <wiesand> When to do it?
[15:53:31] <deason> if people still think an odd number "looks like" "devel", there's no real downside to just using even numbers :)
[15:53:40] <kaduk> Branding for the windows releases seems to be undecided, but I don't know that I want to talk about it here.
[15:54:04] <kaduk> (s/here/here and now/)
[15:54:42] <wiesand> Hopefully, 2.0 will become ready before a 1.9 would?
[15:54:51] <Jeffrey Altman> The immediate decision I need to make is the 1.7.3100 release and for that I'm tempted to issue it as 7.31.0 or 17.31.0.   I would prefer 7.31.0
[15:55:17] <kaduk> 7.31.0 sounds fine to me.
[15:56:01] <wiesand> Fine here.
[15:56:09] <Simon Wilkinson> If there's stuff that's still undecided, I wouldn't do anything different for 1.7.3100
[15:56:30] <Simon Wilkinson> Like, if we're going to call it FooBarBaz, we should do the version number change at that point.
[15:56:34] <deason> I'd rather have it have at least some kind of different name, so it's not just "openafs 7.31.0"
[15:57:06] <Jeffrey Altman> at the moment its "OpenAFS for Windows"
[15:57:13] <Simon Wilkinson> Which is probably fine
[15:57:13] <deason> okay
[15:57:18] <meffie> sounds good
[15:57:28] <Jeffrey Altman> That is what the packaging has said since 2004
[15:57:37] <meffie> yes
[15:57:37] <deason> I'd also caution there's "no going back" after doing a bump like that unless we want things to get really confusing
[15:58:10] <wiesand> You can still go on to year.month.patchlevel.
[15:58:40] <Jeffrey Altman> There is at least one site that rebuilds each release as year.month.day
[15:59:09] <deason> and date-based numbering was suggested on the list; but I assume people don't want that for general releases?
[15:59:51] <Jeffrey Altman> My concern with it is that doing so does not permit the continued maintenance of a prior release series without major confusion
[16:00:04] <wiesand> True.
[16:00:41] <Jeffrey Altman> When I push a major rewrite (~40% of the redirector code base) as a new major version I want to be able to continue to update the prior release series for some time
[16:01:22] <deason> it's possible to use the date as a replacement for just the first number in the version, but that probably looks confusing
[16:01:36] <deason> that is, the date would be the 'series', but that's probably worse (misleading date)
[16:01:49] <Jeffrey Altman> I would prefer major.date
[16:02:36] meffie leaves the room
[16:02:59] <kaduk> Jeffrey: you would prefer major.date to year.month.x, or to 7.31.patch?
[16:03:01] <deason> ah yes, or that
[16:03:18] <Jeffrey Altman> but even that is difficult given the size of the fields.  which is why kfw used a epoch
[16:04:35] gorgo joins the room
[16:04:49] <Simon Wilkinson> I'm not sure what date based versioning really gives you, beyond knowing how far out of touch you are.
[16:07:53] <wiesand> What will the new branches be? -stable-1_8_x and -windows-7_x_y ?
[16:07:54] <Jeffrey Altman> Windows has no packaging equivalent of rc, pre, alpha, beta in the version string.   It can be encoded in other installer and binary metadata but not the version.   The benefit that date based versions provide is the ability to have daily test builds and then choose one that will be the official release
[16:08:19] <Jeffrey Altman> we can get rid of the "openafs-" prefix
[16:08:43] <Simon Wilkinson> But then you end up with the mess that OpenLDAP were in for a while, where you have a load of "version numbers" and a stable tag that moves between those versions.
[16:09:04] <Jeffrey Altman> I would suggest "1_8_x" and "windows-<major>-x"
[16:09:04] <kaduk> I think some of Russ's tooling for Debian would break if we had a stable-1_8_x branch.
[16:09:32] <Jeffrey Altman> if we need to keep it we should
[16:09:41] <deason> can we not move to v1.8.x ?
[16:10:04] <deason> and were you hoping to still have a separate branch for windows? the separate releases doesn't necessarily require that, but it's an option
[16:10:38] <deason> > can we not move to v1.8.x ?
that was maybe not clear; I meant "why not v1.8.x ?"
[16:10:54] <wiesand> Me? Yes. (separate branches)
[16:11:27] <deason> anyone, I suppose
[16:11:30] <wiesand> (except for master)
[16:11:42] <Jeffrey Altman> I don't see how to do separate windows releases without separate branches
[16:11:47] <Simon Wilkinson> v1.8.1 would be the tag in normal git parlance
[16:12:06] <Simon Wilkinson> The branch would ideally be called something sufficiently different that folk don't typo between the two
[16:12:12] <kaduk> (I'm looking for this alleged tooling and not seeing it right away.  In any case, it's probably not very hard to change.)
[16:13:04] <deason> you can still be on the 1.8.x branch and release a windows release in between the unix releases; I don't see what prevents that
[16:13:05] <wiesand> Well, today it's -stable-1_6_x and stable-1_6_8 ...
[16:13:39] <deason> just call it e.g. 7.2; the tags would still be called the windows-y names but the branch doesn't have to match it
[16:13:47] <Simon Wilkinson> The issue is that Windows might want to change bits outside of src/WINNT that we don't necessarily want in a Unix stable release
[16:13:54] <Simon Wilkinson> That's what happened last time
[16:13:56] <kaduk> As an example of what Andrew is describing, the KfW 4.0.x releases were cut from the krb5-1.10 branch.
[16:14:53] <deason> that's something I mentioned as a hypothetical in the email, but I wasn't sure if that was a real concern
[16:14:53] <Jeffrey Altman> The situation I'm in at the moment which is I have a ton of code that can't be merged onto the release branch because it is too large a change.    This is the reason that synchronizing with UNIX branches is hard
[16:15:35] <deason> this is code that affects e.g. rx? but it's considered stable enough for windows but not stable enough for unix?
[16:15:49] <Jeffrey Altman> As Simon has indicated, the Windows branch also has a lot of stuff from master that is not included in 1.6
[16:16:09] <wiesand> And vice versa, I believe?
[16:16:15] <Jeffrey Altman> yes
[16:16:35] <Simon Wilkinson> For example, master has roken. 1.6 does not.
[16:16:39] <deason> that's how it is now, yeah, but will that need to happen in 1.8?
[16:17:37] <Jeffrey Altman> There have been three major forks of Windows from mainline OpenAFS in the last ten years.  I am not going to rule out another one.
[16:18:30] <deason> I understand that, but I thought the rearchitecturing was largely for things in WINNT; does that really require changes to rx etc?
[16:18:38] <deason> (or 'auth' is maybe more likely?)
[16:18:50] <wiesand> I fail to see what's bad about separate stable branches.
[16:19:30] <kaduk> Trying to avoid separate stable branches seems like it's just setting us up for sadness in the future.
[16:19:45] <deason> the only downside I see right now is having to pull changes into two stables branches instead of one
[16:19:56] <deason> maybe more likely to miss things, etc
[16:20:10] <deason> but if having just one branch is a lot of hassle then having two branches doesn't seem so bad
[16:20:49] <kaduk> (Found the bits of Debian tooling, and changing them is indeed very easy.)
[16:22:23] <deason> and just mentioning, e.g. v1.8.2 is what most other things use
[16:22:41] <deason> I don't know if I've seen tags or banches more obnoxiously named than ours
[16:22:47] <deason> branches, even
[16:23:20] <deason> (and I personally always create v1.6.7 etc branches locally anyway)
[16:23:20] <ballbery> I have :)
[16:23:49] <ballbery> (granted, it's not common and seems to be most prevalent in projects that migrated from cvs/svn)
[16:24:50] <Jeffrey Altman> feel free to continue the discussion but I have to walk away
[16:25:55] <wiesand> Same here. I'm fine with 1.8 and 7.x. The rest are details.
[16:26:34] <deason> I don't think there's anything else that needs to be covered; the user-facing "branding" parts are what is most important
[16:26:55] wiesand leaves the room
[16:27:03] <deason> like I think I've mentioned before, the pain points were mostly from users and such, the versioning stuff I don't think has been difficult for developers
[16:27:03] stephan.wiesand leaves the room
[16:27:25] <deason> so whatever we figure out for our side we should be able to handle
[16:44:55] gorgo leaves the room
[16:45:30] madaraszg joins the room
[17:01:39] madaraszg leaves the room
[17:02:20] madaraszg joins the room
[18:02:44] meffie joins the room
[19:22:42] meffie leaves the room
[20:01:21] mvita leaves the room
[20:41:28] madaraszg leaves the room
[21:01:42] Simon Wilkinson leaves the room
[21:03:06] Simon Wilkinson joins the room
[21:22:38] kaduk leaves the room
[21:59:05] deason leaves the room
[21:59:05] deason joins the room
[23:07:51] deason leaves the room