Re: Adding support for SE-Linux security - Mailing list pgsql-hackers

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@2ndQuadrant.com  www.2ndQuadrant.com