Re: [Gdbheads] Let's resolve this quickly

[Ian Lance Taylor]

Elena Zannoni <address@hidden> writes:

> I.e. there are two approaches, either you are more restrictive and
> careful when you check stuff in, or you need to stabilize later on.
> Either way, there is a cost associated with change. Whether you are
> putting the cost upfront when you check stuff in, or later on when you
> stabilize it, the cost is there.

This is true, of course.

The difference is that once the patch is in the source tree, anybody
can fix it.  Before the patch is in the source tree, only the
submitter or a maintainer is likely to fix it.  In other words, I
would argue that on average it is cheaper to fix something once it is
in the source tree--or, if fixing it is too expensive, you revert it.

There are different philosophies of open source development.  I
personally subscribe to "release early, release often"--get the code
out there so that people can see it and fix it.  Code which nobody
sees is code which isn't getting fixed.  Back when Eric Raymond wrote
"The Cathedral and the Bazaar," he was already wrong about how FSF
development worked in general, because Ken Raeburn was already opening
up the development process for the GNU binutils, a process which I
continued.

Ian