Can you link to that PR so we have something concrete to look at?
On Sun, Oct 14, 2018 at 7:49 PM Aleksander Ĺciborek <
aleksanderscibo...@gmail.com> wrote:
> Hi,
> During my first attempt to create pull request with 2 new classes (a single
> utils class and a test class) I have encountered
of
> non-shuffles?
>
> Gary
>
> On Tue, Feb 27, 2018, 13:18 Allon Mureinik <murei...@gmail.com> wrote:
>
> > There will still be a chance, however infinitesimal, of a failure. :-)
> >
> >
> > On Tue, Feb 27, 2018 at 9:02 PM, Gary Gregory <garydgr
There will still be a chance, however infinitesimal, of a failure. :-)
On Tue, Feb 27, 2018 at 9:02 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:
> Why not make the array 1000 items long?
>
> Gary
>
> On Tue, Feb 27, 2018 at 10:31 AM, Allon Mureinik <murei...@gmail
All the ArrayUtilsTest#testShuffleXYZ tests take an array, shuffle it, and
assert that the result isn't equal to the original array.
This is usually true, but there's a small chance that the shuffled array
will be equal to the original array, and thus the test will fail. This
chance is higher for
darn, missed one :-)
Thanks Giles!
On Sat, Feb 17, 2018 at 5:12 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
> On Fri, 16 Feb 2018 21:12:39 +0200, Allon Mureinik wrote:
>
>> The migration from FindBugs to SpotBugs seems to be trivial once we decide
>> to go d
The migration from FindBugs to SpotBugs seems to be trivial once we decide
to go down that route:
https://github.com/apache/commons-rng/pull/7
[Note that there are test case failures in the CI for this PR that are
unrelated to the findbugs-spotbugs migration - they also seem to reproduce
on
On Sat, Oct 21, 2017 at 6:36 PM, Benedikt Ritter <brit...@apache.org> wrote:
>
>
> > Am 21.10.2017 um 13:54 schrieb Allon Mureinik <murei...@gmail.com>:
> >
> > Hi guys,
> >
> > This patch break the CI on GitHub (the checkstyle check)
Hi guys,
This patch break the CI on GitHub (the checkstyle check).
It's pretty straight forward to fix [1], and if someone could merge it to
unblock the CI, that would be great.
TIA,
Allon
[1] https://github.com/apache/commons-lang/pull/302
On Sat, Oct 21, 2017 at 11:27 AM, Benedikt Ritter
On Mon, Aug 7, 2017 at 2:36 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Mon, 7 Aug 2017 14:08:45 +0300, Allon Mureinik wrote:
>
>> On Mon, Aug 7, 2017 at 12:16 PM, Gilles <gil...@harfang.homelinux.org>
>> wrote:
>>
>> Hello.
>>>
&g
On Mon, Aug 7, 2017 at 12:16 PM, Gilles <gil...@harfang.homelinux.org>
wrote:
> Hello.
>
> On Fri, 4 Aug 2017 21:17:43 +0300, Allon Mureinik wrote:
>
>> We had a similar discussion about Configuration.
>>
>> Personally, I'm all for enforcing checkstyle dur
We had a similar discussion about Configuration.
Personally, I'm all for enforcing checkstyle during the validate phase, but
we couldn't reach a consensus about it there:
http://www.mail-archive.com/dev@commons.apache.org/msg58573.html
On Fri, Aug 4, 2017 at 7:16 PM, Karl-Philipp Richter
Assuming you're using the same email to contribute to commons-numbers as
you use for your GitHub profile, staring the Apache repository should do
the trick.
See also [1] for some other common pitfalls that you may have encountered
[1]
I've submitted several such cleanups over the past couple of month, and for
the most part, they've been well received.
I think the key here is to improve the codebase when possible but to leave
room to deviate from IntelliJ's norms when there's a good reason to.
Perhaps annotating such places
/asf/tomcat/trunk/res/ide-support/eclipse/
>
> > Gary
> >
> >>
> >> Claude
> >>
> >> On Fri, Jun 23, 2017 at 4:03 PM, Oliver Heger <
> >> oliver.he...@oliver-heger.de>
> >> wrote:
> >>
> >> >
> >> &
On Fri, Jun 23, 2017 at 6:03 PM, Oliver Heger <oliver.he...@oliver-heger.de>
wrote:
>
>
> Am 23.06.2017 um 08:58 schrieb Allon Mureinik:
> > The root cause, IMHO, is having failValidation=false configured in the
> > pom.xml. This way, when you introduce a n
The root cause, IMHO, is having failValidation=false configured in the
pom.xml. This way, when you introduce a new problem your only option to
notice it is if you visually scan mvn's output. As evident by the current
state of the build, not everyone notices these.
A more robust approach would be
The recent commits 0ba25aa, 4fb393b and 15dcb42 buffed up the CI so several
of these reports (javadoc, checkstyle, rat) are checked per commit, so
reviewing the reports should be easier than previous verisons.
If the project's maintainers can review it, I'd like to get PR #257 in
before the
ee/c79e6fb8
> > Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/c79e6fb8
> >
> > Branch: refs/heads/master
> > Commit: c79e6fb8f95bb07d2394221b29b75fcc016f4900
> > Parents: 98fa164
> > Author: Allon Mureinik <
Hi all,
Building commons-lang locally made me notice HashSetvBitSetTest, which made
me wonder why we need it as a unit test.
I'm guessing it was originally used to support a design decision about
which data structure to use. But having done it, we now have a relatively
slow test (on my machine
19 matches
Mail list logo
