Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On 1 Jun 2016, at 17:02, John Criswell via llvm-dev wrote: > > 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. The thing that we’d gain by keeping them together is not breaking all of the people who have forks of the clang git repo. GitHub tracks 563 so far. David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers
On 13 Jun 2016, at 14:14, Rafael Espíndola via cfe-dev wrote: > >> The 4.1 release gives us the opportunity to drop support for 3.x >> bitcode formats, so I don't think we should move to 4.x until we have >> older bitcode features that we really want to drop. There should >> probably be a separate discussion thread about this. > > It give the opportunity, not the obligation. Given that I think it is > an independent issue and would suggest we just keep the revisions > simple and switch trunk to 4.0. I don’t think that this makes it simple for anyone. Existing packaging tools understand dot notation and know that 3.10 > 3.9, even if interpreting the dot as a decimal point would mean that it didn’t. Without this kind of special handling, they’d be very confused by 3.4.1, which isn’t even a valid number. LLVM minor revisions break ABI and API compatibility and bugfix revisions don’t. There is an expectation that major revisions will break the bitcode format, so releasing a 4.0 version but saying ‘this one doesn’t actually break it’ will be confusing. Particularly if we then release a 5.0 that does, after a 4.5 that doesn’t. That said, in general I’d prefer if we used semantic versioning and stopped releasing major versions with a bump of the minor version number. David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.9 Release] Release plan and call for testers
On 13 Jun 2016, at 15:24, Robinson, Paul via llvm-dev wrote: > > +1. My understanding is that 2.9->3.0 came with some huge internal changes > (overhaul of the type system, maybe? this slightly predates my involvement > with LLVM so I'm not entirely sure) and warranted a major-version change > regardless of the .9->.0 thing. 1->2 also came with a fairly fundamental change (removal of signed and unsigned integer types, addition of signed and unsigned integer operations). > I don't think 3.10 should be confusing to anyone, really. The version > number is a tuple, not a string or a decimal fraction. Agreed. David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 Jun 2016, at 15:03, Renato Golin via llvm-dev wrote: > > Any more comments before we put this proposal to vote? Thank you very much for driving all of this. I just have one quick question: Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub continue to work by simply switching the remote in the config? David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-foundation] [llvm-dev] [cfe-dev] Sequential ID Git hook
On 4 Jul 2016, at 12:13, Renato Golin via llvm-foundation wrote: > > And since tagging *every* commit doesn't scale for long ranges, and > anything else will need scripting on the client side, I think we can > get rid *completely* of any server side hook, and let the client side > scripts deal with the output of "git describe". > > Or am I just too optimistic? One of the nice features of GitHub is that it provides a download link to grab tarballs for any specific version. These are easy to se with other workflows (for example, the FreeBSD ports collection has infrastructure for grabbing a release and building it). It would be a shame if you needed a full git clone to get the revision information, as that would mean that anyone who built from a tarball would lose it. David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-foundation] Sequential ID Git hook
On 5 Jul 2016, at 11:44, Renato Golin via llvm-foundation wrote: > > Just for reference, GitHub *does* have an SVN interface [1], and you > can already checkout a specific revision with "svn checkout -r NNN > repo", which *is already* using "git rev-list --count". > > This means that, for SVN based bisects, using GitHub will make it > *completely transparent* for SVN users. You can also base your > releases off an SVN view of the Git repo. Note that GitHub (currently, at least) doesn’t export submodules sensibly with their svn version. I don’t intend to use the svn thing (the only time that I have used it in anger was to replace a project that moved to GitHub with an svn:external that referred to the GitHub repo so people could easily find the new location), but that would cause problems if anyone wants to do an svn bisect. I think it would help to have a description of how to bisect for a clang or lldb (or some other subproject) regression. For downstream users, it would also be nice if tools like git-imerge let you merge clang and llvm together, though that’s a nice-to-have feature that we currently lack so shouldn’t in any way block the migration. David smime.p7s Description: S/MIME cryptographic signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
On 4 Jul 2016, at 12:27, Renato Golin via Openmp-dev wrote: > > On 4 July 2016 at 00:42, Robinson, Paul wrote: >> Daniel claimed it was not different, even though he proposed the text. >> I think it is better, as "egregious" (even though it is qualitative) >> helps identify what "rare" circumstances would come under the policy. >> As a non-lawyer I do think it's different. > > I personally agree with you, both on helping identify "rare" (as what, > not when), and for easing non-lawyers minds. The simplest solution would probably be to have a separate advisory document listing informally examples of things that would and wouldn’t be covered by the CoC. For example: Stalking a member of the LLVM community: Covered. Inciting harassment of a member of the LLVM community in social media: Covered Sending rude emails to a member of the LLVM community with whom you have a relationship outside of the project: Probably not covered, unless it’s directly related to LLVM Some example that people are worried would constitute overreach: Not covered Some other examples that people are concerned must be covered: Covered This document would provide guidance for the CoC enforcement committee, but would not be part of the official CoC. David smime.p7s Description: S/MIME cryptographic signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
On 6 Jul 2016, at 16:16, Robinson, Paul wrote: > > As Daniel pointed out, an enumeration like that knows no bounds, and > starting a list invites endless what-if questions. That's why I settled > for a more qualitative statement; we have to acknowledge that ultimately > there's a judgement call on the part of the enforcement committee, but > the wording as it was felt a little too wide-open for me. That I was explicitly *not* what I was suggesting an enumeration of all possible cases, I was suggesting an additional document describing hypothetical case studies and whether they would be covered. There is ample precedent for this in law (for example, much of the tax code in the UK comes along with guidance notes, which are not considered legally binding but provide people with rough rules of thumb) and does not degenerate into an attempt to list every possible case. David smime.p7s Description: S/MIME cryptographic signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
On 18 Feb 2017, at 02:10, Anna Zaks via llvm-dev wrote: > > While students with previous LLVM dev experience will be more productive, > GSoC is a great way of attracting newcomers to the project! So if a proposal > is scoped to be completed in time even by someone not familiar with LLVM, we > should still accept it. I’d also add, from having mentored GSoC projects for several open source projects, that there are two ways of considering success for a GSoC project: 1. The student completes the work and it’s incorporated into trunk. 2. The student becomes engaged with the project and continues to contribute after the end of the GSoC. The former treats the GSoC as an expensive way of getting a particular feature added (yes, Google pays the student, but generally the mentor time comes from somewhere and that’s not free, it’s time that would otherwise be spent contributing to the project in another way). The second treats the GSoC as a powerful recruitment tool. I’ve had a couple of students that succeeded in the first way, but didn’t really benefit the project, because they left at the end of the GSoC. I’ve also had a few that managed some proof-of-concept code that ended up showing that the entire GSoC project idea was the wrong approach, but then remained active contributors for years and ended up contributing far more (good) code than I’d have written if I’d spent the time that I spent mentoring them on hacking. I would strongly encourage treating the GSoC as a way of engaging students. I’d also hope that the Foundation’s Women in Compilers and Tools project will help encourage this kind of participation in a way that meshes well with the GSoC. David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
On 1 Feb 2019, at 22:48, Peter Wu via cfe-dev wrote: > > On caveat is that the test coverage would be limited or else the build > times would be very long. There are quite some builders for various > projects (llvm, cfe, compiler-rt, etc.) on a lot of different platforms > and targets (Linux, macOS, Windows, Android, etc.). > > With limited resources, Arthur's suggestion seems workable to me: > - Enable pre-commit testing of few configurations (in parallel). > - Encourage developers to wait for tests to pass before pushing changes. > - Do not block hard to avoid a situation where unrelated changes > (commits or build environment) cause failures. GitHub does let you block merges (by anyone who isn’t an administrator) of PRs that don’t meet certain requirements. For one project, we have it set up so that you need to have at least one reviewer saying approved, you have to have signed the CLA, and you have to pass all of the CI checks. It’s then easy to set up automatic merging when all of the prerequisites are met (you can get a notification and process it automatically). We allow self approval for small changes (not automatically enforced, this is a judgement call, but you can remove people who abuse it from the team quite easily and then they can’t approve changes). I’ve found it leads to a very nice workflow: developers aren’t in the loop for merges, they just prepare something that they think works, submit it, and get on with something else. If you’re lucky, someone approves it and you pass CI first go, then everything is fine. Reviewers can wait until CI is finished and not bother looking for things that are going to break. If the change introduces new tests, reviewers know that those tests are passing. If you broke a platform that you don’t test on locally, you get notified but no one else is spammed with breakage reports. Once you’ve fixed it, you get a review, and make any changes. The master branch is always buildable and passing CI. If your changes break CI, you don’t have a race to fix things before someone reverts your change, you just fix things in the PR and wait for it to be automatically merged. David ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy
On 20 Mar 2019, at 18:23, Arthur O'Dwyer via cfe-dev wrote: > > Server-side hooks are the answer to this problem. There is no problem. You > just use a server-side hook. It is quite unlikely that GitHub will allow LLVM (or any other project) to run arbitrary post-receive hooks. It is far more likely that they will give an option that disables the merge button in PRs. It is already possible to prevent direct pushes to master by anyone, so this would be a very small change (literally disabling one button in the UI). David ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
