Albe & Joshua, thanks for the advice. I am in the process of deciding what to
work on and am looking at the TODO list. I definitely do not intend to work in a
vacuum :-) I am really excited about this and look forward to being challenged and
learning a lot.
Regards
Ashish
On Mon, 7 Dec 2009, Joshua Tolley wrote:
On Mon, Dec 07, 2009 at 09:53:32AM +0100, Albe Laurenz wrote:
abindra wrote:
Next quarter I am planning to do an Independent Study course
where the main objective would be to allow me to get familiar
with the internals of Postgres by working on a project(s). I
would like to work on something that could possibly be
accepted as a patch.
This is (I think) somewhat similar to what students do during
google summer and I was hoping to get some help here in terms of:
1. A good project to work on for a newbie.
2. Would someone be willing to be a mentor? It would be nice
to be able to get some guidance on a one-to-one basis.
I would start with the TODO list: http://wiki.postgresql.org/wiki/Todo
These are things for which there is a consensus that it would be
a good idea to implement them. Pick things that look interesting to
you, and try to read the discussions in the archives that lead
to the TODO items.
I agree the TODO list is a good place to start. Other good sources include the
-hackers list and comments in the code. I was surprised when I began taking an
interest in PostgreSQL how rarely interesting projects mentioned on -hackers
made it into the TODO list; I've come to realize that the TODO contains, in
general, very non-controversial items everyone is pretty sure we could use,
whereas -hackers ranges freely over other topics which are still very
interesting but often more controversial or less obviously necessary.
Committed patches both large and small address TODO list items fairly rarely,
so don't get too hung up on finding something from the TODO list alone.
Bring the topic up in the hackers list, say that you would like
to work on this or that TODO item, present your ideas of how you
want to do it. Ask about things where you feel insecure.
If you get some support, proceed to write a patch. Ask for
directions, post half-baked patches and ask for comments.
That is because you will probably receive a good amount of
critizism and maybe rejection, and if you invest a couple of
months into working on something that nobody knows about *and*
your work gets rejected, that is much worse than drawing fire
right away.
+1. Especially when developing a complex patch, and especially when you're new
to the community, you need to avoid working in a vacuum, for social as well as
technical reasons. The more complex a patch, the more consensus you'll
eventually need to achieve before getting it committed, in general, and it
helps to gain that consensus early on, rather than after you've written a lot
of code. The keyword "proposal" might be a useful search term when digging in
the -hackers archives for historical examples.
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
