I'd like to go back to Benedict's initial point: if we have a new consensus protocol that other projects would potentially be interested in, then by all means it should be its own project. Let's start with that as a basis for discussion, because from my reading it seems like people might be disagreeing with that initial premise.
If we agree that Accord should be independent, I'm +1 for git submodules primarily because that's a standard way of doing things and I don't think we need yet another bespoke solution to a problem that hundreds, if not thousands of other software projects encounter. I've worked with lots of projects using submodules and while they're not a panacea, they've never been a significant problem to work with. It's also a little confusing to see people argue about HEAD in relation to any of this, since that's just an alias to the latest commit for a given branch. In every project I've worked with that uses submodules you would never use HEAD, because the submodule itself already records the *exact* commit associated with the parent. Cheers, Derek On Tue, Jan 17, 2023 at 2:28 AM Benedict <bened...@apache.org> wrote: > > The answer to all your questions is “like any other library” - this is a > procedural hack to ease development. There are alternative isomorphic hacks, > like compiling source jars from Accord and including them in the C* tree, if > it helps your mental model. > > > you stated that a goal was to avoid maintaining multiple branches. > > No, I stated that a goal was to *decouple* development of Accord from C*. I > don’t see why you would take that to mean there are no branches of Accord, as > that would quite clearly be incompatible with the C* release strategy. > > > > On 17 Jan 2023, at 07:36, Mick Semb Wever <m...@apache.org> wrote: > > >> >> … extrapolating this experience to multiple C* versions > > > To include forward-merging, bisecting old history, etc etc. that's a leap of > faith that I believe deserves the discussion. > >> - patches are off submodule SHAs, not the submodule's HEAD, >> >> >> A SHA would point to the HEAD of a given branch, at the time of merge, just >> by SHA? I’ve no idea what you imagine here, but this just ensures that a >> given SHA of the importing project continues to compile correctly when it is >> no longer HEAD. It does not mean there’s no HEAD that corresponds directly >> to the SHA of the importing project’s HEAD. > > > > That wasn't my concern. Rather that you need to know in advance when the SHA > is not HEAD. You can't commit off a past SHA. Once you find out (and how does > this happen?) that the submodule code is not HEAD what do you then do? What > if fast-forwarding the submodule to HEAD's SHA breaks things, do you now have > to fix that or introduce branching in the submodule? If the submodule doesn't > have releases, is it doing versioning, and if not how are branches > distinguished? > > Arn't these all fair enquiries to raise? > >> - you need to be making commits to all branches (and forward merging) anyway >> to update submodule SHAs, >> >> >> Exactly as you would any library upgrade? > > > > Correct. submodules does not solve/remove the need to commit to multiple > branches and forward merge. > Furthermore submodules means at least one additional commit, and possibly > twice as many commits. > > >> - if development is active on trunk, and then you need an update on an older >> branch, you have to accommodate to backporting all those trunk changes (or >> introduce the same branching in the submodule), >> >> >> If you do feature development against Accord then you will obviously branch >> it? You would only make bug fixes to a bug fix branch. I’m not sure what you >> think is wrong here. > > > > That's not obvious, you stated that a goal was to avoid maintaining multiple > branches. Sure there's benefits to a lazy branching approach, but it > contradicts your initial motivations and introduces methodology changes that > are worth pointing out. What happens when there are multiple consumers of > Accord, and (like the situation we face with jamm) its HEAD is well in front > of anything C* is using. > > As Henrik states, the underlying problem doesn't change, we're just choosing > between trade-offs. My concern is that we're not even doing a very good job > of choosing between the trade-offs. Based on past experiences with > submodules: that started with great excitement and led to tears and > frustration after a few years; I'm only pushing for a more thorough > discussion and proposal. > > > > -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+
