Theo de Raadt | 5 Aug 22:14 2012

Re: OpenBSD on GitHub

> 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

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?