I am proposing adding a new role/capability. I'm not sure how hard this will be to implement but I believe it is an important one. There should be a capability that allows people to pish to any branch except trunk. I want to allow people to contribute to my project but I don't want everyone having the ability to alter the trunk branch without approval. Thoughts?

Trunk is just a branch like any other. It's only "special" by convention, not by policy. Fossil needs "some" default branch, and "trunk" is that (arbitrary) default. In a DVCS it's impossible to keep someone from pushing to a given branch unless that policy is in force for every copy of the repo. i.e. it's impossible to enforce.

In a DVCS it's impossible to keep someone from pushing to a given branch

GitHub has this functionality. You're able to do whatever you want locally of course, but if the remote branch is "protected" then you cannot push to it. "Trunk", just like "master", is indeed an arbitrary default. But there is also a widely used convention that these defaul branches (trunk, master, etc.) should be build-able/use-able at all times. I would love having as many contributors to my project as possible but I would still like to keep the convention of "trunk should be build-able/use-able at all times".

github supports it because github is not a DVCS. It's centralized service built upon a DVCS. Fossil is not a centralized service, it's a DVCS. This type of feature requires a central authority, and that's something fossil does not provide.

I guess I just have to bring on contributors that I can completely trust

Do you completely trust everyone you live near? Do you trust everyone in your country? Are these prerequisites to a productive life?

I'll grant that the anonymization afforded by a few thousand miles of Internet cabling tends to erode the benefits of prior civilizing influences on people, but it is still possible to build well-functioning civilizations upon the Internet. We have one right here.

I quite understand if you're unwilling to trust others easily, but I think there's a grey zone between "is completely trusted" and "has provided good patches in the past" where there's a high chance of getting good-quality direct checkins which respect your project's rules.

Your committers will occasionally break your project's rules. Part of your job as project lead is to enforce those rules in a way that leads to better future commits, rather than in a way that causes you to lose committers.

Just the other day, I learned here on Fossil's own repository that I speak the local dialect of Hungarian with a detectable accent. I'm unlikely to mispronounce it the same way in any future checkin now. The correction was handled delicately: I was neither annoyed by the correction nor banned, so now I'm likely to continue improving Fossil.

Rather than comparing Fossil (a DVCS) to github (a service), compare it to git(another DVCS).

As of the last time I used git (not by choice), if you allowed someone push privilege to your git repo, you'd have the same problems as when you allowed someone to push to your Fossil repo.

I can't say if git has since added a feature to block pushes to specified branches, but I do know that github layers additional features on top of git.

At least when I did use github, the main mechanism for contributing to another person's project was "pull requests".

github's UI for pull requests aside, they are really very simple: A message with an URL. The message describes what the offered contribution is, and the URL points to a commit in the requestor's repository.

That seems a reasonable approach to accepting contributions from "untrusted" developers.

As long as you're paying attention to the checkins — and you have less excuse now than ever before, since the same mechanism that allows email notification of forum posts also allows you to sign up for email notifications on checkins — Fossil already has a way to move something unwanted off of trunk:

1. Edit the checkin in Fossil UI, moving it to a new branch.

2. Use fossil amend to do the same thing.

Either option moves the checkin and all of its children to the new branch, so it's important to catch this early.

Having done this, "trunk" once again means the same thing as before the bad checkin.

I realize you want a more rigid solution here, but a software project is a human endeavor first and a technological product second; you should be leaning more on community mores than on technological limitations. If you don't trust someone to commit to trunk, you probably oughtn't let them commit to any branches, either.

How you handle violations of your restrictions on checking in to trunk is also a social matter. You might have a series of escalating warnings, just as you probably already do for bad code style, missing tests, etc.

If I've failed to convert you to my grand philosophy of project management ( :) ) and you try to implement this anyway, I think you'll find it to be fairly difficult, due to the DVCS nature of Fossil.

First off, each user has Setup privileges on their own clone, so a naive solution involving only the central repo will result in users successfully checking changes into trunk, then being unable to sync to the central repo. Now they've got to move their local checkin to a branch before the local clone will sync.

A better solution would be for the central clone to pass down the restrictions to the clones, but now you've got a new problem, because the user table doesn't sync down to the clones of low-privilege users, on purpose. So, how would the clone learn what privileges the central server allows?

Then having battled past that, you've turned Fossil partly into a centralized VCS: a clone's user should be allowed to modify his own clone any way he likes. That brings you back to the first problem, where you want this condition to just make the clone un-syncable, which is a usability problem.

Yech.

Plan B: If someone can't be trusted to check changes in to trunk, but you're still willing to accept changes from them on a provisional basis, make them submit patches or bundles instead.

After someone has sent in several good-quality submissions, you may then be willing to give them check-in privileges.

It turns out, most people are not evil. Almost everyone who wants a commit bit on your project wants to help your project, not harm it. What turns out to be harder to discover is whether they're competent to do that, and you only learn that by watching what they do for a while.

Don't react too harshly too fast: someone who starts out a bit clueless may turn into one of your best contributors, with a bit of mentoring.

And if it turns out that someone is in fact evil or irredeemably incompetent, Fossil gives you the tools to kick them out and back their damage out.

Either option moves the checkin and all of its children to the new branch, so it's important to catch this early.

Say I'm on vacation and I am not around a computer or phone for 2 weeks. What if I can't catch it early? This functionality should of course not be enabled by default, but I still think there is a valid use for something like this. GitHub has the capability to do this so I'm pretty it is not completely impossible.

Run:

fossil merge --backout <bad-checkin>

Then compile, test, and commit. That will undo all the changes in the <bad-checkin> check-in. It won't remove them from the repository, and people will still be able to go back and see historical check-ins that include the bad change, but it will remove the changes from the latest trunk check-in.

Say I'm on vacation and I am not around a computer or phone for 2 weeks.

Sounds like a time of delegation. if drh is on vacation, he's got others with fossil write access and sqlite access who can make commits.

GitHub has the capability to do this so I'm pretty it is not completely impossible.

Little is impossible with software, but just because it's possible, doesn't mean it's a good design idea.

I say it's important to catch it early because you don't want others to check in other changes on top of the bad one, because that means you have to move their checkins to the "bad checkin" branch as well, then probably cherrypick them back onto trunk. It's not especially difficult to fix all of this, it's just tedious and makes the timeline GUI look a bit ugly, so it's better not to get into this situation.

If only the rogue developer made checkins while you were away, then when you get back, you can move everything past your last good checkin to a "bad checkins" branch, then deal with the violation socially.

If you have multiple users with checkin rights, some of which are allowed to check in directly to trunk and some not, then those granted permission to modify trunk can fix the problem before checking their changes in: amend privilege is part of check-in privilege.

That leaves you only with the possibility of a developer so misguided or evil that they then move their checkins back to trunk, which then makes me wonder why that person has a checkin bit at all.

GitHub has the capability to do this so I'm pretty it is not completely impossible.

Sure: you could just turn Fossil into a non-distributed VCS.

That wouldn't necessarily be a bad thing. Traditional VCSes have some advantages over DVCSes. If you want a centralized VCS, I can think of worse things than to make it a Fossil-based VCS.

Anyway, I didn't say it was impossible. It just makes Fossil into something rather different than the software that attracted me to the project. Thus my claim that this would result in a project fork.

Fossil already supports such a capability (to a degree, could use some polish) which operates in a similar manner to git (same method used by gerrit and others); server-side hooks.

Fossil provides server-side hooks (for receiving 'push's'). One can insert TH1 code here to either allow the push or reject it (if perhaps the commit message template was not followed, a 'restricted' branch was specified, etc.).

I remember setting up a fossil repository like this before to enforce a classic checkin-to-review-branch, get approval (code reviewed) and a privileged user (gatekeeper) could then move the change over to the applicable branch (trunk, release-xx, etc.). I also remember this was a terrible pain to setup (rejected push's didn't give a clean, applicable, failure reason, determining the user was difficult and other side cases I don't believe I entirely resolved at the time).

I would like to cleanup fossil capabilities in the future (under load currently*), to allow specifying branch capabilities (other fossil items, like skins, already store privileged users). In addition, I wouldn't mind making the capability system a little more generic (giving the ability to dynamically create verifiable capabilities and allowing them to referenced by TH1 scripts). Would also like to give the ability to remove 'default' groups (developers and other non-special ones) while adding the ability to create new groups.

*Would very-much like to contribute to fossil development (when some free time comes up) as this is one of the most interesting FOSS projects I've seen in a while)