Thanks for the detailed response!
Each way has its own pros and cons, so as long as both ways are considered and
we choose the ones whose strengths matches what we need, that’s a win. Both
ways are viable, and neither one will lead to calamity. (and now that I have a
more full understanding of our intentions, my suggestion does seem less ideal)
In that spirit, some additional problems a rebase strategy would introduce:
-How often do we rebase on illumos? Every commit?
-The SHA for a changeset can potentially change many many times.
-The workload is greater on the admins.
But the overarching benefit I see in a rebase strategy is a clear understanding
of what changesets are where.
You mention that the diffs may be slightly different by the time they land in
illumos. Lets say that for a certain patch, the OpenZFS group approves it as it
is tn the GH PR. Then when it goes to illumos for RTI, they would prefer an
ASSERT be added. Weeks later after the next illumos merge, if I were running
OpenZFS/master, would I expect the ASSERT to be there or not? If I knew the bug
ID and searched for it in the logs, I would find the two versions, but which
one would I expect to be running, and how do I determine which one it is?
I was not considering the impact a rebase strategy would have on ‘git pull’,
because I do not use git pull (I fetch frequently, then use git checkout
(-b/-B) to get the repo in a state I want). You are correct, this would make
the git pull workflow significantly more risky.
I think the advantage for the downstream repos is going to be the PR process
and the discussions. I don’t expect downstream maintainers to source this repo
as a submodule or as a sub-tree, because it would pull in all of illumos. In
that case, neither method really affects them, because they will just be
reaching in and taking out the files they want (HEAD SHA will not really matter
to them). Once we reach the goal of independant files not tethered to any
implementation, this whole discussion becomes moot, because illumos will no
longer be merged in.
Seems like we have a pretty good coverage of the pros and cons, so unless any
of the above sound particularly compelling, continue to :shipit:
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/28#issuecomment-153750902
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
