- Thursday, March 10, 2022

release-team@conference.openafs.org

Thursday, March 10, 2022< ^ >

kaduk@jabber.openafs.org/barnowl has set the subject to: openafs release team

Room Configuration

Room Occupants

GMT+0
[16:55:20] <kaduk@jabber.openafs.org/barnowl> I will be delayed, if I can make it at all.
[16:56:09] meffie joins the room
[16:59:13] wiesand joins the room
[16:59:27] <wiesand> Good evening
[16:59:54] <meffie> greetings
[17:02:07] <meffie> i am back at the office now. was away for a camping trip.
[17:02:33] <wiesand> nice
[17:03:39] Cheyenne joins the room
[17:03:49] <Cheyenne> Hello all.
[17:04:23] <meffie> from the scrollback, it looks like ben will not be able to attend today.
[17:07:48] <wiesand> right
[17:09:22] <Cheyenne> Well.. linux-5.17 update.. still getting a clean build with master.  But on a related note, my gcc compiler got upgraded to 11.2 and both master and 1.8.x are "breaking" due to new compiler checks.  The good news is that Meffie has already submitted the patches (though 2 are still pending merging into master)
[17:09:51] <wiesand> sigh
[17:10:04] <meffie> yes those patches are needed for newer versions of gcc
[17:10:20] <Cheyenne> (14770 and 14771).  The topic gcc11-warnings has the 7 patches.  They all pulled in cleanly into 1.8.x
[17:10:46] <meffie> that is, they are needed to remove the warnings.
[17:11:10] <Cheyenne> yes (I build with --enable-checking)
[17:11:23] <meffie> currently, we removed the --enable-checking on fedora
[17:14:08] <meffie> once those two patches are merged, we can reinstate --enable-checking on the buildbot
[17:15:16] <wiesand> that will take a while though
[17:16:11] <meffie> well i can enable-checking on the master branch first
[17:16:34] <meffie> then, when they hit 1.8, enable-checking there too.
[17:21:19] <meffie> i can remind ben we are still waiting for the gcc11-warning patches. i'll rebase them again as well.
[17:21:57] <meffie> on of them is trivial. i think the other is pretty simple.
[17:22:05] <meffie> one of them.
[17:22:33] <Cheyenne> that whole topic was fairly simple
[17:22:45] <meffie> fortunately, yes.
[17:23:07] <wiesand> yet i'm currently working on antirely different stuff
[17:23:14] <wiesand> entirely
[17:24:43] <wiesand> and frankly i'd rather continue with that - if i don't get it finished this eveneing i'll start over from scratch in a couple of days…
[17:25:46] <meffie> the gcc11-warnings topic is very old, i think it can wait...
[17:27:38] <wiesand> not as old as those sweeping LINUX_ENV changes (and what they build upon) - I need these in, cleanly, or stable_1_8_x is a lost cause IMO
[17:28:11] <Cheyenne> Do you need any assistance with those?
[17:28:52] <wiesand> I have to find out ;-) And that alone is a lot of work
[17:31:38] <wiesand> If you want to help me, the 1st thing to do is *always* reviewing changes from https://gerrit.openafs.org/#/q/status:open%20project:openafs%20branch:openafs-stable-1_8_x - preferrably all of them, but especially those which still haven't received a single +1 (or a comment why that wouldn't be appropriate)
[17:33:06] <meffie> project:openafs branch:openafs-stable-1_8_x is:open NOT label:Code-review>=+1,self
[17:33:36] <meffie> oh, i have a few. i'll review them this afternoon, before i get more post vacation stuff to do.
[17:33:59] <kaduk@jabber.openafs.org/barnowl> Hi, somewhat here now.
I will try to prioritize the gcc11-warnings (and also at least the
earlier bits of the apple-silicon one, that apply to new macOS
versions in general)
[17:34:09] <wiesand> post vacation stuff is about as frustrating…
[17:34:34] <meffie> thanks ben!
[17:35:10] <meffie> code reviews are better when i'm relaxed and tan
[17:43:49] <meffie> i have 9 gerrits to review. most of them for fbsd.
[17:45:58] <wiesand> and there's more fbsd on the list, but those have to wait for the sweeping linux stuff
[17:47:08] <wiesand> so next should probably be 14387 after its dependencies - i have 8 files to got to figure those out
[17:47:16] <meffie> can they be ported without the sweeping linux changes? seems those are not meant for the current stable release?
[17:48:23] <wiesand> so far most are trivial (indentation changes), but i bet one of the remaining ones will open a can of worms again - that will be the point where i'll cry for help...
[17:48:44] <meffie> ok
[17:49:27] <wiesand> mike, if we leave those out, we merge another handful (with edits) and then every single pullup will be an actual backport
[17:50:39] <wiesand> thus from my point of view, we take them (and a lot more) or degrade 1.8.x to "security and absoluetely critical bug fixes only"
[17:50:39] <meffie> yes, i figured that's the case since stable is different than master
[17:51:52] <meffie> yeah i guess we are close to that point based on your descriptions here
[17:53:25] <wiesand> i may well be just too dumb to handle it
[17:54:26] <meffie> no, it's very very time consuming. the problem is openafs has a lot of technical debt we are trying to fix on the master branch, it makes it hard to have a stable branch that "trails" that .
[17:55:00] <meffie> imho
[17:56:11] <meffie> the other option is to change the policy to say bug fixes have to go to stable first, but then forward ported to master. but then we risk missing a bug fix on the "next" stable.
[17:56:42] <meffie> but i feel that option should have more consideration :)
[17:58:01] <wiesand> agreed
[18:00:06] <wiesand> for 1.8 it's too late, but we try to do better for the next stable series
[18:00:19] <wiesand> should try
[18:00:23] <meffie> yeah, that sounds like a good idea.
[18:02:07] <meffie> in other news Mark V says he has already got inquires about google summer of code from prospective contributors
[18:02:34] <meffie> since his name is listed on www.openafs.org <http://www.openafs.org> as a mentor
[18:02:35] <wiesand> everybody will have an own point of view how to achieve that...
[18:02:51] <wiesand> good!
[18:03:33] <wiesand> in my perfect world, we'd divide all changes to master into two classes:
[18:04:15] <wiesand> 1) those that can and should (and shall) be consumed on stable swiftly
[18:05:48] <wiesand> 2) anything else - and those should not be merged before we enter a period of getting the next stable series ready (say, 6 months)
[18:06:38] <wiesand> and as soon as we enter that period, the current stable series should be frozen, except for critical stuff
[18:06:39] <Cheyenne> Is there a way that we could flag those (special topic names, etc.)
[18:06:52] <wiesand> "open" ;-)
[18:08:02] <meffie> basically you are saying development moves to github. and releases are done in gerrit ;)
[18:08:20] <wiesand> take it as food for thought please - i'm sure some will deeply dislike the idea
[18:08:39] <meffie> i dont dislike it at all.
[18:09:10] <Cheyenne> not a problem from me
[18:09:16] <meffie> it seems to make sense to me.
[18:10:45] <meffie> but some people do run the current master (like me) i build and run it every day. if we have to pull it from somewhere else, i dont mind.
[18:11:44] <meffie> what ever you think makes sense, we can help you
[18:12:11] <wiesand> if that works fine, we have the other option: cut stable releases much more frequently
[18:12:22] <meffie> yes
[18:12:54] <meffie> or just get rid of the idea of alternating stable/devel releases, like linux did.
[18:13:23] <wiesand> but that adds other questions… say we'd head for a 1.10 within a few monts
[18:13:57] <wiesand> what would we do about rxgk? leave it in as is? rip it out? disable it?
[18:14:24] <meffie> i thought the point was to leave it in so it can be used
[18:15:02] <meffie> even if it is only for server to server connections
[18:15:37] <wiesand> why haven't we pulled it up to stable then? that sure would have made things easier
[18:17:01] <meffie> i assume because it was just going to be in the next release on the branch it is already in?
[18:21:07] <wiesand> i was told, literally, that it was supposed to "break master for a while"
[18:22:08] <meffie> hmm.
[18:22:30] <meffie> well, not sure what that means.
[18:22:40] <kaduk@jabber.openafs.org/barnowl> That might have referred to a scenario where we merge stuff on master
that is functional in its own right for a new install, but would break
an existing server deployment if you install it on top of a released
version
[18:24:13] <meffie> ah, yes, there could be some extra steps when upgrading.
[18:24:21] <wiesand> maybe - also note this was many years ago…
[18:25:17] <meffie> i normally dont upgrade 1.8.x to master, but even going from 1.6.x to 1.8.x there were some small things to look out for.
[18:26:17] <meffie> ok, motion to adjourn?
[18:27:04] <wiesand> sustained - thanks for the discussion
[18:27:32] <Cheyenne> Sounds good.  Have a safe week everyone
[18:27:50] <kaduk@jabber.openafs.org/barnowl> Yes, thanks everyone.  Sorry for not really being present.
[18:27:59] <meffie> you are welcome, have a good day/evening all.  oh, and i forgot, i think we change to daylight savings this weekend in the U.S.A. ?
[18:28:41] <wiesand> thanks for the reminder -  as usual, let's keep the local time the same for us folks?
[18:28:58] <meffie> ok, thanks
[18:29:06] <Cheyenne> ::sigh:: Dr. Franklin and his attempt at saving tallow candles..   -- :)
[18:29:24] <wiesand> thanks for the reminder
[18:30:57] <wiesand> as usual, let's keep the (local) time slot the same for us folks?
[18:31:13] <Cheyenne> fine with me
[18:31:37] <wiesand> (experiencing bad delays here, and it's not my internet connection)
[18:32:12] <wiesand> U.S. folks, of course
[18:33:32] <wiesand> CU next week then
[18:36:15] wiesand leaves the room
[18:43:29] meffie leaves the room
[19:57:51] mvitale leaves the room: Replaced by new connection
[19:58:24] mvitale joins the room