similar to: [RFC] Require PRs for XFAILing tests

Displaying 20 results from an estimated 6000 matches similar to: "[RFC] Require PRs for XFAILing tests"

2016 Sep 28
3
[RFC] Require PRs for XFAILing tests
This may be an unpopular opinion (and I don’t have the full context on those specific issues), but I believe that these are an abuse of XFAIL, and should probably be written in terms of REQUIRES instead of XFAIL. I believe XFAIL tests actually execute, and are just marked as expected failure. If a test is not expected to ever succeed, we shouldn’t bother running it, which is what the REQUIRES
2016 Sep 28
6
[RFC] Require PRs for XFAILing tests
On 28 September 2016 at 10:08, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I cannot think of any situation where a universally failing test > should be in-tree unless it is a bug that someone is expecting to fix. It seems moderately common to mark something XFAIL temporarily to get the bots green while then going ahead to fix the issue. Your proposal would add
2016 Oct 03
2
[RFC] Require PRs for XFAILing tests
> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Krzysztof Parzyszek via llvm-dev > Sent: Monday, October 03, 2016 10:40 AM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Require PRs for XFAILing tests > > On 10/3/2016 12:21 PM, Robinson, Paul via llvm-dev wrote: > > As David Blaikie mentioned,
2016 Sep 29
2
[RFC] Require PRs for XFAILing tests
> On Sep 29, 2016, at 7:52 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Sep 28, 2016 at 11:58 AM Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 28 September 2016 at 10:08, Chris Bieneman via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
2016 Oct 03
2
[RFC] Require PRs for XFAILing tests
> -----Original Message----- > From: Alex Bradbury [mailto:asb at asbradbury.org] > Sent: Saturday, October 01, 2016 1:06 PM > To: Robinson, Paul > Cc: Renato Golin; Chris Bieneman; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Require PRs for XFAILing tests > > On 28 September 2016 at 19:58, Robinson, Paul via llvm-dev > <llvm-dev at lists.llvm.org>
2013 Dec 19
2
[LLVMdev] How to XFAIL test cases with buildbot LNTFactory
Hi, I am currently trying to set up new performance and regression testers for Polly and LLVM and would like to XFAIL two test cases. I am using the LNTBuilder instead of the NightlyTestBuilder out of the assumption that the LNTBuilder is the more modern solution. However, when trying to xfail test cases I realized the xfail=[] parameter of getLNTFactor is ignored. Previously this was not an
2004 Nov 27
6
[LLVMdev] QMTest vs. Dejagnu
I've finished adding the -rundejagnu option to the nightly tester script, which was the last step to fully support Dejagnu. I think now is the appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot of work went into using QMTest, so I think we should make this decision carefully and before the 1.4 release. Here are the pros and cons in my eyes, please feel free to add your
2020 Jan 23
2
Phabricator -> GitHub PRs?
On Wed, Jan 22, 2020 at 11:24 PM David Greene <greened at obbligato.org> wrote: > Christian Kühnel via llvm-dev <llvm-dev at lists.llvm.org> writes: > > >>> In Github pull requests there is always a git commit that you can just > >>> feed to the build server. And you can be sure of what really gets > merged. > >>> You review, build and test
2004 Nov 29
0
[LLVMdev] QMTest vs. Dejagnu
Tanya Lattner wrote: > I've finished adding the -rundejagnu option to the nightly tester script, > which was the last step to fully support Dejagnu. I think now is the > appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot > of work went into using QMTest, so I think we should make this decision > carefully and before the 1.4 release. > > Here are the
2019 Apr 21
5
Close PRs on GitHub repo
There is already 10 PRs sent to GitHub repo. But they all are useless, in every PR people are being informed that they should send patches to http://reviews.llvm.org/
2020 Mar 03
3
Allowing PRs on GitHub for some subprojects
> On Feb 20, 2020, at 14:25, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > On 02/20, Louis Dionne via llvm-dev wrote: >> I know there has been significant discussion about "moving" from >> Phabricator to GitHub reviews and pull requests, etc. I'm not >> suggesting that we do anything in terms of global LLVM policy. >> However, as
2020 Feb 20
6
Allowing PRs on GitHub for some subprojects
Hi, I know there has been significant discussion about "moving" from Phabricator to GitHub reviews and pull requests, etc. I'm not suggesting that we do anything in terms of global LLVM policy. However, as a maintainer of libc++, I commit __a lot__ of other people's code for them. It would be a huge time saver for me if I could nicely suggest to contributors (not force them) to
2015 Oct 16
2
[cfe-dev] Buildbot Noise
On 16 October 2015 at 15:17, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > But if > there are new fails, the blame mailer can do a set-difference and report > only the new ones. That would reduce the noise a bit, hmm? Hi Paul, The danger there is that it'd be easier to "get used" to having some failures as long as you don't have "new"
2020 Mar 03
3
Allowing PRs on GitHub for some subprojects
> On Mar 3, 2020, at 17:16, Shoaib Meenai <smeenai at fb.com> wrote: > > `arc patch` should preserve the author information in the original commit, if there was any. At least it has in my experience. Yes, but I think people can upload raw patches to Phabricator without using `arc diff`. I know I ran into one of these just last week where I used Johannes' script (thanks!) and
2020 Jan 08
5
Phabricator -> GitHub PRs?
Now that we're on GitHub, can we *please* move to GitHub PRs? As much as I hate git, I hate Phabricator/Archanist even more. They're super clunky and makes working in git that much worse. -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200107/e47b7e36/attachment.html>
2020 Mar 04
3
Allowing PRs on GitHub for some subprojects
> On Mar 3, 2020, at 18:48, Eric Christopher <echristo at gmail.com> wrote: > > I'm one of those people ;) That's not something to be proud of if you expect a maintainer to commit on your behalf. If you commit yourself, then whatever. Louis > > -eric > > On Tue, Mar 3, 2020 at 2:20 PM Louis Dionne via llvm-dev <llvm-dev at lists.llvm.org
2020 Jan 08
3
Phabricator -> GitHub PRs?
What was the verdict? Any plans to move? I hate coding anything knowing that I'll have to use Phabricator. It's like nails on a chalkboard. -bw On Tue, Jan 7, 2020 at 4:13 PM Finkel, Hal J. <hfinkel at anl.gov> wrote: > > On 1/7/20 6:03 PM, Bill Wendling via llvm-dev wrote: > > Now that we're on GitHub, can we *please* move to GitHub PRs? As much as I > hate
2020 Jan 16
2
Phabricator -> GitHub PRs?
On Thu, 16 Jan 2020 at 18:45, David Blaikie <dblaikie at gmail.com> wrote: > I'm not sure where the idea that a patch series is anything other than that ^ came from. When I was talking about a patch series, it was/is with that definition in mind - ordered/dependent commits. I said "dependent series" to reinforce this idea that the kind of situation I was describing was one
2015 Sep 29
3
Fwd: buildbot failure in LLVM on clang-ppc64-elf-linux2
On Tue, 2015-09-29 at 14:29 -0500, Hal Finkel wrote: > [+Bill and Bill] > > ----- Original Message ----- > > From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Tuesday, September 29, 2015 12:39:02 PM > > Subject: [llvm-dev] Fwd: buildbot failure in LLVM on
2020 Mar 05
2
Allowing PRs on GitHub for some subprojects
On 2020-03-04, Louis Dionne via llvm-dev wrote: > > >> On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >> On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote: >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for