[00:02:41] --- Jeffrey Altman has become available [04:21:09] --- Stephan Wiesand has become available [04:43:44] --- meffie has become available [05:28:53] test... [05:33:44] pass [05:34:52] Hi Mike. Merci. [06:13:48] --- Marc Dionne has become available [07:02:05] --- deason has become available [07:02:15] Hello [07:02:21] hi [07:02:33] hello [07:02:40] good day [07:02:55] I have at most 90m today. [07:03:13] Have to pick up my new glasses... the old ones are gone with the wind. [07:03:41] Let's start? [07:03:59] aye [07:04:01] 1.6.5.1 [07:04:18] hi everyone [07:04:29] Hi Marc, forgot that on the "agenda": any bad news from Linux 3.12? [07:05:01] still good so far [07:05:31] Do you have an estimate for the release date? [07:05:31] last tested a few days ago, at rc4+ [07:06:05] well release is usually around rc7-9, and it's 1 week per rc [07:06:22] so probably another month or so [07:06:44] Thanks. I think we shouldn't block 1.6.5.1 on that. [07:06:59] nor should we block 1.6.5.1 on OSX Maverick [07:07:19] Worst case, we need 1.6.5.2 for 3.12 (and maybe Maverick). [07:07:42] I figure Derrick has access to the developer seed? [07:08:39] YFS has access to the seeds [07:08:56] GM has already been cut. No date for final release but it is soon [07:09:28] Any estimate how much has to be changed for openafs to work on it? [07:10:32] Derrick would need to respond to that question. [07:11:01] Anyway, let's look at what we have: a rather well tested tip of stable-1_6_5_1, and 10331 as a candidate. [07:11:36] I believe Derrick isn't actually present. [07:12:17] If we merge 10331, are out test results still valid? [07:12:41] well, it's linux-specific [07:13:02] and even then, you'd only need to re-test building if you really want to [07:13:46] in theory if you have keyrings it's a noop [07:14:33] Of course. But how confident are we that the theory is correct? [07:14:41] Given that the change is not a change to the behavior of the function but just when the function is compiled I would just merge it [07:15:53] Yes, it looks so simple that I'm actually tempted to believe that all tests on systems with keyring support (and AIX of course) is still valid. [07:16:29] If anyone has serious concerns, please speak... [07:16:47] how confident? confident enough that I don't think anyone else here wants to spend more time on it :) [07:17:09] Got it :-) [07:18:33] Merged. [07:18:54] If there are any objections to 10332, -1 it now... [07:19:08] (please) [07:19:39] its fine [07:20:25] Thanks. Merged. [07:21:31] There is one negative report from Harald. He fails to build Christof's SRPM and from the tarball therein on that Cray system. [07:22:30] But that seems to be rather special, and right now he's unavailable. [07:22:53] do you have a pointer? or was that via private communication? [07:23:19] He sent it to Christof and me today. Mail ended with "gotta run"... [07:23:46] Just forwarded it to you. [07:24:23] Anything else that would keep us from releasing the current HEAD of stable-1_6_5_x as 1.6.5.1? [07:26:30] just a tag :) [07:27:28] Fine. Derrick is supposed to be on a plane I believe. But we should get that r.s.n. [07:28:04] By the way is there a need to wait for the tag on git.openafs.org before cutting tarballs? [07:30:02] Regarding binaries: Stephen built the preliminary tarballs for EL6 and Fedora15..19. [07:30:26] Which kind of answers who can provide binaries for Red Hat ;-) [07:30:39] EL5 is still missing though. [07:31:11] Anyone who feels like providing AIX binaries? Does it make sense at all? [07:31:46] And the general question: Should we wait for binaries, or release without them and possibly add them later? [07:32:07] "is there a need to wait for the tag" doesn't running regen run git-version? the version number is embedded in configure, so you'd need to wait for the tag if you want the correct version in there the 'correct' way [07:32:38] you could fudge it with a local tag, though [07:32:50] Well, I can copy the whole git repo, tag -a, cut the tarballs, and throw the copy away. [07:33:14] That's how last week's tarballs were made. [07:33:23] hmm. [07:34:09] Certainly good enough for testing, but good enough for an actual release? [07:34:10] you can apply the tag locally to cut tarballs. Just let Derrick know explicitly what sha1 the local tag was applied to and the tag name [07:34:44] Derrick is on vacation until Monday although I'm sure he will check mail long enough to permit issuing a tag [07:34:57] Thanks. [07:35:11] If it's Monday, well. [07:35:52] On to 1.6.6 ? [07:36:38] We can forget about 10325, unless someone would want it to be reverted. Merged it today before pulling up to 1_6_5_x. [07:37:02] 10310 seems to be something to discuss though? [07:37:25] I don't think it makes anything worse [07:37:35] just "parallel builds still aren't completely fixed yet" [07:37:49] we'll get there, just not for 1.6.6 [07:37:53] yep. [07:38:45] I see no reason to revert it [07:39:04] (and aix binaries probably would be useful; those two sites that complained about it seemed like they normally use the provided binaries) [07:39:24] The point is we haven't had such buildbot failures for a long time on the 1_6_x branch. All those rebases, not a single problem. But the very first build after merging 10310 failed... [07:40:22] yes. i can push some changes to master and 1.6.x for review. [07:41:23] yet we have seen the parallel build failures on master. they are timing dependent where the configuration of the builder can impact the timing and the races in a variety of ways [07:42:14] i think it made things a bit worse - it cures one issue (not handling a dissapearing .h correctly, and maybe other cases) for some potential build failures. but not sure that parallel build problems should be show stoppers [07:42:35] I'd be more concerned if there were a lot of things that still needed to be added to 1.6.x; we can fix it quickly for the 1.6.x branch after 1.6.6 [07:42:44] we can turn off parallel builds in the slave configurations. the builds will just take longer [07:43:21] and yeah, the greatest impact is for gerrit, imo, not for users; we can deal with it if we need to [07:43:24] and if you're building manually and you get a failure from a parallel build, you can usually just repeat your make and it will complete [07:44:24] and that could still already happen, and I think people that aren't new to building the tree kinda expect it to happen [07:45:00] Parallel build failures are a real nuisance for packagers (like me), testers, contributors of bug reports, and projects like rpmfusion, elrepo, and all those others building their own binaries, [07:45:42] they shouldn't be building it in parallel; I don't think you should be building a large project like that unless you know that upstream supports it [07:46:29] i am testing a better fix based on 7921, but still uncovering places we dont have proper dependencies. [07:47:04] If the project considers parallel builds unsupported, we should break them completely. [07:47:38] I'm not aware of any problem caused by them once the build has succeeded though. [07:47:50] yep. [07:47:58] And have been running such binaries for a decade. [07:48:03] there are no issues with parallel builds and the code they generate [07:48:51] And those bug hunting sessions "here's the next patch to try" are ugly enough as they are. No need for significantly longer build times, really. [07:49:01] the issue with parallel builds is whether there are appropriate dependencies within the tree to ensure that make is capable of scheduling parallel builds in a safe manner. the fact is that OpenAFS does not make such a guarantee. [07:49:20] i don't see how parallel build executables would have issues [07:49:45] yeah, they wouldn't [07:49:59] the only issue with parallel build failures is whether or not the build completes. [07:50:04] i'm sure there are other parallel build dependency problems out there in the tree - i've tried to fix the ones i see, but errors are very timing dependent [07:50:08] it's just a matter of cleaning up the dependences as this point. [07:50:32] 1.6 releases have been pretty good in this respect. If we suspect that 10310 could make things worse, I's be against releasing a 1.6.6 with it. [07:51:07] I don't think they are worse. I think the failure points are different [07:51:33] my opinion is that it doesn't matter, so I won't object to reverting it [07:52:14] Every time we make a change to the dependency graph it is possible that the ordering of build components will change which in turn alters the timings and potentially exposes the next issue [07:53:17] my opinion is that there is more risk of failure after 10310 [07:53:32] I don't feel strongly about it one way or the other. [07:54:16] The conservative approach argues that build system changes should remain on master and not be pulled to 1.6.x [07:54:28] We'll gather some more statistics in the coming days. If we see a significant failure rate, I'm in favour of reverting it. [07:54:42] ok. [07:54:56] A single failure is not significant. Poisson statistics says it's 1 +-1... [07:56:08] Ok. Everything that was pulled up to 1_6_x was merged (except those clearly not to be merged at this point). [07:57:58] was the motivation for 10310 observed parallel build failures, or for other issues (like not rebuilding a missing .h file, etc.) [07:59:02] both; and build failures for non-parallel builds. (make clean; make all) [07:59:09] fyi, current openafs master fails a parallel build here 100% of the time [08:00:29] does anyone object to the compile_et change that would generate file separately - that does seem like the cleanest way forward [08:00:29] ok. well, i'd like to fix this with 7921, and i'm testing that now. [08:00:41] it does. [08:01:53] and it is very clear when the dependencies are incorrect with that approach. [08:02:05] I have no objection to modifying compile_et to generate single files [08:02:40] I also have no objection to changes to the tree that make the build fail when dependencies are wrong [08:03:35] I'm clearly not the expert here, but 7921 looks like the way to go to me. [08:03:41] excellent. i was under the assumption that we needed to support external compile_et versions, if that is the case then we could cope with it but i'd rather not (it involves temp files) [08:04:41] of course 7921 would need to be followed by reworking the Makefiles to make use of the new options [08:05:02] yes, i've done that, testing now before i push to gerrit. [08:05:16] amazing... [08:05:22] is that an option for including in 1.6.6 if we see it done and verified soon enough? I thought this was a post-1.6.6 thing, but I'm not sure from the last few minutes [08:05:56] I think it is a master only thing [08:06:01] That's probably because I haven't gotten around to writing them :-( [08:06:48] It's not supposed to incur any functional change. If it's ready, why not include it in 1.6.x. I wouldn't want to block 1.6.6 on it though. [08:07:27] ok [08:08:51] Let's see how it does on master, how hard it is to pull up etc. 1.6.6 can go as is if build failure rates are low to 0, otherwise we can revert 10310. [08:08:59] ok [08:09:21] Anything else to consider for 1.6.6pre1? [08:09:48] Ben mentioned some changes for BSD, but I haven't seen any activity in gerrit in this regard. [08:11:06] if it shows up, it shows up [08:12:39] that is my opinion. do not wait for it [08:13:14] this week is the kerberos conference at mit. I doubt Ben will be spending much time on openafs [08:13:32] Ah. [08:14:01] It seems pre1 can go out right after 1.6.5.1 then. [08:14:19] good [08:14:58] The question whether to wait for 1.6.5.1 binaries is still open. Thoughts? [08:15:10] binaries can come as they are available [08:15:35] If it wasn't such a hassle to update the web page, I'd be completely in favour of releasing without binaries at first. [08:16:12] But yes, we should rather get it released. [08:16:50] Once the tag is in place third party distributions can begin builds [08:17:07] Note that Russ is on vacation for two weeks so Debian is unlikely until then [08:18:13] Ok. And Stephen won't even have to wait for the tag to start. It still takes about a week to build for all Red hat distros. [08:18:52] I think we'll include whatever is ready in the initial release, but won't wait for more. [08:19:19] Fine. Anything else to discuss today? [08:19:31] give me a minutes [08:20:43] Do you need a minute, or is this a quip about me failing to write minutes for three weeks now? [08:22:56] The 1.6 series is now just over two years since the first production release and it is nearly four years old as measured from the introduction of dafs into the 1.5 series. The Windows 1.7 releases are now at a point where there are stable and 1.8.0 will soon be issued. It is time for us to begin working on a 1.9 branch with the intention of getting 1.10 out the door. [08:23:58] Ah. Major topic. [08:24:33] IMO, yes, unless you want to discard most progress on master in the long run, this has to happen eventually. [08:24:50] The major changes for 1.10 would be pthreaded ubik, the hcrypto changes, all of the libtool work, and other things that have landed on master over the last 2.5 years [08:25:12] so we are abandoning the plan to make 2.0 the next major version? [08:25:28] The roadmap has said 1.10 is the next release for quite some time [08:25:58] From the roadmap.html page: Major new features will be integrated into 1.9 releases in preparation for the 1.10 stable release. October 2011. [08:26:25] Obviously 2011 is long past [08:26:56] yes, and I thought after that it was said that the next one was 2.0 [08:27:17] obviously the roadmap isn't updated very often, and is not something I consult to get the actual current plan of action [08:27:19] 2.0 is rxgk whenever there is rxgk [08:27:28] yeah, I know [08:27:49] The 2.0 is rxgk statement was made in March 2004 [08:28:37] Where would 1.9 be branched off? [08:28:43] From master [08:28:48] I'm talking about when we had the discussions for thr 1.6/1.7/master.... thing, when we had the plan for 3 branches [08:29:06] and we argued about whether we would be cherry-picking or merging [08:30:06] but yes, 1.10, fine; so we'll have one stable branch again [08:31:32] When 1.9 is nearing readiness for production, we start restricting 1.6 to critical changes? [08:33:02] Stupid question? [08:33:13] I suspect that there will be demand for 1.6 releases for at least a year after 1.10. As confidence in 1.10 grows, the rate of updates to 1.6 should slow [08:35:47] Realistically, we won't be able to do much more than security fixes for 1.6 after 1.10 was released. Maybe enabling new Linux kernels, as long as Marc can help. [08:35:52] The problems that Mark Vitale described on openafs-devel two weeks ago with LWP thread priority inversion simply do not exist with pthreads. pthreaded ubik has been on master for 18 months. It is about time that end users get to use it [08:36:51] An alternative would be to more aggressively pull up to 1.6 and converge to master in the long run. [08:37:00] Not sure it's realistic. [08:37:24] well, specifically with tubik, it _is_ on 1.6, and whatever fixes on master could be pulled to 1.6 [08:38:27] for some of the other things mentioned, pulling to 1.6 isn't really feasible [08:38:46] the policy is that we do not pull new functionality on to stable branches. there is much more on master than just pthreaded ubik [08:40:38] Ok. Sorry, I really have to run now. Pity. But I'll read up in about an hour, and if you're still discussing... [08:40:39] I wanted to put this out for people to think about. [08:40:54] "the policy is that we do not pull new functionality on to stable branches" whether or not what you consider the policy is, we have definitely been pulling new features into 1.6 [08:41:14] not that I'm trying to say to pull e.g. libtool changes into 1.6, hah :) [08:41:35] yes we have and doing so is undesirable. [08:41:54] the shared library stuff alone is going to require deployment changes... I was expecting to not need to do that before 2.0, where it's clearly a big leap [08:42:22] but yeah, okay okay, no need to discuss the details right now [08:42:23] Once a new release is at least on the horizon, following that policy will be easier. And of course you can blame it all on me ;-) [08:42:24] clearly 1.10 is not going to be issued next month [08:42:29] Ok, bye for now. Sorry. [08:42:31] --- Stephan Wiesand has left [08:42:49] It probably won't be six months. [08:43:03] but if we do not get started soon it is going to become more difficult [08:58:32] ok, have a good afternoon/evening [09:10:49] --- Marc Dionne has left [09:34:48] --- ktdreyer has become available [09:40:28] --- stephan.wiesand has become available [10:51:11] --- ktdreyer has left [13:37:37] --- stephan.wiesand has left [14:23:24] --- Jeffrey Altman has left: Disconnected [14:33:55] --- Jeffrey Altman has become available [15:42:35] --- deason has left [16:06:39] --- meffie has left