Thankfully there are alternatives! My favorite thing to do when trying to learn a new large FOSS codebase is to implement some redundant function like a plus (+) operator. If you do that in Python or PostgreSQL you can mostly copy-paste from existing functions (don't actually look at the exact one you're copying) and it will take you through the language frontend (lexer/parser) and backend evaluator.
You can do this same kind of technique whether it's a language or not. Just take some kind of redundant feature and copy existing features/modifying as you go along.
I wrote about doing this kind of thing for nginx, as an example: https://notes.eatonphil.com/learning-a-new-codebase-hacking-...
You'll learn a lot about the architecture and build process within a few hours.
Which matches the contributor's email domain name suburbia.net
You might be able to report an outright bug if you find one, and you can report "this old patch still applies and passes its tests", but other than that it seems difficult for the project to make use of what you say.
If you say "I read this patch and everything looks great, I'd love to see this in the next release", how much weight can the project put on that? How do they know whether you would have found problems if they were there?
Or if you read the patch and conclude "I can't find any actual bugs, but I'm pretty sure most of that code is going about things the wrong way, and I don't think this is going to get past a committer as it stands", how can you write that up in a way that's actually helpful?
(The last is where I ended up the one time I decided to have a go at reviewing a PostgreSQL patch. So I just said nothing and waited for an experienced reviewer to tell the author to rewrite it, which happened a month or three later.)
yes, contributing is difficult
> an unstructured mailinglist
the main barrier to entry is not the lack of simple issue tracker though!
<rant>with something so well engineered, so visible each day to users (performance,features) and invisible to users (implementation), so portable (OS,arch) and so just .. careful.. The mental models needed to make meaningful changes to the code base, are so layered and detailed, the issue tracker is just as plain paper envelope as it can be ! If you dont know your bugs you shouldn't be here! so the gruff, take-no-prisoners engineering attitude goes .. and there is plenty of that in PostgreSQL, seems to me
On the other hand, modern FOSS plus dropping boomers, relays the actual fact that no, you do not have to get the "my patch was rejected by Tom" t-shirt to participate and IMPROVE the project. Its just that, this has not always been the culture, and now, maybe there are winds of change.
Every single core PG engineer today will pass away one day. PG is dead - long live PG ! yes, make the issue tracker but also, learn your bugs if you are seriously contributing at the core.
This means a structured list of what to do.
There’s a todo-wiki with some links to mailing threads of years old.
With unaccepted patches without explanation what’s wrong.
If you want an engineer to help, don’t require him to be a PM
1. FROM, 2. WHERE, 3. SELECT
1. SELECT, 2. FROM, 3. WHERE
I agree that it's kinda weird, though. Every time I need to spend serious time in SQL I end up having to re-learn how to think "inside out", for that and other reasons.
e.g.: If the query starts with "SELECT" I can use the SELECT parser. If it starts with "UPDATE" I can use the UPDATE parser and so on.
With FROM/WHERE/SELECT you can no longer do that. So there's a cost... but to be honest, it's worth it in my opinion.
It would amount to little more than a change to the build script, to change "gcc" to "g++", and then the project could immediately begin updating incrementally. New code could use all the modern conveniences.
The Gcc and Gdb projects both started this way sometime back, and it has been a stellar success. The common experience when preferring latest language features, whenever there is a choice, is that when the compiler is satisfied, the code is right.