From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Seeking Google SoC Mentors |
Date: | 2007-02-27 16:49:18 |
Message-ID: | 20070227164917.GI29041@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-students |
On Tue, Feb 27, 2007 at 12:47:14AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-02-27 16:49:44 | Re: Resumable vacuum proposal and design overview |
Previous Message | Tom Lane | 2007-02-27 16:42:17 | 7.x horology regression test on Solaris buildfarm machines |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2007-02-27 17:17:16 | Re: Seeking Google SoC Mentors |
Previous Message | Dave Page | 2007-02-27 10:13:12 | Re: Seeking Google SoC Mentors |