Re: [lldb-dev] [cfe-dev] lists.llvm.org server maintenance, Friday Dec 18 @10:30 PST
On 12/19/15 1:33 AM, Tanya Lattner via cfe-dev wrote: The server maintenance is complete and lists should be operational. Thanks, Tanya! Regards, John Criswell Thanks, Tanya On Dec 17, 2015, at 12:06 PM, Tanya Lattner wrote: All, The server that runs the mailing lists will be down for maintenance starting Friday Dec 18th at 10:30PM PST. I do not expect a long downtime, but please keep this in mind if you see any issues with the lists during this period. I will send an email once I am finished. No other services should be affected. Thanks, Tanya ___ cfe-dev mailing list cfe-...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] GitHub anyone?
Dear Renato, Do you have a set of volunteers lined up to do such a migration? Getting people willing to do the migration will obviously be key, and that was the one thing I didn't see in the original email. Regarding the issue of git sub-modules and keeping Clang/LLVM in sync, perhaps we should just put Clang and LLVM into a single git repository and add a CMake option to disable compilation of Clang (the same could be done for other LLVM sub-projects for which bisection and other nifty features require a single revision number to refer to code across projects). Keeping these projects in separate repositories is just more work, and I don't see what we're getting out of that extra effort. IIRC, Clang was initially separate from LLVM because it significantly added to the download time and compilation time. I don't think download time is really a problem anymore, and compilation time can be fixed with a CMake option. For what it's worth, John Criswell On 5/31/16 2:31 PM, Renato Golin via cfe-dev wrote: Folks, There has been some discussion on IRC about SVN hosting and the perils of doing it ourselves. The consensus on the current discussion was that moving to a Git-only solution would have some disvantages, but many advantages. Furthermore, not hosting our own repos would save us a lot of headaches, admin costs and timed out connections. TL;DR: GitHub + git submodules [1] could replace all the functionality we have currently with SVN. (also GitLab, BitBucketc, etc). Here are some of the arguments made on IRC... 1. Due to SVN, we can't re-write history. If we use some GitHub properties [2], we could have the same effect. 2. Due to SVN, we have a mandatory time sequence, so commits go first in LLVM, then Clang (for example), and buildbots don't get lost. If we use submodules [1], we can have a similar relationship, but in a more explicit way, and the problem could be solved elegantly. 3. Some people still can only use SVN. For that, GitHub has an SVN interface [3] to the repositories. 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator, etc. Not only this incurs in additional admin cost, but it also gets outdated, locally modified, and it needs to be backed up, etc. GitHub gives all that for us for free. 5. We can still use Bugzilla (and lock GitHub's own bug system), but we can also use GitHub's system to manage releases (it's actually quite good for that). 6. GitHub has automated testing of merge requests, meaning we can have pre-commit tests enabled on a set of fast bots, triggered by GitHub's own validation hooks. Even though that wouldn't cover everything, having a few pre-commit bots would considerably reduce the need to revert patches [citation needed]. 7. With git submodules, we'd probably want to follow the same style we have today (llvm-projects/) instead of modelling how they look in tree (llvm/tools/clang still as a symlink). 8. Once we're solo Git, we can shop around *much* more easily. By using SVN, we're basically forced to host, or choose Source Forge. Using just Git, we can choose GitLab, BitBucket and many others, if GitHub is not appealing enough. Essentially, it doesn't matter where you are, the tools are good, there and largely replaceable [citation needed]. What do people think? Any issue not covered that we should? How would that disrupt downstream users? Would it be a temporary disruption, but with long lasting benefits? Or will it just break everything for you? cheers, --renato [1]https://git-scm.com/book/en/v2/Git-Tools-Submodules [2]https://help.github.com/articles/defining-the-mergeability-of-pull-requests/ [3]https://help.github.com/articles/support-for-subversion-clients/ ___ cfe-dev mailing list cfe-...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
On 2/17/17 1:16 AM, Mehdi Amini via lldb-dev wrote: Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also contributors to the LLVM project (or user/advocate of LLVM for building other cool projects). A key part of the process is about how do we select the projects. The way we’ve done it last year, is that the volunteer mentors shared an email thread and ultimately each one individually ranked the projects. We kept the average grading for each project to ranked them overall. In order to make the process more transparent to student applicants, we want to formalize and announce the criteria for ranking and selection project. The purpose of this email is to gather community feedback about the criterion that mentors should apply when ranking projects, for example: - Should we favor a student which has past contributions to LLVM compared to a newcomer? Is it more important or as equally important as the quality of the proposal? Historically, we have opted for students with previous LLVM experience because they are more likely to make progress and complete their project. For most projects, this makes sense. However, it does have the downside of attracting students that are already "on board" with LLVM; it doesn't introduce new developers to the LLVM community. We therefore might want to devise projects that would fit beginner developers. For example, a proposal that aims to fix a set of bugs might work. - How should we rank (if any) “research or unbounded projects” vs “project with an immediate application”? Should we strive to keep a balance? We should strive to keep a balance. The important factor is getting students to either improve the existing LLVM software or to build cool tools using LLVM. We want to grow the LLVM community, and both the software development and research communities are important. I also believe that research projects and open-ended projects can provide long-term gains even if they don't provide immediate short-term benefits. Remember that LLVM itself was once a research project. If we keep a balance, then we will have a nice mix of short-term, low risk projects and projects that contribute to longer-term, higher risk goals. - What about “projects that touch LLVM/Clang/…” vs “projects that are building something on top of LLVM”? (For example this project was first proposed to be selected by LLVM before being rejected and finally picked by the Julia project directly: https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ )? We should encourage proposals that build something *with* LLVM/Clang/etc. as well as projects that improve the core compiler infrastructure. Part of LLVM's appeal is that one can build *a lot* of tools with it. We want to encourage students to use LLVM to build interesting things. In some cases, we will have overlap with other communities (the Julia and FreeBSD communities come to mind). I think that's fine. - Should we ask that the work is done upstream all along? In the past there have been project developed on GitHub outside the community that have never been merged. The LLVM developer policy has a full section insisting on incremental development ( http://llvm.org/docs/DeveloperPolicy.html#incremental-development ). It depends on the project. Projects that enhance the core infrastructure should probably follow the developer policy and contribute upstream. Projects that are "trying out" a new idea or are research-oriented should probably not worry about working upstream; why upstream if you don't even know if what you're trying to do is going to work? Hopefully we should be able to provide a set of guidelines to student that would help them fill the best application, and avoid unfortunate surprise at the end of the process. I think what actually makes a strong proposal is whether the student presents a good idea, whether the proposal convinces the reader that the student will be able to perform the work, and whether there is a mentor interested in the project. If you have these three things, then you have a project that is more likely to achieve its goals and grow the LLVM community. Regards, John Criswell -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
