search for: premerge

Hi folks, Bad news: the permerge testing service is down after a Jenkins update. We're working on it but it's more difficult to resolve this than expected. I disabled the builds right now. I'll keep you posted once it's back online. Sorry for the downtime... Best, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL:

...ter" practise less awful:) Now the main topic... > clang-tidy: fail. Please fix clang-tidy findings. For example, on https://reviews.llvm.org/D72103#1801916 , merge_guards_bot reports clang-tidy findings of existing code, not just the modified code. I think https://github.com/google/llvm-premerge-checks should use --line-filter= as clang-tidy/tool/clang-tidy-diff.py does. > clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or applying this patch. Similarly, clang-format should use --lines to filter out untouched code.

...rocess, shall we finalize channels we are going to use for communication so that all the developers involved know what is going on and where. Which ML and IRC would be used for 'semi-official' communication etc. 1. Danny, Quinn and Marex have already started working on compiz-plugins-beryl-premerge tree on http://gitweb.beryl-project.org. The tree has a complete build system with ./autogen.sh && make && make install set up. 2. Mikedee is keeping tarballs of individually packaged plugins, users would have to make && make install them individually and apply schemas. Are...

...to clang-format and would like to see LLVM 100% clang formatted so we can use LLVM as a massive test-suite for clang-format when we make changes. In the last couple of months since we added this page the % has gone up by ~4% and this is likely in most part of either: a mention in LLVM-Weekly, the premerge checks or perhaps some recent clang-format efforts by individuals. This is fantastic and every directory that gets to 100% increase the directories that I can run against to check against. However, it recently twigged to me that files that don’t change very often are never going to be 100% clang-f...

...er. And you can be sure of what really gets merged. You review, build and test exactly the change that gets merged afterwards. So from the build server perspective, Github is clearly the better solution. [1] https://buildkite.com/llvm-project/llvm-release-builds [2] https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md Best, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/8dbda8dd/attachment.html>

...; > > This is soooooo much easier to set up and maintain than the > Phabricator integration > Of course it is easier to do on GitHub, but the integration on Phabricator can also a one-time cost for the project, which is already kind of on the way with https://github.com/google/llvm-premerge-checks ; then it is a matter of making it easier to add your own bot the pre-merge and increase the coverage. > Furthermore, what libc++ needs in this area is not necessarily the same as > the rest of LLVM. I don't know what pre-merge bots are setup right now, and > it's certai...

I worte in my last mail that when I ue compiz git fullscreen videos are no longer ontop of the gnome-panel... that means that the gnome-panel is still visible while playing the video in fullscreen. The commit which I said may caused it has nothing to do with it compiz does not build if I revert it). again with older compiz and metacity it works fine. (now I am running 20070316). Anyone else wiith

Please forgive the incorrect threading on this reply to Tom Stellard's RFC. > I would like to start using GitHub Actions[1] for CI testing on the release/* > branches. As far as I know we don't have any buildbots listening to the > release branches, and I think GitHub Actions are a good way for us to > quickly bring-up some CI jobs there. Personally, I feel that Tom's

Hi MyDeveloperDay, We are using the released version of clang-format / clang-tidy (not necessarily the latest release). I think it makes sense to use most recent versions of the tools: https://github.com/google/llvm-premerge-checks/issues/196 Kind regards, Mikhail On Wed, Jun 3, 2020 at 3:40 PM MyDeveloper Day <mydeveloperday at gmail.com> wrote: > Mikhail > > Firstly let me say that I love the pre-merge checks...but I recently saw > something a little odd > > A recent change I made to clan...

...r to clang-format and would like to see LLVM 100% clang formatted so we can use LLVM as a massive test-suite for clang-format when we make changes. In the last couple of months since we added this page the % has gone up by ~4% and this is likely in most part of either: a mention in LLVM-Weekly, the premerge checks or perhaps some recent clang-format efforts by individuals. This is fantastic and every directory that gets to 100% increase the directories that I can run against to check against. I’m a huge fan of clang-format, and have worked in “required to be formatted” code bases - it is a way better...

...and test jobs does GitHub allow users to run > concurrently before being throttled? > > You may have seen that Christian Kuhnel has been working on a pre-commit > testing bot that integrates with Phab: > https://reviews.llvm.org/p/merge_guards_bot/ > https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md > I hope that ends up being the way forward and suits Tom's original release > testing goals. > > On Wed, Dec 11, 2019 at 11:43 PM John Byrd via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Please forgive the incorrect th...

...es GitHub allow users to run concurrently before being throttled? > > You may have seen that Christian Kuhnel has been working on a pre-commit testing bot that integrates with Phab: > https://reviews.llvm.org/p/merge_guards_bot/ > https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md > I hope that ends up being the way forward and suits Tom's original release testing goals. > > On Wed, Dec 11, 2019 at 11:43 PM John Byrd via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrot...

I was writing a simple plugin a while ago which just sets the paint values on inactive windows. The plugin is very simple and the main part is below. When I load this plugin it blocks dbus and fuse plugins so that they only reply to requests when the active window changes. Is there anything obvious here that would cause that? static Bool inactivePaintWindow (CompWindow *w, const

...hat changed recently that makes this suddenly critical compared to the previous years? Unfortunately, we currently don't have a good way of doing pre-commit > testing on Phabricator AFAICT > I thought we do now? I got a bunch of libcxx failing on my revision a few weeks ago. The LLVM-premerge-test project recently added presubmit on Linux. Windows will hopefully follow soon (in beta right now I believe), and Mac afterward! (Even though mac is lacking on the cloud provider availability) . From the Harbormaster documentation [1]: > > You'll need to write a nontrivial amou...

Hello friends, We are switching the pre-merge test build system from Jenkins to Buildkite. That will give authors and reviewers more transparency on what's going on during the build process. For now only members of "pre-merge beta testing" [0] group are affected. As usual, please tell us if something is off. [0] https://reviews.llvm.org/project/view/78/ Kind regards, Mikhail

...c4647ce88df9e3692bf90cf They perfectly demonstrate that libc++ indeed requires a wider range of configurations that the existing pre-merge testing instructure cannot satisfy :/ I think libc++abi and libunwind may be in the same boat. These subprojects just have lots of variety. >> The LLVM-premerge-test project recently added presubmit on Linux. >> Windows will hopefully follow soon (in beta right now I believe), and Mac afterward! (Even though mac is lacking on the cloud provider availability) >> >> >> . From the Harbormaster documentation [1]: >> >>...

On Tue, Feb 25, 2020 at 4:19 AM Christian Kühnel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Louis, > > I think this is a good idea. We should start with some local experiments > where people are willing to try it and figure out how well that works and > what does not. Why not allow this for "not significant" changes? They are > merged without review

Hi all, Now that we're on GitHub, we can discuss about pull-requests. I'd like to propose to enable pull-request on GitHub, as a first step as an experimental channel alongside the existing methods for contributing to LLVM. This would allow to find workflow issues and address them, and also LLVM contributors in general to start getting familiar with pull-requests without committing to