Re: Seeking Google SoC Mentors - Mailing list pgsql-hackers

On Tue, Feb 27, 2007 at 12:47:14AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > Yes, but the list being discussed is SoC projects that the community
> > would like to see done, which means most people would assume that #1
> > isn't an issue.
> 
> > We need to make sure that every project on the list of SoC ideas is
> > supported by the community.
> 
> Agreed, except that in most cases a one-liner description of an idea
> isn't enough to get a meaningful reading on whether people think it's
> sane or not.  To take our current example: do you think a one-liner
> description of full disjunctions would have gotten any feedback, except
> for requests for more detail?
> 
> I'm not sure how we fix that --- laying out every acceptable project
> in great detail in advance won't happen for lack of manpower, and wouldn't
> be a good idea even if we could do it, because that sounds like a great
> way to stifle creativity.  At the same time we can hardly promise to
> accept every wild-west idea that someone manages to turn into some kind
> of code.  What can we tell the students other than "get as much feedback
> as you can, as early as you can"?

I agree we certainly don't want to go designing these projects in
advance, but I think we could at least ensure that the community buys
into the concept of each project. ISTM one of the big issues with FD is
that most people didn't even really understand what exactly it was or
how it might be useful, which made getting broad acceptance even harder.

For example, these TODOs seem like they have good acceptance by the
community (though they might not be good SoC projects for other
reasons):
Simplify ability to create partitioned tables
Allow auto-selection of partitioned tables for min/max() operations
Allow commenting of variables in postgresql.conf to restore them to
defaults

Examples of ideas that might not be good because it's unclear that the
community supports them:
Stop-on-a-dime partial vacuum
Adding a replication solution to the backend
Putting time travel support back in

Granted, the 'not good idea' list is pretty exaggerated simply because
it's not as easy to find examples of that on the TODO list, since stuff
on the TODO list is generally supported. Some of the 'temporal database'
items that had been suggested probably fall into the category of 'might
be a good idea, but the community hasn't decided that yet'. So maybe we
should be limiting SoC projects to stuff that's already on the TODO
list..
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)