Re: Learning curves and such (was Re: pgFoundry)

On Tue, May 17, 2005 at 09:23:42PM +1000, Russell Smith wrote:
>
> > I think it might also be valuable to have a list of things that are good
> > 'starter projects'. Maybe some indication of TODO items that are
> > simpler. Possibly a list of bugs, too.
>
> As someone who has looked at hacking the pg code, I agree it is
> difficult to know what to look at to get started. I love fixing bugs,
> but I'm used to the bug tracker type situation and being able to find
> something that looks relatively easy. That is how I've started on a
> number of other projects. With no formal bug tracker, I'm not sure
> what bugs I could look at. I have talked to some people on IRC about
> tackling the infinite date issue, but was warned off that, as the
> date/time code is a scary place.

I'd say the datetime code is a good place to start, the most important
characteristic being that it's self contained.

> It would be useful to outline positions that are actually available
> for people to take. It's easy to give a general list. I've asked and
> seen may like it. For me, what does helping with advocacy mean? What
> should be performance tested (I assume new code, like the bitmap
> scan).

Yes, performance testing may also show some implementation bugs that are
important to find too. Stress-testing is important too. Or find corner
cases, push implementation limits, etc.

Or, find some area that people mentions as needing testing, the current
example being SIGTERM handling in busy backends.

> But at the same time, how do I not get into something that is
> being duplicated by somebody else?

Tell -hackers. But if you are going to do testing, it doesn't matter
there is multiple people doing it.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"The first of April is the day we remember what we are
the other 364 days of the year" (Mark Twain)