Re: Is a modern build system acceptable for older platforms - Mailing list pgsql-hackers
| From | Craig Ringer |
|---|---|
| Subject | Re: Is a modern build system acceptable for older platforms |
| Date | |
| Msg-id | CAMsr+YGHBv1zi8GKgXAeyxGXySfuZ2sp9L5pq012j9_0dS4NhQ@mail.gmail.com Whole thread Raw |
| In response to | Re: Is a modern build system acceptable for older platforms (Andres Freund <andres@anarazel.de>) |
| Responses |
Re: Is a modern build system acceptable for older platforms
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: Is a modern build system acceptable for older platforms (Andres Freund <andres@anarazel.de>) |
| List | pgsql-hackers |
On 18 May 2018 at 11:10, Andres Freund <andres@anarazel.de> wrote:
On May 17, 2018 7:44:44 PM PDT, Bruce Momjian <bruce@momjian.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...)
pgsql-hackers by date: