Thread: [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
2016: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
theyhave planned for the summer, and what their time   commitment to the GSoC work will be - A clear statement that
therewill be no intellectual property   problems with the work they will be doing -- that the PostgreSQL   community
willbe able to use their work without encumbrances   (e.g., there should be no agreements related to prior or   ongoing
workwhich 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.

Hi, Kevin.

I've finished a draft proposal for "Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions".
Youcan 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

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

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

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
serializabletransactions
 
> 
> 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

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

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
aquick 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
wouldtake. 
 


> -----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
serializabletransactions
 
> 
> 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

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

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