> I don't find this controversial, except the notion that sticking with > blunt tools to solve a human/procedural problem is a good idea.
How else should I, as the maintainer of the trunk, contain the damage from these human/procedural problems? Careful -- every suggestion you want to suggest now makes the job of the trunk maintainer harder. Every single one of them. If people don't depend on the trunk as their primary, the trunk rots. If people have easy branch tools, they use the branches. > It also > doesn't work, even if it appears to work: how many devs have I heard > talk about a local tree they've maintained for a long time with changes > that haven't yet gone in? Quite a few. Those are not public branches. They are used by one (maybe two) developers to advance something big. But not everything is big. Lots of important things are very small, and don't need a branch. Yet the answer heard over and over again is: branches are good, they should be used for almost everything. Except once again, that infects those people's trees, and they don't test the trunk, and once instabilities are introduced by another developer they abandon the head of the trunk and run something else and we don't get those bugs fixed until the release process. I see other projects falling into this problem all the time. It is awesome. > When the changes go in, they come > in small chunks, but the long-lived forks exist. No, these long-lived forks are deleted when their changes go into the trunk. They are just a local development process tool; some people manage to do them without rcs type models, yet others like their own rcs's. Here in OpenBSD, there are no such long lived forks. Maybe somewhere else. But look at the list you are on... > Small commits are > largely preferred by pretty much all of the sensible people I know, and > OpenBSD culture clearly prefers/demands them. I'd be surprised if giving > people sharper tools would do much harm. Ha ha. I watch other projects. You see what looks like "small commits", except the care of moving things from their own branch to the trunk is often highly sloppy -- by nature people are careless and will not re-test their trunk commits independently. So they break the head of the trunk. This pisses off developers who rely on the trunk. Eventually they learn to rely on their own safer branches and only update once in a while when the trunk is safe. Do you see where this is going? Incredible division of labour when it comes to testing. And who eventually gets burned the most by this? The release engineer... if a release is ever done. > > github is all about social coding and they have a point. But many > > of the things they enable are considered antisocial in the OpenBSD > > development process. > > There can be public read-only git without github, and I'd think > self-hosting would be a much better fit for OpenBSD. If people only used such trees for reading, fine. But they will run them, and then not test the trunk. Every 6 months we ship the trunk. How does it become solid if everyone runs something else?
