On Mon, 28 May 2018 at 03:30, Yuriy Zhuravlev <stalkerg@gmail.com> wrote:
I suppose I can make summary after reading all this:
1. Any change in the development process will be possible if it will be convenient for each key developers personally only. (development process include build system)
2. Currently, almost all key developers use Unix like systems, they have strong old school C experience and current build system very comfortable for them.
I think new build system will be possible only by next reasons:
1. Autotools will be completely deprecated and unsupported.
2. Key developers will be changed by people with another experience and habits (and maybe younger).
I don't want to be CMake advocate here, and I see some problems with CMake to Postgres project too. But I want to make Postgres development more comfortable for people like me who also doesn't like mail lists and was growing with github. Unfortunately, we are too few here to change anything now.
If we were starting out a new project, would we choose the tools and environments we have now? Probably not. Is it worth spending thousands of person-hours converting what we have into something different that happens to be de rigeur, and (especially) using up many hours of our precious core developer time while they learn the new methods, while not actually gaining functionality? Also, probably not.
The core developers are core developers because they have been involved with postgres for years. Yes, to a certain extent that's a respect thing, they've earned the right to be part of the core team, but it's also related to the fact that they're likely to be around moving forward.
Someone has to maintain and manage these things. With the greatest of respect - I'm sure you have the best of intentions and would be happy to put in many person-hours changing the build environment and helping everyone through the change process - life has a habit of overtaking our best intentions. Who's to know whether you'll still be involved in Postgres in 5 years' time?
