Guidelines for GSoC student proposals

Started by Kevin Grittneralmost 9 years ago9 messages
#1Kevin Grittner
kgrittn@gmail.com

I've found various sources that give hints about what a student
proposal should look like, but nothing I could just give as a link,
so I pulled together what I could find, tempered by my own ideas and
opinions. I suggest that we send the below, or something like it to
each student who expresses interest in making a proposal, or who
submits a proposal that doesn't meet the below guidelines. Thoughts
or suggestions for changes before we do? Remember, time is short,
so this cannot be a 200 message bike-shedding debate -- we just need
to provide some sort of guidance to students in a timely way, with
the timeline being:

February 27 - March 20
Potential student participants discuss application ideas with
mentoring organizations
March 20 16:00 UTC
Student application period opens
April 3 16:00 UTC
Student application deadline

Each GSoC student proposal should be a PDF file of 6 to 8 pages. In
the end, Google will publish these documents on a web page, so the
student should make each proposal something which they will be happy
to have future potential employers review.

Some ideas for desirable content:

- A resume or CV of the student, including any prior GSoC work
- Their reasons for wanting to participate
- What else they have planned for the summer, and what their time
commitment to the GSoC work will be
- A clear statement that there will be no intellectual property
problems with the work they will be doing -- that the PostgreSQL
community will be able to use their work without encumbrances
(e.g., there should be no agreements related to prior or
ongoing work which might assign the rights to the work they do
to someone else)
- A description of what they will do, and how
- Milestones with dates
- What they consider to be the test that they have successfully
completed the project

Note that a student proposal is supposed to be far more detailed
than the ideas for projects provided by the organization -- those
are intended to be ideas for what the student might write up as a
proposal, not ready-to-go proposal documents.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Mengxing Liu
liu-mx15@mails.tsinghua.edu.cn
In reply to: Kevin Grittner (#1)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Hi, Kevin.

I've finished a draft proposal for "Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions". You can find it from GSOC website or by the link below.
https://docs.google.com/document/d/17TAs3EJIokwPU7UTUmnlVY3ElB-VHViyX1zkQJmrD1A/edit?usp=sharing

I was wondering if you have time to review the proposal and give me some comments?

-----Original Messages-----
From: "Kevin Grittner" <kgrittn@gmail.com>
Sent Time: 2017-03-17 21:57:18 (Friday)
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Cc:
Subject: [HACKERS] Guidelines for GSoC student proposals

I've found various sources that give hints about what a student
proposal should look like, but nothing I could just give as a link,
so I pulled together what I could find, tempered by my own ideas and
opinions. I suggest that we send the below, or something like it to
each student who expresses interest in making a proposal, or who
submits a proposal that doesn't meet the below guidelines. Thoughts
or suggestions for changes before we do? Remember, time is short,
so this cannot be a 200 message bike-shedding debate -- we just need
to provide some sort of guidance to students in a timely way, with
the timeline being:

February 27 - March 20
Potential student participants discuss application ideas with
mentoring organizations
March 20 16:00 UTC
Student application period opens
April 3 16:00 UTC
Student application deadline

Each GSoC student proposal should be a PDF file of 6 to 8 pages. In
the end, Google will publish these documents on a web page, so the
student should make each proposal something which they will be happy
to have future potential employers review.

Some ideas for desirable content:

- A resume or CV of the student, including any prior GSoC work
- Their reasons for wanting to participate
- What else they have planned for the summer, and what their time
commitment to the GSoC work will be
- A clear statement that there will be no intellectual property
problems with the work they will be doing -- that the PostgreSQL
community will be able to use their work without encumbrances
(e.g., there should be no agreements related to prior or
ongoing work which might assign the rights to the work they do
to someone else)
- A description of what they will do, and how
- Milestones with dates
- What they consider to be the test that they have successfully
completed the project

Note that a student proposal is supposed to be far more detailed
than the ideas for projects provided by the organization -- those
are intended to be ideas for what the student might write up as a
proposal, not ready-to-go proposal documents.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Mengxing Liu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Kevin Grittner
kgrittn@gmail.com
In reply to: Mengxing Liu (#2)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Wed, Mar 22, 2017 at 2:24 AM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:

I've finished a draft proposal for "Eliminate O(N^2) scaling from
rw-conflict tracking in serializable transactions". You can find
it from GSOC website or by the link below.
https://docs.google.com/document/d/17TAs3EJIokwPU7UTUmnlVY3ElB-VHViyX1zkQJmrD1A/edit?usp=sharing

I was wondering if you have time to review the proposal and give me some comments?

Will take a look and give you an initial review in a day or two.

--
Kevin Grittner

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#4Kevin Grittner
kgrittn@gmail.com
In reply to: Mengxing Liu (#2)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Wed, Mar 22, 2017 at 2:24 AM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:

I've finished a draft proposal for "Eliminate O(N^2) scaling from
rw-conflict tracking in serializable transactions".

I've attached some comments to the document; let me know if they
don't show up for you or you need clarification.

Overall, if the comments are addressed, I think it is great.

--
Kevin Grittner

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#5Mengxing Liu
liu-mx15@mails.tsinghua.edu.cn
In reply to: Kevin Grittner (#4)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Thanks for your time. I've updated the proposal according to your comments.
But I am still wondering that can you review it for a double-check to make sure I've made everything clear?
You can read my replies for reference.

-----Original Messages-----
From: "Kevin Grittner" <kgrittn@gmail.com>
Sent Time: 2017-03-25 04:53:36 (Saturday)
To: "Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Wed, Mar 22, 2017 at 2:24 AM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:

I've finished a draft proposal for "Eliminate O(N^2) scaling from
rw-conflict tracking in serializable transactions".

I've attached some comments to the document; let me know if they
don't show up for you or you need clarification.

Overall, if the comments are addressed, I think it is great.

--
Kevin Grittner

--
Mengxing Liu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#6Kevin Grittner
kgrittn@gmail.com
In reply to: Mengxing Liu (#5)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Sat, Mar 25, 2017 at 9:24 PM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:

I've updated the proposal according to your comments.
But I am still wondering that can you review it for a double-check
to make sure I've made everything clear?

Additional comments added.

I'm afraid a few new issues came to mind reading it again. (Nothing
serious; just some points that could benefit from a little
elaboration.)

--
Kevin Grittner

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#7Mengxing Liu
liu-mx15@mails.tsinghua.edu.cn
In reply to: Kevin Grittner (#6)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Thanks, I've updated the proposal. Just one issue:
I agree that we can make skip list a general data structure. But can we use the fixed-level skip list as a Plan B? Or a quick attempt before the general data structure ?
Because I am not familiar with shared memory structure and tricks used in it, and I cannot estimate how much time it would take.

-----Original Messages-----
From: "Kevin Grittner" <kgrittn@gmail.com>
Sent Time: 2017-03-28 00:16:11 (Tuesday)
To: "Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Sat, Mar 25, 2017 at 9:24 PM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:

I've updated the proposal according to your comments.
But I am still wondering that can you review it for a double-check
to make sure I've made everything clear?

Additional comments added.

I'm afraid a few new issues came to mind reading it again. (Nothing
serious; just some points that could benefit from a little
elaboration.)

--
Kevin Grittner

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Mengxing Liu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#8Kevin Grittner
kgrittn@gmail.com
In reply to: Mengxing Liu (#7)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Wed, Mar 29, 2017 at 11:17 PM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:

Thanks, I've updated the proposal. Just one issue:
I agree that we can make skip list a general data structure. But
can we use the fixed-level skip list as a Plan B? Or a quick attempt
before the general data structure ?
Because I am not familiar with shared memory structure and tricks
used in it, and I cannot estimate how much time it would take.

It's not really too bad for fixed allocation shared memory, and I
can help with that. If I thought it would save much I could see
doing a prototype without generalization, but you would still have
most of the same shared memory issues, since the structure *must*
live in shared memory.

--
Kevin Grittner

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#9Mengxing Liu
liu-mx15@mails.tsinghua.edu.cn
In reply to: Kevin Grittner (#8)
Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

I agree that we can make skip list a general data structure. But
can we use the fixed-level skip list as a Plan B? Or a quick attempt
before the general data structure ?
Because I am not familiar with shared memory structure and tricks
used in it, and I cannot estimate how much time it would take.

It's not really too bad for fixed allocation shared memory, and I
can help with that. If I thought it would save much I could see
doing a prototype without generalization, but you would still have
most of the same shared memory issues, since the structure *must*
live in shared memory.

Thank you. If there is no other problem, I will submit the proposal.

--
Mengxing Liu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers