Thread: Suggestions for first contribution?

Hi guys,

Can anyone suggest a project for my first PG contribution?

My first two ideas didn't pan out:  Yury doesn't seem to need help
with CMake, and the TODO list's "-Wcast-align" project (now deleted)
appeared impractical.

I can continue trying things from the TODO list, but if someone knows
of a project that's definitely worth doing, all the better.

I'd prefer doing back-end coding, but I'm flexible.  The only two
caveats are: (1) I can't work on speedup-focused changes without my
employer's permission, and (2) I only have access to Linux boxes.

Any advice would be greatly appreciated.

Kind regards,
Christian

On Mon, Sep 05, 2016 at 01:25:03PM -0400, Christian Convey wrote:
> Hi guys,
> 
> Can anyone suggest a project for my first PG contribution?

How about adding PIVOT tables?  MS SQL Server and Oracle both have
them.  If you're interested, I have some ideas about the UI parts and
a few about the implementation.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Hello, Christian

> Can anyone suggest a project for my first PG contribution?

In my experience good starting points are:

* Doing code review. It's really important for PostgreSQL project. Everyone likes to write code, no one likes to read
ortest it :)
 
* Finding typos, there are a lot of them.
* Finding bugs: static code analysis, sanitizers, etc. Also subscribe to pgsql-bugs@ mailing list.
* Fixing bottlenecks. Tricky part here is to find one. Could be difficult unless you are working for a company with
manyclients or maintain a project that uses PostgreSQL.
 

Also please note that such activity as answering questions on IRC or in
pgsql-general@, highlighting project news in your blog, writing articles
(or maybe even a book) about PostgreSQL internals, organizing local user
group, etc - all of this are very significant contributions.

Good luck!

-- 
Best regards,
Aleksander Alekseev

Thanks everyone for the suggestions.

It sounds like the most useful thing I can do at the moment is perform
code reviews.  I assumed I'd need more experience with the PG code
base, but I keep on reading that newcomers' reviews are welcome.
Unless someone has a better idea, I'll start with that.

The projects that Pavel and David mentioned sound very interesting.
Hopefully I can tackle one of them after I've done a few code reviews.

Thanks again,
Christian


On Tue, Sep 6, 2016 at 4:20 AM, Aleksander Alekseev
<a.alekseev@postgrespro.ru> wrote:
> Hello, Christian
>
>> Can anyone suggest a project for my first PG contribution?
>
> In my experience good starting points are:
>
> * Doing code review. It's really important for PostgreSQL project.
>   Everyone likes to write code, no one likes to read or test it :)
> * Finding typos, there are a lot of them.
> * Finding bugs: static code analysis, sanitizers, etc. Also subscribe to
>   pgsql-bugs@ mailing list.
> * Fixing bottlenecks. Tricky part here is to find one. Could be
>   difficult unless you are working for a company with many clients or
>   maintain a project that uses PostgreSQL.
>
> Also please note that such activity as answering questions on IRC or in
> pgsql-general@, highlighting project news in your blog, writing articles
> (or maybe even a book) about PostgreSQL internals, organizing local user
> group, etc - all of this are very significant contributions.
>
> Good luck!
>
> --
> Best regards,
> Aleksander Alekseev

On Tue, Sep 06, 2016 at 01:32:10PM -0400, Christian Convey wrote:
> It sounds like the most useful thing I can do at the moment is perform
> code reviews.  I assumed I'd need more experience with the PG code
> base, but I keep on reading that newcomers' reviews are welcome.
> Unless someone has a better idea, I'll start with that.

That is a good choice.  Thanks for getting involved in this way.

On 7 September 2016 at 10:54, Noah Misch <noah@leadboat.com> wrote:
> On Tue, Sep 06, 2016 at 01:32:10PM -0400, Christian Convey wrote:
>> It sounds like the most useful thing I can do at the moment is perform
>> code reviews.  I assumed I'd need more experience with the PG code
>> base, but I keep on reading that newcomers' reviews are welcome.
>> Unless someone has a better idea, I'll start with that.
>
> That is a good choice.  Thanks for getting involved in this way.

Yeah, code review is hard when you don't know the codebase, but it's
also a good way to learn it.

A reviewer who doesn't already know the part of the code of interest
well is in a good position to say "hey, this makes no sense unless you
know that X, Y, Z and 42, maybe you should have a comment here so the
next reader doesn't have to spend 4 hours studying calls through three
different subsystems to figure it out?" . That's actually quite nice
for maintainability, though obviously we can't describe everything in
detail everywhere, there has to be a balance.

Sometimes you'll also ask "dumb" questions that force someone to
explain assumptions they'd made... and in the process figure out that
actually their assumptions don't fit reality / make sense. I certainly
find myself writing "well, it does X" explanations then figure I
should re-check, go read the code and find out that actually ... no,
not so much.

The main thing that's hard is knowing where to look to start learning
about the basic subsystems you need to know and the ones a particular
patch touches on. fmgr, relcache/syscache (and invalidation, oh fun),
how the whole Datum variant business works, memory contexts, PGPROC,
walsenders and walreceivers, startup process, bgwriter, checkpointer,
bgworkers, latches and LWLocks, shmem and private memory and
copy-on-write postmaster memory, elog/ereport(...) and longjmp() error
unwinding, visibility/xmin/xmax/cmin/cmax, infomask/hintbits/locks,
SLRUs and clog, multixacts and comboxacts, low level heap/index access
routines, the SPI, the parser/rewriter/planner and its subsystems like
inheritance_planner, extensions, timelines, logical decoding, slots,
.... etc etc. We really could use a developer's primer. The current
developer docs and scattered READMEs are nice for what they cover, but
somewhat spotty. That said, who's volunteering? Nope nope nope! Though
I am trying to blog about various subsystems occasionally.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

Here is another idea for a contribution - refactoring.

Currently there are a lot of procedures in PostgreSQL code that
definitely don't fit on one screen (i.e. ~50 lines). Also many files are
larger than say 1000 lines of code. For instance, psql_completion
procedure is more than 2000 lines long! I think patches that would make
such code easier to read would have a good chance to be accepted.

In case you are interested I wrote a script that scans PostgreSQL code
and then prints procedures names and corresponding number of lines of
code (see attachment).

--
Best regards,
Aleksander Alekseev

Christian Convey wrote:
> Yury doesn't seem to need help
> with CMake
Hello.
I am sorry that the only answer is now.
I need help but with write CMake code:
1. Make ecpg tests
2. Make MinGW/Msys support
3. many many .......
all targets and discussion here:
https://github.com/stalkerg/postgres_cmake/issues

If you can only test CMake for Ubuntu x86_64 that it is not necessary.
If I not fully understand you - sorry.



--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

> On 05 Sep 2016, at 20:25, Christian Convey <christian.convey@gmail.com> wrote:
>
> Hi guys,
>
> Can anyone suggest a project for my first PG contribution?
>
> My first two ideas didn't pan out:  Yury doesn't seem to need help
> with CMake, and the TODO list's "-Wcast-align" project (now deleted)
> appeared impractical.

There is also a list of projects for google summer of code: https://wiki.postgresql.org/wiki/GSoC_2016

That topics expected to be doable by a newcomer during several months. It is also slightly
outdated, but you always can check current state of things by searching this mail list on interesting topic.

Also postgres have several internal API’s like fdw[1] or gist[2] that allows you to implements something
useful without digging too much into a postgres internals.

[1] https://www.postgresql.org/docs/current/static/fdwhandler.html
[2] https://www.postgresql.org/docs/current/static/gist-extensibility.html

--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

On Wed, Sep 07, 2016 at 05:14:44PM +0300, Aleksander Alekseev wrote:
> Here is another idea for a contribution - refactoring.

Refactoring is not a good early contribution.  Refactoring is more likely to
succeed once you internalize community code practices through much study of
functional patches.  However, even committer-initiated refactoring has a high
failure rate.

On Wed, Sep 7, 2016 at 10:14 AM, Aleksander Alekseev
<a.alekseev@postgrespro.ru> wrote:
> Here is another idea for a contribution - refactoring.
>
> Currently there are a lot of procedures in PostgreSQL code that
> definitely don't fit on one screen (i.e. ~50 lines). Also many files are
> larger than say 1000 lines of code. For instance, psql_completion
> procedure is more than 2000 lines long! I think patches that would make
> such code easier to read would have a good chance to be accepted.

Thanks for the suggestion!  I can see how refactoring could make a lot
of sense for some functions.  That's probably a task I'd want to take
on after I had more experience with PG's code base.  I think being
familiar with most/all of PG's code would make that task go more
smoothly.

- Christian

On Wed, Sep 7, 2016 at 10:34 AM, Yury Zhuravlev
<u.zhuravlev@postgrespro.ru> wrote:
> Christian Convey wrote:
>>
>> Yury doesn't seem to need help
>> with CMake
>
> Hello.
> I am sorry that the only answer is now.
> I need help but with write CMake code:
> 1. Make ecpg tests
> 2. Make MinGW/Msys support
> 3. many many .......
> all targets and discussion here:
> https://github.com/stalkerg/postgres_cmake/issues
>
> If you can only test CMake for Ubuntu x86_64 that it is not necessary.
> If I not fully understand you - sorry.

Hi Yury, no problem.  It sounds like most of the platform testing you
want requires hardware I don't have, unfortunately.

- Christian

On Wed, Sep 7, 2016 at 10:44 AM, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
> There is also a list of projects for google summer of code: https://wiki.postgresql.org/wiki/GSoC_2016
>
> That topics expected to be doable by a newcomer during several months. It is also slightly
> outdated, but you always can check current state of things by searching this mail list on interesting topic.
>
> Also postgres have several internal API’s like fdw[1] or gist[2] that allows you to implements something
> useful without digging too much into a postgres internals.
>
> [1] https://www.postgresql.org/docs/current/static/fdwhandler.html
> [2] https://www.postgresql.org/docs/current/static/gist-extensibility.html

Thanks Stas, I'll have a look at those.  I appreciate the links.

- Christian