Re: Is a modern build system acceptable for older platforms

On 18 May 2018 at 11:10, Andres Freund <andres(at)anarazel(dot)de> wrote:

>
>
> On May 17, 2018 7:44:44 PM PDT, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
> >> I do have a real concern about the long term attractiveness of the
> >> project to new developers, especially younger ones as time passes.
> >> It's not a secret that people will just avoid creaky old projects,
> >and
> >> for Postgres old out of fashion things do add up: autoconf, raw make,
> >> Perl for tests, C89, old platform support. I have no doubt that the
> >> project is already loosing competent potential developers due to
> >this.
> >> One can say this is superficial and those developers should look at
> >> the important things but that does not change reality that some will
> >> just say pass because of dislike of the old technologies I mentioned.
> >> Personally, I can say that if the project were still in CVS I would
> >> probably not bother as I just don't have energy to learn an inferior
> >> old version control system especially as I see version control as
> >> fundamental to a developer. I don't feel the balance between
> >> recruiting new developers and end user benefits tilted enough to
> >> replace the build system but maybe in some years that will be the
> >> case.
> >
> >What percentage of our adoption decline from new developers is based on
> >our build system, and how much of it is based on the fact we use the C
> >language?
>
> I think neither is as strong a factor as our weird procedures and slow
> review. People are used to github pull requests, working bug trackers,
> etc. I do think that using more modern C or a reasonable subset of
> C++would make things easier. Don't think there's really an alternative
> there quite yet.
>
>
+10.

Also - mailing lists. We're an ageing community and a lot of younger people
just don't like or use mailing lists, let alone like to work *only* on
mailing lists without forums, issue trackers, etc etc.

I happen to be pretty OK with the status quo, but it's definitely harder to
get involved casually or as a new participant. OTOH, that helps cut down
the noise level of crap suggestions and terrible patches a little bit,
which matters when we have limited review bandwidth.

Then there's the Windows build setup - you can't just fire up Visual Studio
and start learning the codebase.

We also have what seems like half an OS worth of tooling to support our
shared-nothing-by-default multi-processing model. Custom spinlocks, our
LWLocks, our latches, signal based IPC + ProcSignal signal multiplexing,
extension shmem reservation and allocation, DSM, DSA, longjmp based
exception handling and unwinding ... the learning curve for PostgreSQL
programming is a whole lot more than just C even before you get into the
DB-related bits. And there's not a great deal of help with the learning
curve.

I keep wanting to write some blogs and docs on relevant parts, but you know
how it is with time.

The only part that build system changes would help with would be getting
Windows/VS and OSX/XCode users started a little more easily. Which wouldn't
help tons when they looked at our code and went "WTF, where do I find out
what any of this stuff even is?".

(Yes, I know there are some good READMEs already, but often you need to
understand quite a bit of the system before you can understand the
READMEs...)

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services