Home
release-team@conference.openafs.org
Friday, December 29, 2017< ^ >
Room Configuration
Room Occupants

GMT+0
[14:01:24] wiesand joins the room
[14:01:41] meffie joins the room
[14:01:50] <wiesand> Hello
[14:02:04] <meffie> good day
[14:02:58] <wiesand> I had a weird idea
[14:03:12] <meffie> ok
[14:03:53] <wiesand> How about a 1.6.22.2 release with:
[14:04:01] <wiesand> 1. high sierra support
[14:04:10] <wiesand> 2. linux 4.15 support
[14:04:18] <wiesand> 3. the specfile changes
[14:04:38] <wiesand> 4. el7.4 getcwd (shakeloose refactor)
[14:04:43] <wiesand> [end of lis]
[14:05:36] <meffie> i thought we wanted to do a prerelease for 4 ?
[14:05:44] <wiesand> This could be finished well in time for Linux 4.15
[14:06:29] <meffie> but, yes that sounds like a great idea.
[14:07:07] <wiesand> We wouldn't force the shakeloose changes on anyone except those who live on the bleeding edge anyway
[14:08:01] <meffie> ?
[14:09:06] <meffie> i dont think those patches check for kernel versions.
[14:09:07] <wiesand> No point in installing that .2 release anywhere, except on Linux 4.15 or EL7.4 clients.
[14:09:16] <meffie> ah.
[14:09:25] <wiesand> sorry for being fuzzy
[14:09:42] <wiesand> EL7.4 admins will want tor try it.
[14:10:02] <meffie> ah, i see. yes, then it's sort of a pre release, yes
[14:10:17] <meffie> that sounds good.
[14:10:20] <wiesand> And who's running 4.15 so early should be used to some churn ;-)
[14:10:56] <meffie> yes
[14:11:13] <wiesand> exactly, a "prerelease" likely to acctually get public testing
[14:11:30] <meffie> sad, but true.
[14:12:14] <wiesand> Of course we should be reasonably sure that the shakeloose changes won't cause serious new issues.
[14:12:28] <meffie> ben recently pushed 12830, and andrew was able to review it yesterday and give it a +1
[14:12:31] <wiesand> And a prominent note in the release notes seems justified too.
[14:12:46] <wiesand> Yes, looks like we're getting close.
[14:14:30] <wiesand> And then we could swiftly issue a 1.6.23pre1 with the other changes in the queue, including some making me a bit nervous
[14:15:25] <wiesand> That would give us ~7 weeks prerelease time (before we have to release something to support Linux 4.16)
[14:15:43] <meffie> ok
[14:16:14] <wiesand> Whereas a 23pre1 next week would give us… ~2
[14:16:54] <wiesand> We don't have to decide on this today, but I think it's worth considering.
[14:18:17] <meffie> it seems, you really want a 1.6.22.2 with only the getcwd() changes, the other 3 things you mentioned could wait until 1.6.23pre1 ?
[14:18:42] <meffie> sorry getcwd() + 4.15
[14:19:00] <meffie> so just changes for recent linux and rhel.
[14:19:07] <wiesand> highsierra is completely orthogonal, and the spec changes are fairly
[14:19:48] <meffie> yes, i understand, they dont add risk, but the are orthogonal, so dont need to be in the point release.
[14:20:22] <meffie> just to make the release notes easier and for people to understand this is for recent linux changes.
[14:20:23] <wiesand> but why not include them? they're ready, and they fit what we general ship in these releases
[14:21:28] <meffie> yes, that is true.
[14:21:55] <wiesand> and I hate having acinclude.m4 changes in the queue…
[14:22:06] <meffie> ?
[14:22:27] <meffie> what's wrong with having acinclude.m4 changes?
[14:23:44] <wiesand> nothing with those themselves, but with them lingering around for weeks or months before they're merged
[14:25:02] <meffie> ah, i see. yes. well, to me that no different than any change lingering. the fact they happen to be in the same file is of no consequence, is it?
[14:25:37] <wiesand> not if that is taken into account when they're pulled up
[14:25:46] <wiesand> but that's not what usually happens
[14:26:57] <meffie> it's not?
[14:27:47] <wiesand> no
[14:28:58] <meffie> oh, sorry. i guess it's because we dont merge changes. but i agree it's nicer to have a linear history.
[14:29:20] <wiesand> the way the Linux-4.15 and highsierra stacks are lined up on the 1.6 branch now will allow me to just submit them
[14:30:00] <wiesand> but if I merge Linux-4.15 first, highsierra needs a rebase
[14:30:23] <meffie> why would you merge them out of the branch order?
[14:30:23] <wiesand> no big deal…
[14:30:42] <wiesand> you just suggested doing that ;-)
[14:30:48] <meffie> seems like they are based correctly now, and need to be apply in order.
[14:31:17] <meffie> oh, i'd just rebase them first then merge them.
[14:31:18] <wiesand> yes, which means that we either ship highsierra in .2 or rebase it
[14:31:33] <wiesand> rebasing usually is not a problem
[14:31:53] <meffie> correct, i guess i rebase all the time, since we want to have a linear order.
[14:32:28] <meffie> but yes, it does make for more work. not just for acinclude, for any change really.
[14:32:31] <wiesand> but according to murphy's law it typically becomes necessary when there's not much time and at least one buildbot slave is down or buildbot queues are clogged with other stuff
[14:32:55] <meffie> ah! good point!
[14:34:15] <meffie> i think last year i was looking at dividing up acinclude into smaller files, but i'm not sure that would really help, since we normally change the 'linux' parts. it would have helped in this case though.
[14:35:33] <meffie> the idea was to move more parts of it to cf/m4/
[14:35:46] <wiesand> rebase == revalidate, that's the actual issue
[14:36:26] <wiesand> and not just regarding buildbot, I also don't merge anything I haven't actually run on my systems (exception: db servers)
[14:37:27] <meffie> i see, ok, i understand now. sorry for being dense.
[14:37:41] <wiesand> so that's why I prefer avoiding rebases
[14:38:57] <meffie> yes, i see. it's the retesting part after it's been pushed to gerrit.
[14:39:38] <meffie> thank you for explaining.
[14:40:15] <wiesand> right (and with the new gerrit you can even rebase changes with two clicks, no need to even push, so that's not the issue)
[14:41:37] <meffie> ah, ok.
[14:42:06] <meffie> well, i still like our way better than github workflows :)
[14:42:07] <wiesand> So for 1.6.23, you want the ubik stuff, and probably the libafs changes from summer?
[14:42:34] <wiesand> so do I ;)
[14:42:34] <meffie> the ubik stuff, yes. i dont remember the other changes
[14:43:05] <wiesand> 12684..7
[14:43:18] <wiesand> 12667
[14:44:04] <wiesand> and I have a few trivial ones on the list
[14:44:28] <wiesand> 12645..6
[14:44:36] <wiesand> 12666
[14:44:49] <wiesand> 12643
[14:45:16] <wiesand> settled hint: all of those lack review…
[14:45:22] <meffie> ah, ok, i will need to re-read all of these :)
[14:45:51] <wiesand> that's another problem with changes lingering for too long
[14:46:06] <meffie> yes.
[14:46:15] <wiesand> shame on me
[14:46:27] <meffie> no, not shame on you.
[14:47:06] <meffie> at least we have a new year to start fresh and fixes to review and deliver :)
[14:47:23] <wiesand> right
[14:47:56] <wiesand> let's try to get rid of the backlog with a reasonably long prerelease phase for 1.6.23
[14:48:26] <wiesand> immediately after 1.6.22.2
[14:49:29] <wiesand> So we have "gute Vorsätze" for the new year
[14:49:31] <meffie> yes, some things may be blocked on 1.8.0, and maybe would be not pulled down to 1.6.x if they are "features"
[14:50:55] <meffie> yes, new year resolutions!
[14:51:23] <wiesand> you mean there are changes in  the 1.6 queue not yet merged on 1.8?
[14:52:13] <meffie> i mean some things that may go in 1.8.x maybe dont need to be in 1.6.x
[14:52:29] <wiesand> ah, yes of course
[14:52:37] <meffie> but i dont have any specific examples.
[14:53:12] <meffie> i wonder if there is a way in gerrit to show that.
[14:53:27] <wiesand> I don't think so
[14:55:31] <meffie> ok
[14:55:58] <meffie> i'll list the gerrits you have listed here in the meeting notes at least.
[14:56:26] <wiesand> Thanks. That may help them get some attention...
[14:56:46] <meffie> excellent.
[14:57:11] <meffie> ok, i need coffee (today is technically a holiday here)
[14:57:27] <wiesand> Thanks a lot for being here anyway!
[14:57:53] <wiesand> Happy new year!
[14:57:57] <meffie> you are welcome. i'm excited to attack the backlog in 2018.
[14:58:08] <meffie> happy new year.
[14:58:22] wiesand leaves the room
[14:58:31] meffie leaves the room