2018-05-18 5:50 GMT+02:00 Craig Ringer <cr...@2ndquadrant.com>: > On 18 May 2018 at 11:10, Andres Freund <and...@anarazel.de> wrote: > >> >> >> On May 17, 2018 7:44:44 PM PDT, Bruce Momjian <br...@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?". >
+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 > >