similar to: Instructions for requesting GitHub commit access

One is expected to use `git llvm push`. For more information, please see: https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-changes-from-git > On Sep 3, 2019, at 7:06 PM, David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > What is the expected way to do commits? Do we push directly to master > after a rebase? I know there has been talk of using

What do you do when the ftp login username is different then the svn username? Every time I try to deploy it gets stuck right here: [kopanas.com] executing command ** [out :: kopanas.com] Authentication realm: <http://kopanas.com:80> kopanas.com ** [out :: kopanas.com] Password for ''jkopanas'': ** [out :: kopanas.com] subversion is asking for a password ** [out ::

I've gone through Code Reviews with Phabriactor[1], Arcanist Quick Start[2] and Arcanist User Guide arc diff[3]. But I'm unable to setup reviewers my editor pops up and there is a "Reviewers:" line and but I'm unable email addresses directly. It seems it wants reviewers passed on the command line or some how in .arcconfig. But I haven't been able to find any

Hi, I would like to follow up on the previous thread[1], where there was a consensus to disallow merge commits in the llvm github repository, and start a discussion about how we should enforce this policy. Unfortunately, GitHub does not provide a convenient way to fully enforce this policy. We can enforce it for pull requests, but not for direct pushes to the master branch, so we will have to

Jeremy Lakeman via llvm-dev <llvm-dev at lists.llvm.org> writes: > 4. Each reviewed bug / feature must be rebased onto the current "known > good" commit, merged into a "probably good" commit, tested by build > bots, and only then pushed to trunk. Keeping trunk's history more > usable, with most bad patches reworked and resubmitted instead of >

Hi, We're getting ready to start migrating to GitHub. SVN will be moved to read-only now and we'll begin the process of turning on GitHub commit access. I'll send an email when we're done. -Tom

SwitchTower is a utility that can execute commands in parallel on multiple servers. It allows you to define tasks, which can include commands that are executed on the servers. You can also define roles for your servers, and then specify that certain tasks apply only to certain roles. Manual: http://manuals.rubyonrails.org/read/book/17 Project:

We have noticed that although we have active development in the OpenMP runtime, there is no formal code-owner. I would therefore like to nominate Andrey Churbanov who is a major committer and has deep experience with the runtime code since before it was the LLVM runtime. -- Jim James Cownie <james.h.cownie at intel.com> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes) Tel: +44

On Tue, 2019-10-22 at 09:57 -0700, Tom Stellard via cfe-dev wrote: > On 10/22/2019 09:08 AM, Tom Stellard via Openmp-dev wrote: > > Hi, > > > > We're getting ready to start migrating to GitHub. SVN will be > > moved to read-only now and we'll > > begin the process of turning on GitHub commit access. I'll send an > > email when we're done.

Hi, As part of the migration of LLVM's source code to github, we need to update our developer policy with instructions about how to interact with the new git repository. There are a lot of different topics we will need to discuss, but I would like to start by initiating a discussion about our merge commit policy. Should we: 1. Disallow merge commits and enforce a linear history by

On 01/15, Nicolai Hähnle via cfe-dev wrote: > On Tue, Jan 14, 2020 at 11:41 AM Renato Golin <rengolin at gmail.com> wrote: > > We rarely approve some patches and not others in a series, and when we > > do, we ask people to create a new series without the approved patch, > > or split them, so that we can continue reviewing the series. > > This has simply not been

Hi, We're less than 2 weeks away from the developer meeting, so I wanted to give an update on the GitHub migration and what's (hopefully) going to happen during the developer meeting. Everyone who has added their information to the github-usernames.txt file in SVN before today should have received an invite to become a collaborator on the llvm-project repository. If you did not receive

On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Mehdi AMINI <joker.eph at gmail.com> writes: > > > What is the practical plan to enforce the lack of merges? When we > > looked into this GitHub would not support this unless also forcing > > every change to go through a pull request (i.e. no pre-receive hooks >

All, I'd like to resurrect the discussion on replacing libgomp with libiomp as the default OpenMP runtime library linked with -fopenmp. For reference, the previous discussion is accessible there: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 We are very close to getting *full* OpenMP 3.1 specification supported in clang (only one (!) clause is not

Greetings all! # Summary - We will put the new LLVM license and developer policy in place for all subsequent commits next Friday (2019-01-18). - Commit access will be stopped while this is done (starting 3pm PST, hopefully under 3 hours). - We will restore commit access for everyone covered by relevant corporate and/or individual agreements. - Others will need to take some steps to restore commit

Hi Developers, This is to clarify which patches may be merged into the 3.5 branch. * All doc changes may go in. In fact, you’re encouraged to update the branch's ReleaseNotes.rst file! :-) * All non-documentation patches should first receive approval from the appropriate code maintainer. (A blanket approval is acceptable for the first phase of testing.) * If your patch fixes a major bug,

On Thu, Apr 30, 2015 at 11:59:52AM +0100, Renato Golin wrote: > Tom, code owner nomination. > > Andrey is the most active developer, so I think it makes sense. How > long do we wait to change the file? Is there any process that you'd > like to follow? > I don't think there is a formal process, but usually the file gets updated once Chris approves. -Tom > cheers,

On 15 March 2015 at 20:22, Chris Lattner <clattner at apple.com> wrote: > Can you post the entire revised diff that you want to include? Is it Diff 21913 on Phab? If so, LGTM. Hi Chris, Here's the final version: http://reviews.llvm.org/D8197 cheers, --renato

Bill, I have the openmp support in llvm 3.5svn now built on 10.7 using Xcode 4.6.3 and 10.8/10.9 using 5.1.1. The 10.7 build required the hack… perl -pi -e 's|list\(APPEND SANITIZER_COMMON_SUPPORTED_DARWIN_OS iossim\)||g' projects/compiler-rt/CMakeLists.txt to suppress building libclang_rt.asan_iossim_dynamic.dylib. The compiler-rt build now expects the iPhoneSimulator7.0.0.sdk but

Here's another question about the current status of this. It's close to two months after the official monorepo was supposed to be published. Can someone give an update? Is this on hold indefinitely? Are there concrete issues that people are working on and this will happen as soon as those are resolved? At the least, I'm assuming the "SVN will shut down 1 year from now"