On Sun, Aug 05, 2012 at 02:14:56PM -0600, Theo de Raadt wrote: > > 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.
I agree. If I implied that public branches were good then I should have been more clear. The "-current is (almost) always best" and "release like clockwork" attitudes have paid large dividends, and that goes hand in hand with trunk working as you say. The private branches (or whole separate trees!) seem like another matter to me. In git, working with branches and keeping them in sync is fairly easy, as is sharing directly (not through the central repo) with others. > 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. Back when CVS was in widespread use, people still did stupid things. They do stupid things now with git. I'm one of those people who like to make branches for everything, but I still test against trunk. Of course I do. That's what will get committed to the central repo, so that's what matters. > > 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... This time I was definitely unclear. Yes, delete after merging with trunk. > > 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. I won't vouch for what unsensible people do. Of the various ways I've seen people do things, "trunk is reliable" works the best by a long shot in my experience. You can do the "trunk is gee whiz cutting edge" with CVS, too. We've both seen projects do that with CVS. It stinks. But that's not a CVS vs. Git thing. > > > 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? I'm not sure this would be the case to any larger degree than now, but I don't understand your reasoning there so it's likely I'm missing something. I think Git can support the workflow you want, but that doesn't matter. I do not expect or want to change your mind, and do not expect to see an official OpenBSD git repo soon, if ever. It should only ever happen if it makes sense to you and the other OpenBSD devs, to further the underlying goals of the project. Until then, it would be stupid to switch. So at this point I don't even *want* you to switch. Not yet, anyway.
