Re: Adding support for SE-Linux security

David P. Quigley wrote:
> I understand that PostgreSQL is a fast moving target with a large developer base but so is the Linux Kernel and a
> similar framework has been working there for years now.
>

It sounds like how you're thinking about this project's development
model is inverted from the reality, and it's import to sort that out
because it really impacts why there's so much resistance here. One
reason the Linux kernel moves so fast because they don't care one lick
for many types of backward compatibility, they'll just change interfaces
as necessary to work around problems. To use the terms of the old 2.4
Linux kernel, there is no "stable" branch development happens against
anymore; just the fast changing unstable one, that if everyone is lucky
eventually converges into some usable versions anyway.

Here, there is zero tolerance for any commit that destabilizes the
codebase even temporarily. Until you get the whole thing sorted out
usefully enough to be shippable quality, you don't go into the main (and
only official) branch.

Also, the PostgreSQL developers like to deliver a stable release and
then change *nothing* to it except to fix bugs, supporting that release
for years. We consider a released piece of software like a contract to
the users, and everyone goes through lots of work to avoid changing
anything unless absolutely necessary. A very large component of the
concern here comes from that mindset. If this goes out, and there's a
fundamental problem with it, this community doesn't even have a good
process to fix that until the next major release, around a year later.
In general, there is no such thing as an upgrade to a stable version
that includes a serious behavior change. Having that happen is
considered a major breakdown in the process, and there's only been a
very small number of such situations in the past, when some just
impossible to work around bug was introduced. Instead, just the
absolute minimum of changes needed to fix bugs are applied to the
stable, shipped versions. If a version ships with a broken enough
behavior, it's quite possible that fixing it cannot be done in a way
that can be distributed and applied via the standard minor version
upgrade procedure used at all.

The idea here is not "if it's not quite right, development is fast so it
will get sorted out eventually". Instead it's "if it's not believed to
be free of non-trivial bugs, don't commit it at all". SEPostgres has
lived in this state for a while now. And it's not known bugs that are
the problem, it's that almost all of the Postgres community can't even
accurately gauge whether there are bugs or not in the code/design, which
is really uncomfortable given how things work here.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com