Thread: Seeking Google SoC Mentors
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.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
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
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
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
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] 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/ > From each according to his ability. To each according to his ability to litigate.
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/