Hi!

I got Fossil to work on MorphOS in the morphos branch. I successfully cloned https://objfw.nil.im/, made two commits and pushed them, so it even works with somewhat larger repositories that require multiple round trips. It is a bit slow, but that is due to the combination of 20 year old hardware and the UNIX emulation layer ixemul.

The changes are quite minimal, in my opinion, so it would be nice if this could be merged. The contentious change is probably the change to the embedded SQLite and jimsh. It is a quite minimal change to get SQLite running via ixemul on MorphOS, so I hope this can be merged into SQLite, given the Fossil developers and SQLite developers are mostly the same. What would be the best process for this? Should I sign up on the SQLite Fossil and post on the forum? I've signed the CLA for Fossil, so I guess that should also be good for SQLite? The jimsh patch is already upstreamed.

The only thing I could find that is not working yet is the integrated HTTP server. This is due to the fact that ixemul does not emulate fork, so a larger refactor would be required that makes it fork-less. That would probably also benefit Windows. But since that is something larger, that probably demands its own branch.

The next release of MorphOS, 3.20, will very likely also include Fossil in the SDK, making it the probably the first OS to ship with Fossil in the SDK.

I've signed the CLA for Fossil, so I guess that should also be good for SQLite?

Unfortunately not - SQLite. SQLite has its own contract, and any source code in SQLite (as opposed to infrastructure tools, like autosetup) is required to have been written by the one doing the checkin. When someone posts SQLite patches which are accepted, they're used as a proof-of-concept and rewritten/reformulated unless they're so trivial that they can't sensibly be expressed some other way (that is the case, IMO, for your particular patch).

If drh doesn't see this i'll point it out to him as a candidate for an upstream patch. "The problem," though, is that we have no way of testing it beyond setting up MorphOS, a burden neither of us will want to take on. Whether your patch really warrants that particular concern is debatable, of course, and IMO it's not a concern in this case, but the decision is ultimately drh's and that factor will certainly be part of the equation.

Please keep the MorphOS port off of trunk for now. Rationale:

1. Asking "can I merge to trunk" is really a nice way of asking "will you take over maintenance of this for me". No, I don't have the bandwidth for that right now.

2. There are a lot of "#ifdef IPV6" in parts of the code that are complicated enough already.

3. There are changes to upstream: SQLite and autosetup.

4. The MorphOS user community seems capable of taking care of themselves. It will not be a terrible hardship for them to have to pull the code from a branch other than trunk, or to contribute occasional bug fixes or updates to the morphos branch.

That said, if you want to continue supporting the morphos branch, by merging trunk updates into morphos periodically, that would be fine. You are welcomed to do that. Notice that I do something similar for some long-running branches on SQLite, rather than burden the trunk with unnecessary #ifdefs. See one example of this at: https://sqlite.org/src/timeline?ml=bedrock*+wal2*.

That's a sad outcome, but let me make some arguments to see if they can be convincing:

1. I don't understand how getting this merged is a request for you to take over maintenance - I'm quite happy to maintain it. And should I not, it's very easy to remove it again. I don't foresee any maintenance burden in any case, really. The patch doesn't touch the code paths for any other OSes, so the worst thing that could happen is that MorphOS support breaks. Which is no worse than the current situation which is no MorphOS support at all. If things break in the future, I'm also happy to fix them.

2. Yes, it's debatable if #ifdef IPV6 is the right one here. This applies for any OS that does not have the new name resolution APIs that were added to POSIX roughly the same time as IPv6. I'm quite surprised how the DJGPP port works without this?

3. Yes, which is why I asked about upstreaming those to SQLite. I'm puzzled about where I patch autosetup. Isn't auto.def specific to Fossil? It contains a lot of Fossil things. Did autosetup upstream an auto.def specifically for Fossil?

4. It's usually always better for everyone involved if everything is upstream. That usually improves maintenance for everybody, makes ports to other OSes easier and makes further development easier (see below). I'm happy to refactor things if you think instead of #ifdefs, they should just be properly abstracted, which is a fair point to make.

I would still be eager to get MorphOS support upstream, the reason being pretty simple: Branches of branches. Let's say I create a branch to add color support to diffs (which on MorphOS makes a lot of sense since it's less convenient to pipe things through something like colordiff and less). Now, given I do the development on MorphOS, I have to base these changes on the morphos branch rather than on trunk. How could color diff support ever be merged then, later on, given Fossil has no rebase?

With this in mind, I'd be very interested in finding another way to allow upstreaming MorphOS support that would be acceptable to you.

How could color diff support ever be merged then, later on, given Fossil has no rebase?

Cherry-picking.

Wouldn't that be pretty bad, cherry-picking an entire branch with double digit commits?

How could color diff support ever be merged then, later on, given Fossil has no rebase?

See Rebase Considered Harmful section 2.1:

A rebase is just a merge with historical references omitted

Fossil does support merge. It just chooses to remember all the parents, rather than forget some of them as Git does. There is no loss of capability.

So if somebody adds something to trunk that you want to incorporate into the morphos branch, all you do is merge:

fossil up morphos
fossil merge trunk
#  run tests...
fossil commit

I'm talking about the other way around. I need the changes that are in branch morphos to do any development at all, since Fossil needs to run in order to develop it further. So that means all my changes are created based on branch morphos. So if I create a branch colordiff, this one would be forked from morphos, not trunk. Now, if we want to merge the branch colordiff later, this would automatically bring in the changes from branch morphos, too. So how would we do this then if we want to merge colordiff to trunk, but not morphos? That would only work with a rebase of colordiff on trunk - which we can't do.

The first approach has the problem that I would need to commit untested changes to colordiff, which would be quite bad. The second approach could work, though, so I will try that when it gets to this.

Anything about the other points? Is there any way MorphOS support could be added in a way you would be OK with having in trunk? As said, I expect zero maintenance from others for it, as I will maintain it - and if not, well, dropping support is easy. So I really don't understand the perceived risk. If you think ifdefs are ugly, happy to instead abstract things. I still believe it would be easier for everybody if development happens based on trunk and not based on another branch :).

Asking "can I merge to trunk" is really a nice way of asking "will you take over maintenance of this for me".

To add some context to that for those who may benefit from it: this project has only a handful of long-time maintainers and arguably only two "core" maintainers (disclaimer: i feel justified counting myself as one of those two). People come and go, as is natural in any project, and the long-term contributors don't want to be stuck maintaining things which were there only to proverbially scratch someone else's proverbial personal itch. Symlink and th1-docs are examples of where that's happened: we can't remove symlink support without disrupting who-knows-how-many repositories, plus that compatibility burden carries on downstream/side-stream in libfossil, so it's a double-whammy for me personally.

I would understand this stance if this were a big change with a significant maintenance burden that would always need to be carried around or even a change to the format. However, none of that is the case and removing this again is literally just dropping the code in a few ifdefs, so it seems hard to comprehend how this could be rejected as a massive maintenance burden should I disappear. Even doing nothing would not be a problem - let the code in the ifdef be broken and nobody other than MorphOS will be broken. It doesn't touch the code on any other OS at all. I even offered to add a layer of abstraction if ifdefs are considered to be too ugly. So I really don't see any maintenance burden at all here, sorry. In fact, such a patch would have probably been happily taken by 99% of open source projects within less than a day. Most projects are happy to take patches that improve portability, because often it points towards hard-coded assumptions and improves abstractions, leading to better code overall. See this very recent and relevant post: https://infosec.exchange/@david_chisnall/114674770032641847. A good example of how this has lead to worse code is that Fossil currently has two different HTTP server implementations, one for POSIX and one for Windows, instead of having a generic one using async I/O (something I would have been willing to work on, but not if all my changes go nowhere anyway).

There only being two core maintainers is maybe something that should trigger taking a step back and thinking about why that is. It seems that very simple changes get rejected, and this is not the first time it has happened to me. When even simple fixes cannot be merged, it drives contributors away. I at this point have zero hope of getting something like https://fossil-scm.org/home/info/9e06f72b710808c5 merged, even though it fixes an actual bug affecting every OS but Windows (well, actually, maybe even modern Windows, as it gained symlinks). It seems there is a general mindset of "If this doesn't fix a particular problem / bug I have, it's not gonna get merged". However, with such a mindset, it is impossible for others to contribute. This leaves me with two options: If Fossil is not gonna meet my needs, even though simple patches could achieve this, I can either fork, or I can move to another VCS.

It's fine if Fossil only wants to cater to the needs of the two core maintainers and nobody else. However, I think then it should be made more clear that contributions are not welcome and people should just go away and fork or use a different VCS. I always wondered why there are so few projects using Fossil, even compared to Mercurial. However, I notice myself there are a lot of sharp edges and eventually it's death by a thousand cuts. All these minor things add up and would be easy to fix, but not if nothing ever gets merged because it doesn't scratch the needs of the two core maintainers. And I would not be surprised if other projects are in a similar situation and just moved back to something else. Here is just another example of Fossil being almost there, but a few sharp edges driving the decision to move away: https://kalafut.net/posts/fossil-scm-again/. I imagine other projects were in a similar situation, but just did not blog about it. Many of those sharp edges could easily be fixed, if only contributions would be welcome.

Another example is that on the one hand, changes quickly get rejected, however, user facing changes that break workflows quickly get added without providing an option to restore the old behavior (see recent removal of inline diffs for added/removed files, for example). All this makes me feel more and more like Fossil is not a tool to be used by everybody, but only by the core maintainers for the core maintainers.

Sorry this got a bit long and might sound like a rant - it's not supposed to be one. It is just frustration because I really like Fossil and would like to improve it, however the project doesn't seem to be open to contributions even after making one sign a CLA, which makes me really sad, as Fossil is just so close to having everything I'm looking for.