Home
release-team@conference.openafs.org
Thursday, February 24, 2022< ^ >
kaduk@jabber.openafs.org/barnowl has set the subject to: openafs release team
Room Configuration
Room Occupants

GMT+0
[16:42:26] wiesand joins the room
[17:01:53] kaduk@jabber.openafs.org/barnowl leaves the room
[17:02:12] kaduk@jabber.openafs.org/barnowl joins the room
[17:04:06] <kaduk@jabber.openafs.org/barnowl> greetings
[17:04:47] <wiesand> Hello
[17:04:59] <wiesand> I'm having the blues
[17:05:33] <kaduk@jabber.openafs.org/barnowl> I think that's understandable, given current events (and many other
potential reasons, to be clear)
[17:06:06] meffie joins the room
[17:06:32] <meffie> greetings. sorry for being late
[17:06:49] <wiesand> Well, it's clearly due to current "global" events. It's due to openafs too, however.
[17:08:16] <wiesand> I spent the better part of the day trying to disentangle interdependencies between changes on the list for 1.8.x. And the closer I look, the worde it becomes.
[17:08:27] <kaduk@jabber.openafs.org/barnowl> uh-oh
[17:08:59] <wiesand> Our development model for stable releases isn't working.
[17:10:49] <meffie> we could just provide bug fixes for stable, since it is a separate project from the development branch(es)
[17:11:04] <wiesand> And I'm *really* close to throwuig in the towel.
[17:11:05] <kaduk@jabber.openafs.org/barnowl> Hmm, 1.8.0 was almost 4 years ago.  On past trends, that suggests that
we're close to needing to cut a new stable branch in order to make
sense of things, anyway
[17:11:14] <meffie> yes
[17:11:52] <wiesand> That's one of the possible solutions, yes. But is it realistic anytime soon?
[17:12:06] <kaduk@jabber.openafs.org/barnowl> And scaling back drastically the scope of what we try to put in the
"old" stable branch is a reasonable approach.
[17:12:40] <kaduk@jabber.openafs.org/barnowl> Well ... IMO we have been pretty good about not putting half-baked
stuff into master.  So in that sense we believe that the current tree
provides stable behavior.
[17:13:17] <kaduk@jabber.openafs.org/barnowl> We've been making only very slow progress towards our major feature
goals for a 2.0 release, but I suppose one could have 1.10 follow 1.8
(or even repurpose 1.9)
[17:13:44] <kaduk@jabber.openafs.org/barnowl> And I only have 4 weeks left in my Security AD role, which ought to
free up some time to look at more AFS things.
[17:13:47] <meffie> in fact 1.9 is used for fedora users :)
[17:14:17] <meffie> s/used for/used by/ that is
[17:15:01] <wiesand> I'm not accusing you of merging half-baked stuff into master. The problem is that much of it is "not for stable". And the code skew has risen to a point where every pull-up is actually a serious backport.
[17:15:36] <kaduk@jabber.openafs.org/barnowl> Right, that is what I took your point to be
[17:16:06] <kaduk@jabber.openafs.org/barnowl> my "fully baked" remark was an attempt to start thinking about how
much effort is needed to actually make a new stable branch from
current master.
[17:16:34] <wiesand> Take https://gerrit.openafs.org/#/c/14911/
[17:16:40] <kaduk@jabber.openafs.org/barnowl> I would have to go check what we did last time, but I think doing some
installs and smoke tests on various platforms is a prerequisite,
possibly the only one.
[17:18:01] <wiesand> A really simple, one-line fix. But you end up having to either backport it, or pull in another two changes, years old. And cross-check against interaction with other changes, not always obvious.
[17:21:12] <wiesand> Maybe I'm just not up to it (any longer).
[17:22:09] <kaduk@jabber.openafs.org/barnowl> If you want to take the hat off, we will thank you for your service
and make new plans.
[17:22:34] <kaduk@jabber.openafs.org/barnowl> Please don't feel obligated to try and continue if you are finding it
problematic to do so.
[17:22:50] <wiesand> Sounds a bit like you'd welcome that? Please be frank ;-)
[17:23:35] <meffie> i think it would be better if we treated the stable branch as a separate code tree, and patches should be submitted to that project separately, and a separate version for the devel branch at the same time.
[17:23:59] <kaduk@jabber.openafs.org/barnowl> I truly am grateful for the work you've put in already, but I want to
support you as a person, before I start to worry about what's best for
the project.
[17:24:03] <meffie> i for one would not welcome that :(
[17:25:44] <meffie> i feels like this is a process problem, or we need a new stable branch.
[17:26:00] <kaduk@jabber.openafs.org/barnowl> Just to confirm: Mike's proposal for "stable branch as a separate code
tree" involves removing the requirement to make all submissions be
"cherry picked from" master, and reviewing them as if they are new
development?
[17:26:19] <meffie> yes
[17:27:09] <meffie> that way fixes can continue on stable and development can continue in parallel ?
[17:27:45] <kaduk@jabber.openafs.org/barnowl> That may be the best way to keep the 1.8 branch going, but I think it
means that we want to do the full code review process on submissions,
which is a somewhat different job that how we've been treating the
"stable release manager" role.  (And to be clear, Stephan has been
doing an amazing job at the "stable release manager" role!)
[17:27:47] <meffie> the other option is to go down the "git merge" route
[17:28:44] <kaduk@jabber.openafs.org/barnowl> But the "stable branch as a separate code tree" model is a big enough
change that my personal thought would be to look harder at "new stable
branch from master" before pursuing it very far
[17:28:57] <wiesand> Oh no, that's worse...
[17:28:58] <kaduk@jabber.openafs.org/barnowl> Mike: say more about the "git merge" route?
[17:30:27] <meffie> well, i mean, we dont like merges in general, but i think a lot of project lean into gits merge workflow. it's probably not a good approach at this point
[17:31:00] <kaduk@jabber.openafs.org/barnowl> Er, I mean, "I don't understand at a technical level what you propose"
[17:32:38] <meffie> well, i'd have to think about it
[17:33:23] <wiesand> It would rid us of those "path conflicts"
[17:33:49] <meffie> but yes, the current process is not great.
[17:34:40] <kaduk@jabber.openafs.org/barnowl> Oh!
[17:34:47] <wiesand> But path conflicts are just a symptom, not the cause.
[17:34:50] <kaduk@jabber.openafs.org/barnowl> You mean "tell gerrit to use merge commits rather than
rebase/cherry-pick.
[17:34:59] <kaduk@jabber.openafs.org/barnowl> Not "merge from master to stable"
[17:35:22] <meffie> yes, avoid cherry picks in general
[17:35:29] <meffie> not sure how that could work.
[17:35:59] <kaduk@jabber.openafs.org/barnowl> I think that a cherry pick would be needed from master to target
stable, or else git would try to pull in "the whole world"
[17:36:36] <kaduk@jabber.openafs.org/barnowl> And that cherry pick, in turn, might require the same level of review
that the "separate code tree" model.  But I'm not sure yet.
[17:36:41] <meffie> we have some internal trees were we have batches of changes (stacks) are their own banches, and the "main" branch is just merge commits.
[17:36:56] <kaduk@jabber.openafs.org/barnowl> *nods*
[17:37:00] <meffie> so there are different models.
[17:38:48] <kaduk@jabber.openafs.org/barnowl> Yup.
[17:39:15] <kaduk@jabber.openafs.org/barnowl> I suspect we ought not try to make a decision today, but should each
mull things over over the coming week and maybe try to email some
thoughts before the meeting.
[17:39:17] <meffie> sounds like we are in agreement it could be better, but will to be able to solve it today.
[17:40:18] <meffie> i wonder if a new version of gerrit has any features that could help.
[17:41:15] <meffie> also, i wonder if we should turn off the "path conflict" thing, esp for patches that are already in a stack!
[17:41:30] <kaduk@jabber.openafs.org/barnowl> I think new versions of gerrit do have some tooling to support
multiple branches, most notably including using the same Change-Id for
all branches.  But I don't know how they would play out for us.
[17:42:27] <meffie> ok
[17:42:57] <wiesand> I think we shouldn't (and also that it's only possible to do so by changing the submit strategy from "cherry-pick" to "merge".
[17:43:53] <meffie> ah, ok. and i assume "merge" means not a fast-forward merge, but a merge commit?
[17:45:02] <kaduk@jabber.openafs.org/barnowl> Hmm, yeah, it does look like we'd have to change the submit strategy
to do that.
[17:45:03] <wiesand> Path conflicts are not the source of our problems. That's changes lingering on master for years before they conflict with something we want on stable *now*.
[17:45:42] <kaduk@jabber.openafs.org/barnowl> options are: fast forward only, merge if necessary, rebase if
necessary, always merge, cherry pick.
[17:46:01] <kaduk@jabber.openafs.org/barnowl> So maybe "rebase if necessary" is similar to what we currently have
but less stringent?  Would need to look at docs to be sure.
[17:46:24] <meffie> ok
[17:47:15] <wiesand> "git merge" will do a lot of black magic behind your back - it will indeed solve many problems, but it will just hide a few others. Unless someone scrutinizes those merges very closely, you're in for surprises…
[17:47:51] <meffie> yes, that's true.
[17:49:24] <kaduk@jabber.openafs.org/barnowl> yes.    The current gerrit workflow forces a bit more scrutiny, though
it still not perfect
[17:49:43] <meffie> i feel the best way forward is to ask developers to submit separate changes to the stable branch. depending on the bug it can be pushed to stable first, then an updated version to the devel branch, if the bug also exists on the master branch.
[17:50:34] <meffie> and the patches to stable need to be mergeable to the current stable to be considered.
[17:51:03] <wiesand> I'm afraid that would end up creating separate lines of development.
[17:51:24] <meffie> i think we already have separate lines of development
[17:51:31] <wiesand> How about a policy change?:
[17:51:48] <meffie> yes?
[17:52:39] <wiesand> Today it's supposed to be the exception that a change submitted to master is to be included in stable.
[17:52:58] <meffie> yes
[17:53:13] <meffie> (depending on if you are doing fixes or devel ;)
[17:53:39] <wiesand> Let's revert this. Every change submitted to master is also for stable, with very few, well defined exceptions (like rxgk).
[17:54:31] <kaduk@jabber.openafs.org/barnowl> We would have to flip that switch at the branchpoint for a new stable
branch, though, right?
[17:55:02] <wiesand> In addition, shift some resources from whipping up new stuff to getting it ready for prime time.
[17:55:17] <wiesand> Ben: right.
[17:55:26] <meffie> i think another way to say that is we dont have a stable/devel release cycle any more, and just have one series?
[17:55:47] <kaduk@jabber.openafs.org/barnowl> In some sense, though maybe not exactly
[17:56:38] <meffie> i think that's what the did in linux. and old versions are treated as separate projects, with maintainers, right?
[17:56:45] <wiesand> Like, I begged for review of the open changes on 1.8.x, in particular FBSD 12.3. Weeks ago. Nothing. But now there's a change about supporting LWP for another platform?!
[17:58:00] <meffie> oh, LWP for 64-bit sparc. that's ... interesting.
[17:58:21] <meffie> (i think are time is better spent getting rid of LWP)
[17:59:45] <meffie> > We would have to flip that switch at the branchpoint for a new stable.
[17:59:51] <meffie> not sure i follow that.
[18:00:11] <wiesand> When working through that 1.8.x wish list today, I also noted there are quite a few changes on it not yet merged on master. Often because Ben requested input or made some remark but got no response.
[18:00:52] <kaduk@jabber.openafs.org/barnowl> I have to jump to my next meeting, but will see if I can pay half
attention here
[18:00:58] <wiesand> And items like this one:
[18:01:04] <wiesand> deason's/meffie's vldb_check improvements (meffie's not even in gerrit yet)
M14845 vldb_check: Check MHC for duplicate MH block
M14846 tests: Introduce vldb_check tests
M14867 vldb_check: General cleanup
[18:01:56] <meffie> yes, my changes are not ready for gerrit yet. mark mentioned i was working on vldb_check fixes.
[18:01:57] <wiesand> I think we're mostly done. Sorry for my whining, thanks for listening.
[18:03:33] <kaduk@jabber.openafs.org/barnowl> Not whining!  Good topics to think about.
[18:03:42] <meffie> sorry i was too slow in finishing the vldb_check fixes.
[18:04:16] <meffie> Yes, i do hope we can make a sensible policy that works in the long term.
[18:05:40] <wiesand> The current one isn't, and we must change this. Finally let me say that much of the current mess is certainly my fault.
[18:05:58] <meffie> no, no, no. i do not agree.
[18:06:51] <meffie> hopefully we can come up with a sane approach, and a new stable branch soon.
[18:07:41] <wiesand> a new stable branch would help a lot
[18:08:29] <wiesand> cu next week
[18:08:46] <meffie> ok, thanks wiesand take care
[18:10:05] wiesand leaves the room
[18:12:03] meffie leaves the room
[18:12:57] <kaduk@jabber.openafs.org/barnowl> I second Mike's "current mess is not wiesand's fault"
[18:13:27] <kaduk@jabber.openafs.org/barnowl> I think it is an emergent property of the system that we built, and
not directly the result of individual human review/merge choices
[18:40:49] mvitale joins the room