- Wednesday, September 10, 2014

release-team@conference.openafs.org

Wednesday, September 10, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[06:56:44] Simon Wilkinson joins the room
[07:44:55] Simon Wilkinson leaves the room
[07:54:07] Jeffrey Altman leaves the room
[08:00:35] Jeffrey Altman joins the room
[08:37:32] shadow@gmail.com/barnowlE5B64A04 leaves the room
[08:42:33] shadow@gmail.com/barnowlE5B64A04 joins the room
[10:16:32] Simon Wilkinson joins the room
[10:17:10] Simon Wilkinson leaves the room
[10:30:01] Simon Wilkinson joins the room
[11:45:53] Simon Wilkinson leaves the room
[11:47:57] Jeffrey Altman leaves the room
[12:05:50] Jeffrey Altman joins the room
[12:13:41] meffie joins the room
[12:53:56] Simon Wilkinson joins the room
[12:54:37] Simon Wilkinson leaves the room
[13:47:08] kaduk joins the room
[13:56:16] stephan.wiesand joins the room
[13:57:40] <kaduk> Ah, fearless leader; good morning!
[13:58:49] <stephan.wiesand> Good afternoon.
[14:01:26] <meffie> good day
[14:02:50] <stephan.wiesand> Ok, let's start.
[14:03:15] <stephan.wiesand> Linux: Marc pushed 1455, but I think that's not the end of the 3.17 story.
[14:04:07] <kaduk> I think it sounds like debian jessie is going to be at 3.16
[14:05:22] <stephan.wiesand> Fedora will eventually ship 3.17. But yes, is't probably not urgent. And without the complete changes needed for 3.17, no reason to delay 1.6.10 atm IMO.
[14:06:03] <kaduk> Seems reasonable here.
[14:06:30] <stephan.wiesand> The 11448 you brought up is clearly FBSD-only.
[14:06:55] <kaduk> Yeah, I think I can claim that it is zero-risk.
[14:07:13] <stephan.wiesand> You want it in 1.6.10?
[14:07:34] <kaduk> There was at least one person on IRC who sounded like they would play with a disk cache again if it was there.
[14:07:37] <kaduk> So, yes.
[14:07:49] <Jeffrey Altman> gm
[14:08:01] <stephan.wiesand> Hello
[14:08:14] <Jeffrey Altman> I defer to Ben's wishes with regards to FreeBSD
[14:09:17] <stephan.wiesand> And you +1'ed it anyway. About to hit the submit button...
[14:09:36] Simon Wilkinson joins the room
[14:10:04] <stephan.wiesand> Done.
[14:10:37] <stephan.wiesand> Nothing else was brought up for urgent inclusion in 1.6.10 I believe?
[14:11:06] <kaduk> I think that's right.
It sounds like the arm64_linux stuff is not actually ready yet.
[14:11:52] <stephan.wiesand> We'll have a 1.6.10.1 anyway. If it's ready for that, fine.
[14:12:22] <stephan.wiesand> I think we should release 1.6.10 r.s.n. I
[14:12:29] <Jeffrey Altman> agreed
[14:13:10] <kaduk> Sounds good to me.
[14:13:29] <stephan.wiesand> 'd like to run a final test, the version strings  change is missing, and NEWS should be updated. But we can do this in the next days.
[14:14:06] <stephan.wiesand> Since we have Jeffrey A=ans SImon here, we should probably spend the rest of our time today on that topic i dropped off the agenda...
[14:14:56] deason joins the room
[14:15:03] <stephan.wiesand> And I dropped it because last week I lost all hope for it ever happening. Please prove me wrong.
[14:15:24] <kaduk> I think you had also mentioned  11380 in the agenda, which is still not merged on master IIRC.  I think it's okay to leave it for 1.6.11
[14:16:07] <kaduk> With regard to that other item, I hear a 24 September deadline and am aiming for it.
[14:16:44] <kaduk> I would like to hear from Simon about the eventual plans for the liboafs_foo.so libraries.
[14:17:30] <Simon Wilkinson> The plan in creating them was that OpenAFS would eventually move towards using shared libraries, and use the symbol export lists to enforce module boundaries.
[14:18:00] <kaduk> Are we "not quite there yet" such that that is not a reasonable 1.8 goal?
[14:18:34] <Simon Wilkinson> AIX already builds all of its objects shared
[14:18:51] <Simon Wilkinson> binaries shared, even
[14:19:19] <kaduk> So, it might make sense to play around with that some for the other platforms, once I get the other libraries sorted out?
[14:19:33] <kaduk> (Or someone else could play around with, &c..)
[14:19:46] <stephan.wiesand> Is there a real value to this nowadays?
[14:20:05] <Simon Wilkinson> The value is in terms of promoting good development practice.
[14:20:37] <stephan.wiesand> That's fine. But no showstopper I think.
[14:20:37] <kaduk> Not reaching into other modules and directly accessing their symbols, that sort of thing.
[14:20:40] <Simon Wilkinson> It does also help in terms of memory usage and disk space, but those aren't hugely beneficial on today's systems (unless you're looking at embedded hardware)
[14:21:02] <Simon Wilkinson> The issue is that this is work that's half done on master, so you need to decide what to do with it for a release series.
[14:22:11] <stephan.wiesand> Is this half done work a regression w.r.t. 1.6?
[14:23:38] <kaduk> I don't think it's a functional regression, no.
[14:24:34] <kaduk> Is Mike still planning on doing a whitespace cleanup?
[14:24:36] <Simon Wilkinson> It's only an issue if any of the shared libraries that we commit to shipping have dependencies on the shared libraries we don't ship
[14:25:00] <meffie> oh, i can push that now if you want.
[14:25:17] <meffie> (to gerrit)
[14:27:21] <meffie> pushed as 11456
[14:28:25] <kaduk> The wiki page has "Make libtool export symbol lists generated by configure (maybe?)"
[14:28:33] <Simon Wilkinson> That's a bad idea
[14:29:09] <Simon Wilkinson> Your symbol lists are pretty precisely tied to the versioning information in your software. You don't want them changing because someone changes a config option
[14:29:10] <kaduk> Ah, so it's not just Chas who thinks so ;)
[14:29:45] <Simon Wilkinson> It's a huge pain with roken.
[14:30:43] <kaduk> Any tips for how to supply an rxgk_GetServerInfo symbol from libafsrpc when rxgk support is disabled at configure time, then?
[14:31:00] <kaduk> I think I came up with a handful of differently hacky solutions, none of which I was happy with.
[14:31:06] <Simon Wilkinson> Provide stub functions which return EINVAL for anything that's exported
[14:31:23] <kaduk> But provide them in what compilation unit?
[14:31:52] <Simon Wilkinson> Well, I would enter the rxgk directory, even if rxgk is disabled
[14:32:14] <kaduk> Oh.  I thought that ended up being pretty awkward, but maybe I didn't look at it very hard.
[14:35:31] <kaduk> The wiki also has an item "finish rxosd support" for pre-branching tasks.  Do we have anyone who cares enough to put developer time in?
[14:36:10] <stephan.wiesand> I wondered whether that actually meant "finish off" ;-)
[14:37:27] <kaduk> Heh ;)
[14:38:14] <kaduk> Looking at the FreeBSD packaging reminded me of the existence of 10993, which tries to remedy the current situation where we install the kauth-related manpages even when configure was given --disable-kauth.
[14:39:06] <kaduk> Chas had suggested that we might switch to explicit lists of man pages to install (instead of globs), which seems like something to get done pre-branch, if we want to go that route.
[14:39:06] <Jeffrey Altman> The problem with rxosd is that no one in the OpenAFS community other than Hartmut's employer has been willing to spend time on rxosd.
[14:39:25] <kaduk> (Actually, I think we could probably push the manpage installation change down to 1.6 as well.)
[14:40:22] <stephan.wiesand> Packaging is dealing with the manual pages.
[14:40:23] <kaduk> And Hartmut is retired, now, right?
[14:40:46] <Jeffrey Altman> Its complicated
[14:40:49] <meffie> ha
[14:41:40] <meffie> er, sorry.
[14:41:48] <shadow@gmail.com/barnowlE5B64A04> > You don't want them changing because someone changes a config option
[14:42:09] <shadow@gmail.com/barnowlE5B64A04> istr the problem was on solaris where if your export list had an
unknown symbol, everything went to hell.
[14:42:56] <shadow@gmail.com/barnowlE5B64A04> anyway, yeah, i understand why it's of value to steer clear of the
mess
[14:45:24] <kaduk> Any thoughts about man pages?
[14:46:06] <stephan.wiesand> I think rxosd has no chance to get "done" anytime soon.
[14:46:19] <Jeffrey Altman> as long as there are dependencies between the man pages, then I think all of the referenced pages need to be installed.
[14:46:45] <stephan.wiesand> Man pages: we install quite a few that don't apply in some cases.
[14:47:11] <stephan.wiesand> Like xfs_size_check.
[14:48:02] <stephan.wiesand> Fixing a few cases isn't worth any delays imo.
[14:49:21] <kaduk> Well, one potential issue is the kpasswd man page.  We came up with --disable-kauth to prevent conflicts for the kpasswd binary, but at present it doesn't do anything for the man page conflict.
[14:49:48] <kaduk> I'm not sure that there are any dependencies from non-kauth things on kauth things, in the man page world.
[14:49:55] <Jeffrey Altman> http://docs.openafs.org/Reference/index
[14:50:50] <Jeffrey Altman> http://docs.openafs.org/Reference/1/afs.html
[14:51:08] <Jeffrey Altman> I'm not going to look further
[14:51:17] <kaduk> Oh.
Thanks for the example.
[14:51:50] <kaduk> Moving on...
[14:51:55] <meffie> heh
[14:52:33] <kaduk> I seem to have accumulated a pile of random one-off commits in gerrit targetted at master.  Can I get some gatekeeper guidance for what level of them it is reasonable to go refresh and try to get in before 1.8 branches?
[14:58:58] <stephan.wiesand> No ;-)
[14:59:07] <kaduk> "Aw, shucks."
[15:01:31] <Jeffrey Altman> sure
[15:01:42] <stephan.wiesand> Could you recap the list of firm to-do items before 1.8 can happen for me?
[15:02:09] <kaduk> todo items:
(1) make roken and hcrypto use libtool
[15:04:00] <kaduk> (2) Make sure libtool is used "properly" elsewhere, in particular to install the public interfaces libafsrpc and libafsauthent which we currently ship
(3) Maybe still part of (2), but verify that the shipped libraries do not depend on anything which is not shipped
(4) (maybe optional) look at feasibility of installing shared liboafs_foo and making the client utilities dynamically linked
[15:04:25] <kaduk> (5) I can't in good conscience put rxosd on this list, sorry
[15:04:52] <Jeffrey Altman> I don't blame you.
[15:06:44] <kaduk> (6) Do install and run testing on various platforms; check for memory leaks in servers, etc..
(7) Maybe part of (6), check that the kernel module is done properly on a wide handful of linuxen.
(8) Debian packaging will help do a lot of the libtool validation
(9) Mike's whitespace thing
(10) Potentially other tree-wide cleanup
[15:07:14] <kaduk> I guess I should transcribe this list to the wiki page after the meeting.
[15:07:31] <Jeffrey Altman> thanks
[15:07:32] <kaduk> Am I missing anything?
[15:07:46] <kaduk> (Well, "probably", but anything in particular that comes to mind.)
[15:08:33] <stephan.wiesand> Quite a list for two wweks.
[15:08:48] <Jeffrey Altman> updating any installation packaging that is going to be maintained by OpenAFS for 1.8.   However, that is less of a concern for me since it is unlikely that packaging will change on master after the 1.8 branch
[15:09:36] <kaduk> (BTW, the 1145[1-4] that I mentioned in email are mostly pretty trivial.)
[15:11:09] <kaduk> (I am going to assume that Jeff is still typing up the guidance for how many/what sort of random patches in gerrit to refresh prior to branch.)
[15:11:47] <Jeffrey Altman> I would like you to send me a list of the patches so I know what to look at
[15:11:58] <kaduk> Okay, I will do that.  Thanks.
[15:12:24] <stephan.wiesand> Would it make sense to send it to -devel instead?
[15:12:48] <Jeffrey Altman> more eyes the merrier
[15:13:58] <Jeffrey Altman> I guess another question for 1.8 is whether pthread-bos is intended for 1.8
[15:14:30] <kaduk> I think we had mentioned that several weeks ago, and were leaning towards post-1.8.
[15:15:09] <kaduk> There is a fair amount of churn that would affect the non-pthreaded version and thereby be "risky".
[15:15:33] <Jeffrey Altman> is switching to pthreaded db servers something folks want for 1.8?
[15:15:51] <Jeffrey Altman> folks == release-team members
[15:16:11] <stephan.wiesand> With my site admin hat on: why would I want to?
[15:16:17] <kaduk> What does "want" mean?  "force on everyone"? "have as an option"?
[15:16:25] <Jeffrey Altman> make default
[15:16:26] <meffie> debugging lwp is a nightmare.
[15:16:54] <meffie> well, at least not fun.
[15:17:57] <stephan.wiesand> Is it ready?
[15:18:17] <kaduk> I think that defaulting to --enable-pthreaded-ubik is reasonable.
[15:18:39] <kaduk> So, I guess that implies
(11) Adjust default configure values
[15:19:02] <kaduk> (since ~everyone I know passes a giant barrage of arguments to configure)
[15:19:36] <kaduk> Somewhat related would be the default fileserver tuning, but I'm not sure I'm the right person to do that.
[15:19:42] <meffie> also, default fileserver..
[15:20:33] <meffie> er, what ben said.
[15:21:15] <kaduk> (dafs vs. not is not actually something that we have defaults for (other than documentation), right?)
[15:21:46] <kaduk> (12) beg and plead for people to update the documentation
[15:22:01] <meffie> right, dafs vs fs is a bos create time option
[15:22:04] <Jeffrey Altman> Both are installed.   The choice is the administrator to decide which to configure
[15:22:43] <meffie> what is the default for pts supergroups?
[15:22:50] <kaduk> default is off ATM
[15:22:57] <kaduk> (I was just looking at that :) )
[15:23:23] <meffie> but the rpms have it on, ircc?
[15:23:44] <kaduk> That sounds vaguely familiar.  Once a packaging has turned it on, they can't reasonably turn it off.
[15:25:01] <kaduk> Back when I was poking at the prdb format, I think we had consensus that we should make the ptserver always have the code to understand the supergroups format, but be able to disable the use of supergroups at runtime.
[15:25:06] <Jeffrey Altman> SuperGroups are off except for distributions that explicitly enable it.   Debian enables it and Russ has frequently said that doing so was a mistake
[15:25:39] <meffie> ok
[15:26:09] <kaduk> (I don't think that such ptserver changes are needed before 1.8)
[15:28:02] <Jeffrey Altman> The problem with supergroups is that there needs to be a method of enabling/disabling it that will be enforced by all servers in the cell.  A runtime switch is dangerous because it means that setting or not setting it inconsistently results in different servers generating different CPS responses for the same queries.
[15:28:24] <Jeffrey Altman> A flag in the DB itself is probably the right way to do it.
[15:28:34] <Jeffrey Altman> I agree this is not a 1.8 subject.
[15:28:37] <kaduk> Well, "runtime" may mean "a bit in the prheader flags"
[15:28:52] <Jeffrey Altman> yeah
[15:29:37] <kaduk> (This should even allow transparent migration for sites currently using supergroups, if we're sufficiently clever.)
[15:33:24] <Jeffrey Altman> agreed
[15:34:40] <stephan.wiesand> Ok. To wrap up: release 1.6.10 as is a.s.a.p., and we have a todo list for 1.8.
[15:34:48] <kaduk> I'd like to go back to man pages for a moment; I think I failed to ask a question I meant to.
[15:35:14] <Jeffrey Altman> ok
[15:35:25] <kaduk> In particular, do people have opinions about installing man pages with a glob vs. an explicit list?  (The explicit list makes it easier for packaging to patch the list, if it wants to.)
[15:36:35] <meffie> explicit seems better that implicit
[15:39:19] <stephan.wiesand> +1
[15:43:27] <stephan.wiesand> Anything else to discuss today?
[15:43:32] <Jeffrey Altman> I'm done
[15:43:37] <kaduk> I guess I can go ahead and sketch out a patch for that in gerrit.
[15:43:42] <kaduk> I don't think I have anything else.
[15:43:59] <stephan.wiesand> Thanks a lot everyone!
[15:50:10] stephan.wiesand leaves the room
[16:03:13] deason leaves the room
[16:06:03] meffie leaves the room
[16:33:31] Simon Wilkinson leaves the room
[18:50:37] kaduk leaves the room
[19:47:16] jhutz@jis.mit.edu/owl joins the room
[19:47:20] jhutz@jis.mit.edu/owl leaves the room
[19:47:32] jhutz@jis.mit.edu/owl joins the room