When Fossil didn't have those features, the frequent complaints were that Fossil doesn't have those features, and that's why they had to keep using $INERTIA_SOURCE. Now that it has those features, it's the reason not to move to it? I see. :)
All of these features cooperate and serve the same goal: coordinate the work product of people on a project, in a distributed fashion. One path to that is the nearly fully centralized model of GitHub. Another is the VCS + mailing list + bug tracker + wiki path, which requires considerable admin resources to manage, and at the end of the day is a pile of barely-cooperating services. Fossil's path is to put them all into one place so they all work properly together.
You can reference ticket IDs from a forum post.
You can point to a section of the timeline from a wiki article.
You can create diagrams in Pikchr format that live as version-controlled text in the repo and reference them from commit messages.
You can generate HTML diffs and include them into the body of a Markdown chat posting for discussion of a proposed change before committing it.
Etc., etc. It's all communication, which you need when you have multiple people working on a project, especially across time zones.
I can't say anything to your first remark other than different people will want different things, it's unfair to level an implication of hypocrisy on the GP unless they have individually in the past actually complained about wanting to use Fossil because it lacked X but now have this complaint. Myself, I've never had a strong opinion either way, though I had only ever known Fossil for having all these extra features and thought it fascinating, not necessarily good or bad.
I did eventually try Fossil somewhat seriously for a personal project last year. I gave up and moved back to git, and don't think I'll try Fossil again, either personally or for a broader group or company project. I still find the idea of full integration interesting, just not Fossil's execution of it, not to mention some disagreements with the SCM philosophy itself. (For some it's about rebase, for me I realized I rather like the concept of staged/unstaged files or even Perforce-style pending changelists.) Meanwhile a collection of services approach actually works and cross-integrates pretty well especially when you don't have the requirement to try and self-host everything and give yourself that administrative overhead. And you'll get non-ghetto (for lack of a better descriptor) versions of those services.
Still, I don't recommend against Fossil, it's clearly good enough and aligns very well with certain values, people should evaluate it for themselves.
> Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, documentation, and blog features I want. I don't want my VCS to be a Lotus Notes for software development.
The forum, chat, and Pikchr features have been added since then. Indeed, everything in the Fossil ChangeLog has been added since then, because it cuts off a few months after your post: https://fossil-scm.org/home/doc/trunk/www/changes.wiki
My criticism, over a decade ago, was that Fossil had too many features that were tangential to version control. Since then, they have added more of those tangential features. So please explain to me how my complaints in 2011 are in any way inconsistent with the state of the project today. If anything, my complaints about feature creep have been vindicated by over a decade of continued feature creep.
In 2011, I wanted the flexibility to use other wiki, ticketing, documentation, and blogging systems. In 2022, I also want the ability to use other forum and chat systems. In 2033, I will probably want the ability to choose my own text editor. I have never complained that Fossil is lacking in features, especially features that are not directly part of version control.
Fossil is ideologically opposed to rebasing which makes it (according to its own docs iirc) not so good for large teams, since the repo is full of tons of useless little commits that git users squash out before merging.
All of these features cooperate and serve the same goal: coordinate the work product of people on a project, in a distributed fashion. One path to that is the nearly fully centralized model of GitHub. Another is the VCS + mailing list + bug tracker + wiki path, which requires considerable admin resources to manage, and at the end of the day is a pile of barely-cooperating services. Fossil's path is to put them all into one place so they all work properly together.
You can reference ticket IDs from a forum post.
You can point to a section of the timeline from a wiki article.
You can create diagrams in Pikchr format that live as version-controlled text in the repo and reference them from commit messages.
You can generate HTML diffs and include them into the body of a Markdown chat posting for discussion of a proposed change before committing it.
Etc., etc. It's all communication, which you need when you have multiple people working on a project, especially across time zones.