Home
release-team@conference.openafs.org
Friday, April 23, 2021< ^ >
kaduk@jabber.openafs.org/barnowl has set the subject to: openafs release team
Room Configuration
Room Occupants

GMT+0
[12:01:51] mbarbosa joins the room
[13:35:23] mbarbosa leaves the room
[13:36:40] mbarbosa joins the room
[13:43:34] Cheyenne joins the room
[15:51:04] wiesand joins the room
[15:59:02] yadayada joins the room
[16:00:06] <kaduk@jabber.openafs.org/barnowl> Greetings!
[16:00:23] <Cheyenne> Greetings
[16:00:36] <yadayada> hi all
[16:01:19] meffie joins the room
[16:01:23] <meffie> hi
[16:01:28] <wiesand> Hello.
[16:03:27] <mvita2> present
[16:04:16] <wiesand> No visible progress the past week again. I did quite a bit of work, alas it was all fruitless.
[16:04:44] <kaduk@jabber.openafs.org/barnowl> trying to figure out how to backport things without conflicts?
[16:04:55] <meffie> i just worked on documenation, wiki.openafs.org and ansible-openafs docs
[16:05:36] <wiesand> Or at least w/o too many conflicts, and in particular w/o making things even worse. It's utterly frustrating.
[16:05:52] <wiesand> Stuck in code skew hell…
[16:06:06] <kaduk@jabber.openafs.org/barnowl> I guess we should get cracking on this 2.0 thing, then...
[16:06:19] <meffie> heh
[16:06:45] <meffie> backports is an art form
[16:07:16] <wiesand> And none I'm particularly skilled in
[16:09:03] <meffie> i dont think anyone is, it is hard.
[16:09:36] <wiesand> Last friday, after the meeting, I took a stab at 14589, 14594, 10831 (which is on the wish list). Turns out there are quite a few more changes in this area on master, many of which are easy to pull up. Alas, some aren't, and it's a can of worms.
[16:10:54] <mvita2> looking
[16:12:11] <kaduk@jabber.openafs.org/barnowl> I think sometimes we try to be clever by splitting something into a
"minimal change that's easy to backport" and then a "broader
restructuring for long-term maintainability".  But that doesn't help
much when the "minimal change" is already on top of some other
"broader restructuring" so it no longer matches up with the stable
branch.
(Not sure if that's what's happening here or not, of course.)
[16:12:29] <wiesand> That's as far as I got, then it was too late and I too tired. After the weekend (which I tend to really need for private stuff lately), there's monday/tuesday, and when I could recommence, I move it out ot friday. Of course on friday I don't get it quite done before the meeting either, partially because it's been days since I last dealt with openafs and I basically have to start all over again. Rinse, repeat.
[16:13:03] <meffie> i think we do try to separate patches like that, as best we can.
[16:14:02] <meffie> it's not always possible to just cherry pick patches between branches.
[16:14:15] <wiesand> And yes it makes sense. We're just failing to get those "broader restructuring" changes back into stable. Due to lack of resources, and maybe courage.
[16:14:46] <meffie> well, normally you dont want structuring changes in the old branch, right?
[16:14:58] <wiesand> And over the years, with every "little" change pulled up out of order, code skew gets worse and worse.
[16:16:02] <meffie> maybe we just need to make different patches for the branches, when submitting a fix?
[16:16:19] <wiesand> It depends. If we had a stable release every 18 months and we could basically freeze the old stable and retire it eventually, that would be the case.
[16:16:33] <wiesand> Mm, no.
[16:18:12] <kaduk@jabber.openafs.org/barnowl> Yeah, it's hard for us to just say "this feature won't get backported
to stable [because there is too much churn/skew" because then it won't
be in a stable release for 5 years
[16:18:13] <wiesand> I wonder wether there's a chance to move the meeting to a different day of the week?
[16:18:30] <kaduk@jabber.openafs.org/barnowl> I'm open to changing the meeting day
[16:18:40] <Cheyenne> fine with me
[16:18:45] <mvita2> fine with me too
[16:18:54] <wiesand> How about thursday?
[16:19:08] <meffie> sounds good to me!
[16:19:20] <mvita2> yup
[16:19:26] <mvita2> same time?
[16:19:26] <Cheyenne> okay with me
[16:20:06] <yadayada> ok with me
[16:20:38] <meffie> (that would also help me get the notes done)
[16:21:33] <kaduk@jabber.openafs.org/barnowl> That is probably workable for me, though it potentially puts me in
back-to-back-to-back meetings and will deprive me of my chance for
a "last-minute rush of reviewing".  But I can presumably do such
reviewing on fridays still, too...
[16:22:03] <kaduk@jabber.openafs.org/barnowl> (It would also leave me with no meetings at all most fridays, which
probably counts as a feature.)
[16:22:36] <meffie> that is a great feature!
[16:24:08] <kaduk@jabber.openafs.org/barnowl> I guess I should send mail proposing the change to the list, just to
confirm.
[16:24:22] <kaduk@jabber.openafs.org/barnowl> Is starting with next week fine or should we wait another week?
[16:24:35] <wiesand> I'd appreciate it if we tried. If it doesn't work out for someone, we can always revisit the topic.
[16:24:42] <Cheyenne> next week would be fine with me
[16:24:53] <wiesand> No, let's start right away next week.
[16:25:20] <mvita2> agreed
[16:25:26] <meffie> +1
[16:25:37] <yadayada> +1
[16:25:50] <kaduk@jabber.openafs.org/barnowl> Sounds good!
[16:25:57] <wiesand> Thanks :)
[16:29:48] <wiesand> The server logging stuff is probably not that urgent (14589, 14594, 10831) and I think there is going to be a "good" solution (a stack of relatively simple changes with relatively simple edits). So I'd like to give that more time.
[16:30:07] <kaduk@jabber.openafs.org/barnowl> I think I can live with that
[16:30:15] <mvita2> is there anything I can do to help you with those backports?
[16:30:48] <mvita2> no pressure, just offering help if that would help
[16:32:28] <wiesand> Big Sur is obviously more important. There seems to be a clash at least with ca472e66 . That's three years old, not trivial, and seems to open another can of worms. Simply editing 14431 is probably better, but I'd like to have a closer look.
[16:34:08] <wiesand> I appreciate the offer. That should be a last resort though.
[16:34:15] <kaduk@jabber.openafs.org/barnowl> So ca472e66 was part of "linux-native-mounts", which is as-yet not
fully merged on master :(
[16:34:16] <meffie> i could provide a patch for 14594 that is suitable for 1.8.x.
[16:34:58] <mvita2> 14594 is already 1.8.x
[16:35:12] <meffie> oh, so it is!
[16:35:18] <kaduk@jabber.openafs.org/barnowl> And ca472e66 itself is just supposed to be enabling a new framework,
not actually changing behavior.  So I'm inclined to say that we should
pull up ca472e66 rather than working around it.
[16:35:30] <mvita2> 10931 is the one that's master only so far
[16:35:37] <mvita2> sorry 10831
[16:36:10] <meffie> oh but they are not based on a branch.
[16:36:18] <kaduk@jabber.openafs.org/barnowl> And that one has its fingers all over the place, yeah :-/
[16:36:23] <mvita2> hmm
[16:36:54] <wiesand> 1.6.x lectured me what happens when I merge changes that were modified w.r.t. the master incarnation, without understanding those modifications.
[16:37:49] <meffie> well, 1.6.x has changes there were never on master, but yes.
[16:38:13] <wiesand> I have a strong preference for clean cherry-picks and a strong reluctance to make code skew more rather than less. It's more work in the short run, but will save grief in the long run. And our stable releases are "long run".
[16:39:22] <meffie> maybe pure fixes should hit the stable branch first, then "up" ported to master?
[16:40:11] <mvita2> that's an idea
[16:41:14] <wiesand> 14594 is a nice example. Pulling that up was easy. It even seems to help getting 10831 pulled up too (have to check the merge order on master again). But there are quite a few more changes in this area which IMO should also be backported sooner or later, and doing it now is much better than doing it later.
[16:42:26] <wiesand> I don't think we should make fies hit stable first.
[16:42:38] <kaduk@jabber.openafs.org/barnowl> > maybe pure fixes should hit the stable branch first, then "up"
> ported to master?
I am not confident in my ability to enforce a process that ensures
that fixes actually land on master, which would be needed to avoid
regressions.
[16:43:20] <meffie> yes, that is a downside. another is sometimes a change is not recognized it should be on stable until later.
[16:46:33] <wiesand> I don't think we should deviate from the general "master first" philosophy.
[16:47:29] <meffie> fair enough. it was just an option that occurred to me.
[16:48:12] <wiesand> We should aim for as little code skew as possible.
[16:49:10] <wiesand> There are cases where it's unavoidable (like 10831 & co. touch areas of code rxgk touches too).
[16:50:49] <wiesand> One possibility would be to generally split changes into a part that will easily apply to stable and a part that really really never ever is meant to be backported.
[16:51:35] <meffie> yes, we try to do that already
[16:52:32] <meffie> but a fix can be next to (or the same) lines of code for a new feature or code cleanup/refactoring change.
[16:53:56] <kaduk@jabber.openafs.org/barnowl> right
[16:55:04] <meffie> but we do need be more clear which patches are targeted for stable and which are not. i thing that would be helpful imho
[16:55:13] <wiesand> agreed - thus all we can do is minimize the number of those cases
[16:55:39] <meffie> s/i thing/i think/ :)
[16:56:30] <wiesand> for example, I don't see why code cleanup/refactoring changes should not be backported/pulled up
[16:56:54] <Cheyenne> I think if we went that route, then we might need a separate "development" branch that parallels master
[16:58:06] <wiesand> we'd end up with the same problem
[16:58:20] <meffie> oh, i see what cheyenne is saying.
[16:59:03] <wiesand> enlighten me?
[16:59:05] <Cheyenne> So for things such as IPV6, or other large work would stay in the development branch until they are "ready" for master
[16:59:12] <meffie> he means a the devel linage that is made of merges of fixes (which are for stable)
[16:59:34] <meffie> and another branch of changes for devel
[17:00:33] <meffie> (unless i'm reading to much into the idea)
[17:00:54] <kaduk@jabber.openafs.org/barnowl> The prospect of parallel development branches does not fill me with
excitement...
[17:01:08] <meffie> ha
[17:01:19] <meffie> that means NO. :)
[17:02:28] <wiesand> I think it would just move the problem. From stable<->master to master<->devel. I fail to see the win.
[17:03:35] <kaduk@jabber.openafs.org/barnowl> I suspect that's true, yes.
[17:04:18] <Cheyenne> I think that as long as master contains new features that will not be pulled into a particular stable will always result in some skew
[17:04:23] <kaduk@jabber.openafs.org/barnowl> Also, I'm aware that it's the top of the hour again, so I'll jump in
and note that I had a busy week with non-AFS things, so there's not
much to report from my end.  I looked at some of the `fs examine
-literal` stuff but that's about it.
[17:04:43] <meffie> thank you for the review
[17:05:07] <Cheyenne> latest master/1.8.x builds are still clean against linux 5.12-rc8+
[17:05:26] <wiesand> Sorry for stealing our time for my whining today!
[17:05:35] <meffie> thanks Cheyenne!
[17:05:38] <wiesand> Thanks cheyenne!
[17:05:46] <kaduk@jabber.openafs.org/barnowl> It's an important question that we'll have to face sometime!  Now is
as good as any...
[17:08:23] <wiesand> We won't solve that today, and I guess it has to sink in a bit.
[17:08:48] <wiesand> I guess we're finished for today. See you next Thursday?
[17:08:58] <mvita2> sounds good
[17:09:08] <meffie> someone remind me to meet on thursday! i will forget.
[17:09:25] <meffie> i'll make a reminder for myself. :)
[17:09:40] <kaduk@jabber.openafs.org/barnowl> I will note in this somewhat-discoverable place that I did find
Andrew's comment about pthread-bos that tries to motivate the "one big
lock" approach that his variant of the stack takes: it's a comment on
PS15 of https://gerrit.openafs.org/#/c/10286/
[17:10:10] <kaduk@jabber.openafs.org/barnowl> See you Thursday!
[17:10:25] <yadayada> thanka
[17:10:35] <meffie> thanks all.
[17:10:37] <kaduk@jabber.openafs.org/barnowl> Thanks everyone!
[17:10:51] <wiesand> Thanks everybody!
[17:12:19] meffie leaves the room
[17:13:43] <Cheyenne> thanks everyone
[17:27:49] mbarbosa leaves the room
[17:27:59] mbarbosa joins the room
[17:29:30] yadayada leaves the room
[18:42:48] mbarbosa leaves the room
[18:42:49] mbarbosa joins the room
[21:24:04] mbarbosa leaves the room
[21:50:02] wiesand leaves the room
[23:57:12] Cheyenne leaves the room