[cfe-dev] [GSoC] General Information
Madhur Amilkanthwar via cfe-dev
cfe-dev at lists.llvm.org
Tue Apr 26 04:55:03 PDT 2016
+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> 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
> We will establish a website on 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
> Tobias (on behalf of the LLVM GSoC Mentors)
> cfe-dev mailing list
> 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. *
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev