- Friday, June 1, 2018

release-team@conference.openafs.org

Friday, June 1, 2018< ^ >

Room Configuration

Room Occupants

GMT+0
[11:55:36] Marcio Barbosa joins the room
[13:03:21] <kaduk@jabber.openafs.org/barnowl> greetings
[13:03:40] <kaduk@jabber.openafs.org/barnowl> Did Europe go on DST and I lost track of it?
[13:05:32] wiesand joins the room
[13:05:55] <wiesand> no, it's just me being ate again - sorry!
[13:06:07] mvita joins the room
[13:06:24] <kaduk@jabber.openafs.org/barnowl> No worries -- more time to ponder over this code review :)
[13:06:28] <mvita> Hello
[13:06:42] meffie joins the room
[13:06:46] <wiesand> hello
[13:06:53] <meffie> good day
[13:06:55] <wiesand> ben: which one? ;-)
[13:07:05] <kaduk@jabber.openafs.org/barnowl> the last one of dslot-eintr
[13:07:10] <meffie> (sorry for tartiness)
[13:07:25] <kaduk@jabber.openafs.org/barnowl> though I could imagine someone arguing that something else is higher
priority, I suppose
[13:08:14] <wiesand> ah, master…
[13:08:27] <wiesand> I had my mind set on 1.8 lately
[13:08:46] <kaduk@jabber.openafs.org/barnowl> quite understandable, and I arguably should as well.
[13:08:50] <wiesand> (decided to prioritize those pullups over 1.6.23pre1)
[13:09:05] <kaduk@jabber.openafs.org/barnowl> thank you for that!
[13:09:20] <wiesand> but for the time being I think I've pulled up whatever could possibly make sense
[13:10:02] <wiesand> we also had a lot of review already by Mike, Mark, Andrew -  Thanks!
[13:10:06] <kaduk@jabber.openafs.org/barnowl> Okay.  So I should still be thinking about whether it is appropriate
for 1.8.1 when looking at them
[13:10:41] <wiesand> I think they're all appropriate.
[13:11:18] <kaduk@jabber.openafs.org/barnowl> Okay, noted :)
[13:11:38] <wiesand> Reduce skew as much as possible, get the new code into production use, avoid backlogs (like the current one)
[13:12:22] <wiesand> I mainly left out stuff touching the rxgk tree.
[13:12:48] <wiesand> But even if the subject is "export … for rxgk", why not take ti.
[13:13:53] <kaduk@jabber.openafs.org/barnowl> Fair enough
[13:14:04] <wiesand> But feel free to -2 whatever you consider nonsense.
[13:14:13] <kaduk@jabber.openafs.org/barnowl> I always do :)
[13:14:23] <wiesand> There are quite a few potential path conflicts.
[13:14:32] <meffie> another benefit; you can remember the patches since it hasnt been 3 years since they were reviewed for master :)
[13:14:58] <kaduk@jabber.openafs.org/barnowl> indeed
[13:15:01] <wiesand> I tried to keep stacks reasonable short and on topic. But order matters.
[13:15:08] <meffie> that is when reviewing them for 1.8.x. at least that's what i've found this week.
[13:15:09] <wiesand> Mike: exactly
[13:15:30] <kaduk@jabber.openafs.org/barnowl> Hopefully I will correctly interpret the gerrit "related changes"
column to figure out which order to go in.
[13:15:43] <meffie> i was wondering how you maintain the ordering of the commits?
[13:16:04] <wiesand> hang on
[13:17:04] <kaduk@jabber.openafs.org/barnowl> If I was going to be stuck doing the pullups, I would have just
grabbed one long chain, in the order they appeared on master.  But
Stephan can tell us what actually was done...
[13:17:24] <wiesand> https://www-zeuthen.desy.de/~wiesand/181-notes.txt
[13:18:31] <meffie> please tell me that's autogenerated from git :) oh my
[13:18:42] <wiesand> no it isn't
[13:18:57] <kaduk@jabber.openafs.org/barnowl> Are the stacks in "apply from top to bottom" order or the other way?
[13:18:59] <mvita> :-D
[13:19:52] <wiesand> they should be independent of each other, unless there's some "*** NEEDS" comment
[13:20:16] <kaduk@jabber.openafs.org/barnowl> I mean within a given stack
[13:20:28] <wiesand> iobviously, "lowest gerit first" is the safest route
[13:20:39] <kaduk@jabber.openafs.org/barnowl> Ah, of course.  I should have thought of that :)
[13:21:16] <wiesand> there are expections where things got rebased
[13:22:00] <kaduk@jabber.openafs.org/barnowl> sure
[13:22:13] <wiesand> hover over the "parent" field in gerrit - if that wasn't merged yet you probably want to do that first
[13:22:14] <kaduk@jabber.openafs.org/barnowl> But the numbers are enough to calibrate which direction the axis goes
[13:24:13] <wiesand> That's as convenient as it gets. unless anyone has a brilliant idea how to it better.
[13:24:55] <wiesand> Of course avoiding backlogs as much as possible would be best.
[13:25:01] <kaduk@jabber.openafs.org/barnowl> Sometimes I think that the "related changes" and/or "same topic" in
the right sidebar gets ordered in commit order, and other times I am
less sure.
[13:25:20] <wiesand> Not sure either.
[13:26:23] <meffie> i thought the gerrit doc says "related changes" are in git parent/child order.
[13:26:48] <meffie> i
[13:26:51] <meffie> i
[13:27:00] <meffie> ive nevered noted a case it wasnt
[13:27:45] <kaduk@jabber.openafs.org/barnowl> I think my lack of confidence is mostly due to how the set of changes
listed as related can change as you try to iterate down the list.
[13:28:02] <mvita> yes, that always throws me too
[13:28:54] <meffie> ah, yes, it's not really a topic branch, true.
[13:29:09] <wiesand> My manul "changes to file lists are ordered ;-)
[13:29:35] <kaduk@jabber.openafs.org/barnowl> Oh, they're certainly *ordered*.  We just want to know what ordering
function is being used :)
[13:29:40] <meffie> lol
[13:30:15] <wiesand> like "merge 13092 before 13107, or you get to rebase 13092 and everything on top"
[13:30:25] <meffie> what if way make a rule that gerrit topics must be assigned on actual git topics?
[13:30:44] <wiesand> what's a git topic?
[13:30:49] <meffie> instead of a random order
[13:31:10] <kaduk@jabber.openafs.org/barnowl> You mean, if I push a stack of more than one change to gerrit, I must
use a unique gerrit topic?
[13:31:18] <meffie> i mean a local, short lived git topic branch
[13:31:24] <meffie> yeah
[13:31:27] <kaduk@jabber.openafs.org/barnowl> (and the same gerrit topic should not be used for commits that are not
in a linear parent/child relationship)
[13:31:47] <kaduk@jabber.openafs.org/barnowl> That's probably a good habit to be in, but I don't actually know how
to enforce it, offhand.
[13:31:54] <meffie> that's how people generally organize their topics anyway
[13:32:21] <wiesand> it does happen that fairly unrelated changes are in the middle of a gerrit topic
[13:32:31] <meffie> correct, it would have to be a working rule, if you will, gerrit would not force this.
[13:32:33] <wiesand> and yes, avoiding that would help
[13:33:01] <meffie> but it would be fairly obvious to check i think.
[13:33:13] <kaduk@jabber.openafs.org/barnowl> I would think so, yeah.
[13:33:44] <wiesand> still, in the presence of backlogs, you'd need a second rule: "a topic is merged completely in rapid succession, or not at all" to make it really useful
[13:33:48] <mvita> you couldn't enforce it in gerrit, it knows nothing about your local git topic branch
[13:34:21] <kaduk@jabber.openafs.org/barnowl> I try to do that "merge all in one go", though it doesn't always work
out.
[13:34:22] <meffie> correct, but it's a convention we could adopt.
[13:34:52] <mvita> right, a convention
[13:34:55] <kaduk@jabber.openafs.org/barnowl> Supposedly gerrit has the ability to actually merge a chunk of changes
all in one go, but I think we either don't enable it or are on too old
a version -- I've never seen a button appear that looks like it would
do so.
[13:35:04] <meffie> yeah, it makes sense to merge them all at once i feel, if not, then send it back for rebase and review?
[13:35:45] <wiesand> NB why is 12270 in the ubik_perf topic?
[13:36:11] <kaduk@jabber.openafs.org/barnowl> I guess sometimes failing to merge in one go is because the first one
needs a rebase, but I only rebase one at a time, so then the second
one also needs a rebase, and I'm too impatient to block on buildbot.
[13:37:36] <meffie> 12270 is needed for ubik_perf because it fixes HAVE_PIO which is needed for the pread/pwrite stuff in those patches
[13:37:57] <wiesand> Ah, thanks
[13:39:01] <meffie> no problem, yes it is unfortunate and a bit confusing.
[13:39:01] <wiesand> Also, a nice source of path conflicts are those sweeping changes changing dozns of files across the whole tree. Breaking those up would help too.
[13:39:39] <kaduk@jabber.openafs.org/barnowl> I have avoided needing to mention this to Pat, though, because his
sweeps are mostly only touching files that are generally unloved.
[13:41:58] <wiesand> Yes, they weren't too bad this time around. But potentially they can cause lots of overhead especially when lingering waiting for review for too long.
[13:42:34] <kaduk@jabber.openafs.org/barnowl> Yup.
[13:43:05] <kaduk@jabber.openafs.org/barnowl> On a somewhat different note (not entirely sure where in the agenda we
are), writing up the list of 1.8.1 changes for -info rather made it
sink in that a 1.8.1pre1 seems appropriate.
[13:44:22] <kaduk@jabber.openafs.org/barnowl> (right?)
[13:44:59] <meffie> yes?
[13:45:54] <meffie> sorry, i've not been sending notes this month. (but those go to -devel). well do for today,
[13:46:24] <wiesand> maybe a 1.8.0.1 fixing the pressing issues would make sense? before getting rid of the backlog for 1.8.1pre?
[13:47:11] <kaduk@jabber.openafs.org/barnowl> I think the pressing-issues fixes qualify for 1.8.1pre1 in their own
right.  Though maybe you are right about holding off on the backlog.
[13:47:21] <meffie> seems we have the critical things now for a new 1.8.x since mark found that bug last week.
[13:47:47] <kaduk@jabber.openafs.org/barnowl> I think so.
[13:48:04] <kaduk@jabber.openafs.org/barnowl> And I looked at the libafsrpc exports last night, too -- that was much
less work that libafsauthent.
[13:48:31] <kaduk@jabber.openafs.org/barnowl> (Especially since we have commented-out RXAFS and RXAFSCB entries in
afsrpc.def from a commit that helps make it clear what the point of
the library is.)
[13:48:42] <mvita> I'm reworking 13075 (for master) today - when merged that should go to 1.8.1 too
[13:48:54] <mvita> should/could
[13:49:13] <kaduk@jabber.openafs.org/barnowl> Ah.
[13:49:20] <kaduk@jabber.openafs.org/barnowl> It's kind of sad, the state of some of the xdr code...
[13:50:23] <mvita> it's a time capsule, for sure
[13:50:41] <wiesand> A 1.8.1pre1 now postponing the backlog will make things much worse.  Unless you freeze master until that's addressed. Which causes more backlog on master or Mike's github ;-)
[13:51:53] <wiesand> Again: producing new code at a much higher pace than it can be consumed isn't helpful.
[13:51:54] <meffie> lol
[13:52:08] <meffie> lol about the github
[13:54:18] <wiesand> Arguably, we should close down gerrit for submission to master until everything still open for master is either merged or abandoned or postponed for a good reason and an according comment.
[13:54:31] <meffie> we'll try to focus on reviews more than new patches
[13:55:14] <meffie> we may have some more help with that soon, btw
[13:55:20] <wiesand> Sorry, that sounded a bit harsher than I intended, probably.
[13:55:43] <wiesand> But my feeling is that lately the balance indeed wasn't quite right.
[13:56:23] <meffie> no, it makes sense. i suppose its more important to have more things finished that more things started.
[13:56:33] <meffie> s/that/than/
[13:56:37] <mvita> many of the recent patches have been fixes for 1.8.x , not new things
[13:57:02] <meffie> true.
[13:57:14] <wiesand> still, they're coming in faster than we can process them
[13:57:42] <wiesand> that, of course is the result of 1.8 being years late
[13:58:13] <meffie> as ben once told me, we can still be happy it's done now :)
[13:59:13] <kaduk@jabber.openafs.org/barnowl> I am worried that I am being the bottleneck in terms of reviewing new
changes coming in, though :-/
[13:59:16] <wiesand> and I am
[14:00:21] <wiesand> Ben: of course you are ;-) It's not at all your fault though.
[14:00:32] <mvita> <pondering>
[14:02:02] <mvita> We do have 2 stable releases now - similar to when 1.6.x was new and 1.4.x was reaching end of life
[14:02:15] <mvita> things are bound to be hectic at this stage
[14:02:33] <kaduk@jabber.openafs.org/barnowl> I suppose so.
[14:02:57] <mvita> we can't stop finding and fixing 1.8.x bugs, but maybe there are other areas in the process where we can adjust
[14:02:58] <kaduk@jabber.openafs.org/barnowl> btw, Mike, I just left a review on 13034 with a question, if you want
to look at that.  (I don't necessarily expect you to have an answer,
of course.)
[14:03:07] <wiesand> 1.4 was pretty much abandoned in the 1.6.0pre phase
[14:03:35] <mvita> that's not how I remember it
[14:04:02] <wiesand> the last few releases were off the 1.4.12.1 branch (or so)
[14:04:23] <mvita> 1.4.x had to go on for years due to problems and slow uptake of 1.6.x
[14:04:26] <wiesand> whatever was queued for 1.4.13+ on 1.4.x never made it out
[14:05:21] <wiesand> we issued security releases until  ~ 1 year after 1.6.x was proclaimed more stable than 1.4
[14:05:38] <kaduk@jabber.openafs.org/barnowl> I remember strange branch gymnastics happening on 1.4.x around the
rxkad-k5 time
[14:06:04] <kaduk@jabber.openafs.org/barnowl> Like, noticing patches that had been on 1.4.12.x but not on 1.4.x
proper or 1.4.15, or something like that.
[14:06:29] <mvita> yes, sorry I'm writing 1.4.x but I mean 1.4.*
[14:06:54] <wiesand> When I took on the release manager role during the early 1.6 days, Daria said that 1.4 was already hopeless.
[14:09:19] <wiesand> But yes, we're at 1.8.0. Things are hectic as production use is taking off. But that wasn't unexpected, was it?
[14:10:06] <mvita> no, not unexpected.
[14:10:29] <meffie> maybe "active" would be a more positive spin :)
[14:10:58] <mvita> I'm trying to understand what we should do to make the process better for you and the project
[14:11:00] <wiesand> "interesting"? "challenging"?
[14:11:21] <mvita> the rate of new 1.8.x bugs is out of our control
[14:11:43] <mvita> so what things _can_ we control?
[14:12:34] <meffie> new features can be put off.
[14:12:50] <kaduk@jabber.openafs.org/barnowl> The quality of the code we write, and the pace at which we try to put
in new features, yeah.
[14:13:43] <meffie> better communication and tooling use? e.g. git topic branches -> gerrit topics ?
[14:15:57] <wiesand> Help avoid backlogs. The easiest way to do that is review review review.
[14:16:51] <wiesand> And of course clone Ben, me and yourself…
[14:16:59] <wiesand> It's as simple as that...
[14:17:07] <kaduk@jabber.openafs.org/barnowl> we'll get right on that...
[14:17:37] <meffie> avoiding backlogs also implies we really should not have a "development branch", which is probably true since no one actually runs the "master" branch.
[14:17:54] <mvita> we didn't do our normal review stint yesterday due to another project getting started
[14:17:58] <meffie> or i'm i thinking about this wrong?
[14:19:16] <kaduk@jabber.openafs.org/barnowl> Well, we need someplace to land features that are destined for
$next_major_release
[14:19:27] <mvita> ^
[14:19:34] <wiesand> well, the review on master is needed (at least extremely useful), as is buildbot testing there (including the linux-rc thing)
[14:19:42] <meffie> ah, yes, and wiesand did say the rxgk stuff was excluded.
[14:20:06] <wiesand> rxgk is not for 1.8
[14:20:26] <meffie> yes, ok, thanks, just trying to get my head around this. ok, thanks.
[14:20:33] <wiesand> pretty much everything else shouldn't spend years on master before the 2.0 release IMHO
[14:21:08] <meffie> agreed
[14:21:36] <kaduk@jabber.openafs.org/barnowl> We could also do 1.5.x-style 1.9.x development releases with rxgk
technology preview
[14:21:44] <wiesand> which is why I pulled up almost everything merged on master after 1.8.0 to 1.8.x
[14:22:58] <meffie> thank, you, I've been reviewing those. i'll encourage others to do the same.
[14:23:09] <kaduk@jabber.openafs.org/barnowl> Thanks!
[14:25:25] <wiesand> I think the processes are fundamentally right, we should just adjust a bit how we live them. A bit more "agile" than in the past.
[14:25:29] <meffie> so, what should i put in the notes? :)
[14:26:54] <mvita> good question
[14:27:26] <meffie> i'll list the gerrits and say please review :)
[14:27:36] <mvita> you could cut and paste this log
[14:28:02] <meffie> i normally do a summary of the log, and point to the url.
[14:28:07] <wiesand> Whatever you took away here. If it's way off,  it should at least spark a discussion ;-)
[14:28:25] <wiesand> Don't list the gerrits! :_)
[14:28:33] <meffie> ?
[14:28:44] <meffie> why not?
[14:29:05] <meffie> i'm mean, list them after the summary?
[14:30:17] <wiesand> https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_8_x should suffice and isn't nearly as scary
[14:30:59] <wiesand> and btw there's at least one change in 1_6_x that could be reviewed too
[14:32:05] <meffie> ok
[14:33:30] <meffie> it's easier for me to just run 'git gerrit-query' to list them, but i can put the url instead if you prefer
[14:34:18] <meffie> it makes more sense to list the topics in the summary than a huge list of commits actually.
[14:34:37] <meffie> (now that i'm looking at that long list)
[14:35:34] <meffie> i'll grab that from your notes for now.
[14:35:40] <wiesand> I wasn't super-serious here. But yes the list *is* ling, and I think such a list in the notes will scare some folks away after a glance without having read the notes at all.
[14:36:04] <meffie> or they could say, hey openafs is really active now :)
[14:36:27] <wiesand> They'll still find that out after clicking the link ;-)
[14:37:01] <meffie> but for a summary, we dont need to actually see every commit though. it make more sense to show the types of things changing and why in a summary.
[14:37:43] <meffie> right?
[14:37:50] <wiesand> ight
[14:38:05] <kaduk@jabber.openafs.org/barnowl> seems so
[14:38:12] <wiesand> (there's some dirt under my 'r' key)
[14:39:13] <meffie> i'll try to do the same for 1.6.x too.
[14:39:47] <wiesand> Do we have a strategy now whether we do 1.8.1pre with or without including (most of) the backlog or  a 1.8.0.1 next?
[14:40:24] <meffie> i feel a 1.8.0.1 is kind of confusing
[14:40:42] <wiesand> Mike: 1.6.x is pretty clean at this stage. It's most;y "how about ctf?"
[14:41:47] <meffie> ok, the issue with "ctf" is we really need to add that to the userspace stuff too, and we dont want to make so many changes to all the makefiles.
[14:41:53] <kaduk@jabber.openafs.org/barnowl> IMO a 1.8.0.1 would be for OS support
[14:42:02] <kaduk@jabber.openafs.org/barnowl> s/would be/would be expected to be/
[14:43:48] <meffie> so, i feel the "ctf" patches we have now should not block 1.6.x. they are really for debugging, and just for solaris/bsd
[14:44:21] <meffie> marcio may feel more strongly since he is on the hook for them :)
[14:44:55] <wiesand> ok
[14:45:39] <wiesand> I hope to find some time for 1.6.23pre1 during the weekend, and will neglect ctf.
[14:46:12] <wiesand> the other one bothering me is 13132
[14:46:39] <wiesand> yes, I wouldn't want it in a 1.6. prerelease before it's even merged on 1.8
[14:48:28] <meffie> ok, thanks.
[14:48:44] <wiesand> the rest is redhat spec (I can handle that), NEWS (I may ask for help) and routine
[14:49:12] <kaduk@jabber.openafs.org/barnowl> I hope to find some time for 1.8.next during the weekend as well.
[14:49:27] <meffie> thanks for giving the 1.6.x disposition; i'll do my best to summarize in the notes.
[14:51:01] <wiesand> Some good news: My private, potentially live-changing P1 project will come to a conclusion next Tuesday, one way or the other.
[14:52:13] <wiesand> That will free one of the ~5 slots a human being has available for different topics.
[14:53:14] <meffie> Great news.
[14:53:42] <meffie> sounds super stressful :(
[14:54:48] <wiesand> It's probably the biggest decision I'll ever take.
[14:55:20] <kaduk@jabber.openafs.org/barnowl> It does sound super-stressful, yes.  I hope not dangerously so.
[14:56:13] <wiesand> No no. It just made me spend all available time on gathering the facts. And pondering…
[14:57:42] <meffie> well, very best of luck, we wish you success.
[14:57:44] <wiesand> The 1.8. backlog is at least partly a consequence.
[14:58:23] <wiesand> Thanks.
[14:58:40] <wiesand> And the 1.6.23pre1 delay is too.
[14:59:05] <meffie> (i was irrationally happy to see the /vicepbogus patches in the 1.8.x gerrits ;)
[15:00:04] <meffie> anything else today?
[15:00:27] <wiesand> Those in particular seem "appropriate" to me. I think they're even appropriate for 1.6, even at his stage.
[15:00:40] <wiesand> I don't have anything else. Anyone?
[15:01:18] <wiesand> If not, let's adjourn. Thanks a lot everyone!
[15:01:32] <meffie> thanks, have a good weekend.
[15:01:32] <kaduk@jabber.openafs.org/barnowl> I have nothing else, either.  Thanks everyone!
[15:02:03] meffie leaves the room
[15:02:09] wiesand leaves the room
[15:52:50] meffie joins the room
[15:57:04] meffie leaves the room
[17:33:32] mvita leaves the room
[18:13:57] meffie joins the room
[19:37:45] mvita joins the room
[21:18:37] meffie leaves the room
[22:22:26] Marcio Barbosa leaves the room
[23:44:28] mvita leaves the room