Seeking Google SoC Mentors

Josh Berkus wrote:

The next Summer of Code is just around the corner.

Last year, we had 46 submissions and seven we accepted. Out of the SoC we got
two ongoing contributors, several good patches, two code refactors and even
an employee for a PostgreSQL company. I'd like to see us do the same this
year!

Therefore, we need volunteer mentors. Here's how it works:

-- You help review and rate submissions in March.
-- From May-August, you mentor one or two SoC students in working on
PostgreSQL patches. This means that you must be readily available to your
student(s) during this summer and have time (2-5 hours per week, more at the
beginning) to coach them.
-- You need to evaluate the student's progress both midsummer and on
completion.
-- You prepare the student code for submission as an 8.4 feature, if
applicable.
-- Around October, Google gives SPI $500 for your mentoring. You can choose
to take this money (less transaction fees) or leave it as a donation. You
also get a nifty t-shirt.

We're looking for mentors who are:
-- patient
-- available
-- knowledgeable in depth in some particular area/add-in to PostgreSQL
-- interested in reviewing student code
-- interested in helping create the next generation of contributors

Particularly we'd like people who can mentor on:
-- PostgreSQL internals
-- GIS
-- applications & client tools
-- advanced indexing
-- XML
... based on last year's submissions, but there will be more this year.

Also, I am looking for contacts at universities where I can direct notices
when SoC opens.

E-mail me ASAP.

Is there a list of projects? Or can we suggest some?

cheers

andrew

On 2/26/07, Andrew Dunstan <andrew@dunslane.net> wrote:

Josh Berkus wrote:

The next Summer of Code is just around the corner.

Last year, we had 46 submissions and seven we accepted. Out of the SoC we got
two ongoing contributors, several good patches, two code refactors and even
an employee for a PostgreSQL company. I'd like to see us do the same this
year!

Therefore, we need volunteer mentors. Here's how it works:

-- You help review and rate submissions in March.
-- From May-August, you mentor one or two SoC students in working on
PostgreSQL patches. This means that you must be readily available to your
student(s) during this summer and have time (2-5 hours per week, more at the
beginning) to coach them.
-- You need to evaluate the student's progress both midsummer and on
completion.
-- You prepare the student code for submission as an 8.4 feature, if
applicable.
-- Around October, Google gives SPI $500 for your mentoring. You can choose
to take this money (less transaction fees) or leave it as a donation. You
also get a nifty t-shirt.

We're looking for mentors who are:
-- patient
-- available
-- knowledgeable in depth in some particular area/add-in to PostgreSQL
-- interested in reviewing student code
-- interested in helping create the next generation of contributors

Particularly we'd like people who can mentor on:
-- PostgreSQL internals
-- GIS
-- applications & client tools
-- advanced indexing
-- XML
... based on last year's submissions, but there will be more this year.

Also, I am looking for contacts at universities where I can direct notices
when SoC opens.

E-mail me ASAP.

Is there a list of projects? Or can we suggest some?

I'd like to suggest working on a patch testing tool that was discussed
previously. :)

Regards,
Mark

Andrew,

Is there a list of projects? Or can we suggest some?

Suggest away, please!

I'm going to update the website soon, would appreciate new content.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Josh Berkus wrote:

Andrew,

Is there a list of projects? Or can we suggest some?

Suggest away, please!

I'm going to update the website soon, would appreciate new content.

here are a few ideas to be going on with (none of these are new):

buildfarm:

1. Buildfarm web app: is in urgent need of renovation. (perl + postgres
+ template toolkit. might be nice to rework it as a Catalyst app).
2. Buildfarm client: support downloading patches from an approved
server, doing apply, build, install, and test. (perl + maybe SOAP)
3. Buildfarm client + web app: support running performance tests and
reporting on them (start with pgbench) (s/w as above)

postgres core:

4. allow use of LIKE syntax in all type expressions e.g. select * from
mysrf() as (label text, like foo); create type xx as (label text, like bar);

cheers

andrew

On 2/26/07, Josh Berkus <josh@agliodbs.com> wrote:

Andrew,

Is there a list of projects? Or can we suggest some?

Suggest away, please!

I'm going to update the website soon, would appreciate new content.

I can also volunteer to mentor continuing work on a TPC-E kit, for C
stored procedures and improved results reporting.

Mark

On Monday 26 February 2007 14:22, Andrew Dunstan wrote:

Is there a list of projects? Or can we suggest some?

Temporal database support
* base data types
- verify current for ISO compliance (timestamp, interval)
- implement period datatype
* operators for those datatypes
* add support for valid time tables
* add support for transaction time tables
* add support for bi-temporal tables

Check out [1]http://www.cs.arizona.edu/~rts/ for more info.

[1]: http://www.cs.arizona.edu/~rts/

wt
--
Warren Turkal (w00t)

Warren Turkal wrote:

On Monday 26 February 2007 14:22, Andrew Dunstan wrote:

Is there a list of projects? Or can we suggest some?

Temporal database support
* base data types
- verify current for ISO compliance (timestamp, interval)
- implement period datatype
* operators for those datatypes
* add support for valid time tables
* add support for transaction time tables
* add support for bi-temporal tables

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects. I understand Warren's
keenness for this, but it's not clear to me that it has lots of support
elsewhere, and IIRC the idea was rejected by the SQL Standards body. I
don't object to making new data types available, but new table
properties is quite another matter.

So, what exactly are we promising?

cheers

andrew

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Could you also please share your thoughts on what would be a good
student profile- for instance, how much theoretical background and
practical experience, for working on a SoC project?

Demian

The next Summer of Code is just around the corner.

Last year, we had 46 submissions and seven we accepted. Out of the SoC we got
two ongoing contributors, several good patches, two code refactors and even
an employee for a PostgreSQL company. I'd like to see us do the same this
year!

Therefore, we need volunteer mentors. Here's how it works:

-- You help review and rate submissions in March.
-- From May-August, you mentor one or two SoC students in working on
PostgreSQL patches. This means that you must be readily available to your
student(s) during this summer and have time (2-5 hours per week, more at the
beginning) to coach them.
-- You need to evaluate the student's progress both midsummer and on
completion.
-- You prepare the student code for submission as an 8.4 feature, if
applicable.
-- Around October, Google gives SPI $500 for your mentoring. You can choose
to take this money (less transaction fees) or leave it as a donation. You
also get a nifty t-shirt.

We're looking for mentors who are:
-- patient
-- available
-- knowledgeable in depth in some particular area/add-in to PostgreSQL
-- interested in reviewing student code
-- interested in helping create the next generation of contributors

Particularly we'd like people who can mentor on:
-- PostgreSQL internals
-- GIS
-- applications & client tools
-- advanced indexing
-- XML
... based on last year's submissions, but there will be more this year.

Also, I am looking for contacts at universities where I can direct notices
when SoC opens.

E-mail me ASAP.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFF4204Ws7G5iIp9akRAh6yAKCMp3Fy66BsPmsAGQ7i6CwavE2hFQCgoIZG
66zWJUCOweH0LCgQA9NpotA=
=Ea5J
-----END PGP SIGNATURE-----

Demian,

Could you also please share your thoughts on what would be a good
student profile- for instance, how much theoretical background and
practical experience, for working on a SoC project?

Well, it shouldn't be the student's first year writing code. Basically,
they're committing to developing a feature *to completion* in 3 months.
We're going to be evaluating proposals based on whether we think students
can do that.

References of some kind will be important, given that we'll only be
accepting about 12% of proposals. So, some demonstration of the student's
ability to code from either the open source world or previous coursework.

I don't know, honestly, that we care very much about theoretical
background, except where it relates directly to and cutting-edge concepts
in you proposal. PostgreSQL-space is littered with half-completed
academic projects; we're not seeking more of those.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Andrew Dunstan <andrew@dunslane.net> writes:

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.

Um, if you mean are we going to promise to accept a patch in advance of
seeing it, the answer is certainly not. Still, a SoC author can improve
his chances in all the usual ways, primarily by getting discussion and
rough consensus on a spec and then on an implementation sketch before
he starts to do much code. Lots of showstopper problems can be caught
at that stage.

I think the main problems with the FD patch were (1) much of the
community was never actually sold on it being a useful feature,
and (2) the implementation was not something anyone wanted to accept
into core, because of its klugy API. Both of these points could have
been dealt with before a line of code had been written, but they were
not :-(

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.

Um, if you mean are we going to promise to accept a patch in advance of
seeing it, the answer is certainly not. Still, a SoC author can improve
his chances in all the usual ways, primarily by getting discussion and
rough consensus on a spec and then on an implementation sketch before
he starts to do much code. Lots of showstopper problems can be caught
at that stage.

Tom,

Correct me if I am wrong, but would the way that HOT has been handled be
a good way for the SoC people to do things?

Joshua D. Drake

I think the main problems with the FD patch were (1) much of the
community was never actually sold on it being a useful feature,
and (2) the implementation was not something anyone wanted to accept
into core, because of its klugy API. Both of these points could have
been dealt with before a line of code had been written, but they were
not :-(

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

"Joshua D. Drake" <jd@commandprompt.com> writes:

Correct me if I am wrong, but would the way that HOT has been handled be
a good way for the SoC people to do things?

Well, the HOT discussion hasn't yet led to an accepted patch ... and I'd
say its authors still did way too much work before getting the community
involved. But certainly it's a better model to look at than what the
FD author did.

regards, tom lane

On Mon, Feb 26, 2007 at 09:10:38PM -0500, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.

Um, if you mean are we going to promise to accept a patch in advance of
seeing it, the answer is certainly not. Still, a SoC author can improve
his chances in all the usual ways, primarily by getting discussion and
rough consensus on a spec and then on an implementation sketch before
he starts to do much code. Lots of showstopper problems can be caught
at that stage.

I think the main problems with the FD patch were (1) much of the
community was never actually sold on it being a useful feature,
and (2) the implementation was not something anyone wanted to accept
into core, because of its klugy API. Both of these points could have
been dealt with before a line of code had been written, but they were
not :-(

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.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

"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"?

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.

Um, if you mean are we going to promise to accept a patch in advance of
seeing it, the answer is certainly not. Still, a SoC author can improve
his chances in all the usual ways, primarily by getting discussion and
rough consensus on a spec and then on an implementation sketch before
he starts to do much code. Lots of showstopper problems can be caught
at that stage.

We cannot necessarily expect the students to work this way without
guidance if they are not familiar with our processes before they start.
The mentors should be there to guide not just with the technical aspects
of the project, but the procedural as well imho.

Regards, Dave

On Tue, Feb 27, 2007 at 09:21:42AM +0000, Dave Page wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.

Um, if you mean are we going to promise to accept a patch in advance of
seeing it, the answer is certainly not. Still, a SoC author can improve
his chances in all the usual ways, primarily by getting discussion and
rough consensus on a spec and then on an implementation sketch before
he starts to do much code. Lots of showstopper problems can be caught
at that stage.

We cannot necessarily expect the students to work this way without
guidance if they are not familiar with our processes before they start.
The mentors should be there to guide not just with the technical aspects
of the project, but the procedural as well imho.

IIRC, last time we had a pgsql-students (or similar) mailinglist for the
SoC people. That was closed. Perhaps that's a bit counterproductive - it's
better to get introduced to the "normal way of doing things" right away?
With the help of the mentor, of course.

//Magnus

Magnus Hagander wrote:

On Tue, Feb 27, 2007 at 09:21:42AM +0000, Dave Page wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.

Um, if you mean are we going to promise to accept a patch in advance of
seeing it, the answer is certainly not. Still, a SoC author can improve
his chances in all the usual ways, primarily by getting discussion and
rough consensus on a spec and then on an implementation sketch before
he starts to do much code. Lots of showstopper problems can be caught
at that stage.

We cannot necessarily expect the students to work this way without
guidance if they are not familiar with our processes before they start.
The mentors should be there to guide not just with the technical aspects
of the project, but the procedural as well imho.

IIRC, last time we had a pgsql-students (or similar) mailinglist for the
SoC people. That was closed. Perhaps that's a bit counterproductive - it's
better to get introduced to the "normal way of doing things" right away?
With the help of the mentor, of course.

Yes. The other issue though is that initial project proposal scoring and
discussion is done on a private Google site by the mentors. I don't know
if we're allowed to make the proposals public before they get accepted
by Google in case the students copy or improve each others proposals.

From their (and Google's) point of view their proposals are essentially

job applications.

Once they've been ranked, and Google have approved the top-N projects I
guess it's open season!

Regards, Dave

On Tue, Feb 27, 2007 at 09:53:41AM +0000, Dave Page wrote:

Magnus Hagander wrote:

On Tue, Feb 27, 2007 at 09:21:42AM +0000, Dave Page wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.

Um, if you mean are we going to promise to accept a patch in advance of
seeing it, the answer is certainly not. Still, a SoC author can improve
his chances in all the usual ways, primarily by getting discussion and
rough consensus on a spec and then on an implementation sketch before
he starts to do much code. Lots of showstopper problems can be caught
at that stage.

We cannot necessarily expect the students to work this way without
guidance if they are not familiar with our processes before they start.
The mentors should be there to guide not just with the technical aspects
of the project, but the procedural as well imho.

IIRC, last time we had a pgsql-students (or similar) mailinglist for the
SoC people. That was closed. Perhaps that's a bit counterproductive - it's
better to get introduced to the "normal way of doing things" right away?
With the help of the mentor, of course.

Yes. The other issue though is that initial project proposal scoring and
discussion is done on a private Google site by the mentors. I don't know
if we're allowed to make the proposals public before they get accepted
by Google in case the students copy or improve each others proposals.
From their (and Google's) point of view their proposals are essentially
job applications.

Right. We'll just have to live by Googles rule for that part, I'm
talking about the discussions later. Once things are approved, they
should all be handled on the standard mailinglists, IMHO.

Being able to make "possibly controversial" suggestiosn public
beforehand would certainly help, but may not be possible. But aren't we
supposed to pick mentors who will know enough to be able to make that
call themselves?

//Magnus

Magnus Hagander wrote:

Right. We'll just have to live by Googles rule for that part, I'm
talking about the discussions later. Once things are approved, they
should all be handled on the standard mailinglists, IMHO.

Oh, 100% agreed.

Being able to make "possibly controversial" suggestiosn public
beforehand would certainly help, but may not be possible. But aren't we
supposed to pick mentors who will know enough to be able to make that
call themselves?

yeah, in theory, but you know how wildly opinions can vary even amongst
the oldest and most familiar of community members.

Regards, Dave

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)

Well, the HOT discussion hasn't yet led to an accepted patch ... and I'd
say its authors still did way too much work before getting the community
involved.  But certainly it's a better model to look at than what the
FD author did.

That's pretty much the mentor's job. I don't remember who mentored FD, but
obviously there wasn't enough guidance.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

On Monday 26 February 2007 18:46, Josh Berkus wrote:

Demian,

Could you also please share your thoughts on what would be a good
student profile- for instance, how much theoretical background and
practical experience, for working on a SoC project?

Well, it shouldn't be the student's first year writing code. Basically,
they're committing to developing a feature *to completion* in 3 months.
We're going to be evaluating proposals based on whether we think students
can do that.

References of some kind will be important, given that we'll only be
accepting about 12% of proposals. So, some demonstration of the student's
ability to code from either the open source world or previous coursework.

I don't know, honestly, that we care very much about theoretical
background, except where it relates directly to and cutting-edge concepts
in you proposal. PostgreSQL-space is littered with half-completed
academic projects; we're not seeking more of those.

Additionally it doesn't hurt to bring up an idea to the community before you
even submit the application. If you get buy in / agreement from multiple
community members on a project now, it can only help your chances in the SoC
process. (Picking items from the TODO list is a good way to start if you need
ideas)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Jim C. Nasby wrote:

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.

Yes, at least for those that go on a suggestion list. And that was my
worry about Warren's suggestion - I haven't seen much enthusiasm for it
from anyone else, so the degree of in-principle buyin is fairly dubious.

cheers

andrew

On Tue, Feb 27, 2007 at 10:49:18AM -0600, Jim C. Nasby wrote:

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.

I think it might be useful to at least encourage people wanting to an
SoC project to create page on the developer wiki selling their idea.
You know, questions like: why do we want it? Where do you expect it to
be included? etc.

That might help catch misunderstandings much earlier.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

I think it might be useful to at least encourage people wanting to an
SoC project to create page on the developer wiki selling their idea.
You know, questions like: why do we want it? Where do you expect it
to be included? etc.

They are expected to do as much when they apply for a project at the
Google site.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/