[cfe-dev] [GSoC] General Information
David Come via cfe-dev
cfe-dev at lists.llvm.org
Tue Apr 26 05:04:38 PDT 2016
Emails can be pain to go through afterward.
Creating something like http://llvm.org/gsoc could be a good thing to do.
On 26/04/2016 13:55, Madhur Amilkanthwar via cfe-dev wrote:
> +1 for the introduction part.
> I would request members to explain projects followed by Motivation,
> anticipated challenges, testing methodology, anticipated impact (like
> %speedup etc.). Also, it would be good to archive these docs
> somewhere. I am having hard time to find past projects.
> If we don't have an immediate place for archival then mail is the best
> On Tue, Apr 26, 2016 at 11:00 AM, Tobias Grosser via cfe-dev
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Dear LLVM summer of code students,
> let me congratulate you to your successful application!
> After your participation has been announced, its now time to start
> with community bounding as preparation of the actual project start
> on 23 May. To ensure your GSoC becomes a large success, I wrote
> down some general information that has proven important in
> previous years.
> # GSoC and the LLVM community
> Besides your individual project goals, the primary objective of
> your GSoC project is to establish yourself as a full and active
> member of the LLVM community. It is your job to get in touch with
> the LLVM community and to develop your project as part of the LLVM
> community. This means you are invited to discuss your ideas with
> the LLVM community, to submit your patches for public code review,
> and also to participate as code-reviewer for patches that fall in
> your area of expertise and match your level of knowledge. To
> ensure maximal community involvement, LLVM has a well established
> tradition of incremental development and you should follow this
> practice in your
> GSoC project.
> # The role of the mentor
> You have been paired with one (or two) personal mentors, who will
> support you throughout your summer of code project. Your mentor is
> your first point of contact in case of any questions regarding
> your GSoC project. His primary role is to ensure you are
> successfully integrated with the LLVM community by ensuring you
> understand how to discuss project ideas, how to obtain code
> reviews, and generally to help you to understand the informal best
> practices in the LLVM community. In many cases he will also
> provide reviews for your patches, but please keep in mind that he
> is not your proxy to the LLVM community, but you are expected to
> directly interact with the whole community. In the optimal case,
> you learn quickly how to obtain patch reviews yourself and how to
> discuss your ideas with the full LLVM community. Your mentor will
> likely also give feedback, but he is just one out of the many
> people in the community you will be working with.
> Your mentor also evaluates your project and can change project
> milestone if this should become necessary. However, we again suggest
> to discuss changes to your agenda in public.
> # Media of communication
> This email is on-purpose sent to you through the
> LLVM/cfe/safecode/Polly mailing lists. Mailing lists are the
> primary medium of communication for LLVM. Other means such as IRC,
> phone or personal meetings can complement email, but please ensure
> that all important discussions either take part via the mailing
> lists or are mirrored to the mailing lists by posting meeting
> reports or updates.
> # Reporting / Status updates
> To keep people informed about your work, we suggest each student
> to implement regular reporting habits. As email is our primary
> medium of communication, brief weekly status emails can be a nice
> way to get your information out. If you send them before the
> week-end, chances are
> that some of your news show up in LLVM weekly.
> Previous students also often set up a GSoC blog to irregularly post
> larger status updates, performance results, architecture diagrams, ...
> # GSoC administrative issues
> Please use the public mailing lists for all (non-sensitive)
> administrative issues. You are likely not the only one who has
> similar questions/concerns. Having your questions (and the
> solutions) being
> archived and available in search engines will save us time and be of
> great help for all other students.
> # Introducing yourself
> To kick off your personal GSoC of code, we suggest to introduce
> yourself and your project on the relevant mailing list, invite people
> to provide feedback to your project, and communicate your planned
> timeline as well as the media/location and interval you will use
> to report your status.
> # Project description on llvm.org <http://llvm.org>
> We will establish a website on llvm.org <http://llvm.org> that
> lists all accepted LLVM projects. Please add yourself all relevant
> information about your GSoC project. This includes a link to your
> original project draft, reporting interval, blog, personal
> website, ...
> # Community bounding period
> Even though the community bounding period is not yet the actual
> project, it is of high importance to make your actual project a
> success. Within the next four weeks, you should make sure you get
> a good feeling how the LLVM community works and you should make
> your first steps towards becoming a member of the community. This
> means now is the time to start discussions about your work, but
> also to get a good feeling of the LLVM development practices. Some
> of you already contributed patches to LLVM. Whoever has not should
> make sure to contribute a (smaller) patch as soon as possible. We
> previously had some students who mostly skipped the community
> bounding period and they often had to spend time on
> administrative/infrastructure issues after the actual project
> phase started, which caused stress and delays throughout their
> GSoC. On day one of the project phase, you should be able to focus
> on writing code and pushing first patches through code reviews.
> Your coding environment should already be set up, you should have
> a solid understanding of all tools you are planning to use, you
> should know how patches need to be prepared for smooth review, and
> you should understand the patch submission and review habits of
> LLVM. Similarly, your development plan should have been discussed
> with the community, your reporting should be set up and announced,
> and the only thing missing is you going full in on your project.
> The community bounding period is the time where you get up to
> speed on these administrative/community issues.
> # LLVM developer meeting
> The LLVM Community has a large developer meeting on November 3-4
> in San Jose, CA. We encourage you to present your work at the LLVM
> Developers’ Meeting. Presenting your work is a great way to get
> exposure and gives you the opportunity to meet many LLVM
> developers’ in person. There are many different ways to present
> your work: technical talk, poster, or lightning talk. Funding to
> attend the LLVM Developers’ Meeting may be available through the
> LLVM Foundation and more details on this will be available in the
> coming months. Travel to the meeting may require a passport or
> VISA, and we recommend investigating your travel document
> requirements well in advance.
> Tobias (on behalf of the LLVM GSoC Mentors)
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> /Disclaimer: Views, concerns, thoughts, questions, ideas expressed in
> this mail are of my own and my employer has no take in it. /
> Thank You.
> Madhur D. Amilkanthwar
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev