Re: Is a modern build system acceptable for older platforms

2018-05-18 5:50 GMT+02:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:

> 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?".
>

+1

I have to maintain Orafce and plpgsql_check for MS Windows and it is not
nice work

Pavel

> (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
>
>