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 probl
uffles?
>
> Gary
>
> On Tue, Feb 27, 2018, 13:18 Allon Mureinik wrote:
>
> > There will still be a chance, however infinitesimal, of a failure. :-)
> >
> >
> > On Tue, Feb 27, 2018 at 9:02 PM, Gary Gregory
> > wrote:
> >
> > > Why not make the
There will still be a chance, however infinitesimal, of a failure. :-)
On Tue, Feb 27, 2018 at 9:02 PM, Gary Gregory
wrote:
> Why not make the array 1000 items long?
>
> Gary
>
> On Tue, Feb 27, 2018 at 10:31 AM, Allon Mureinik
> wrote:
>
> > All the ArrayUtilsTes
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 t
darn, missed one :-)
Thanks Giles!
On Sat, Feb 17, 2018 at 5:12 AM, Gilles
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 down that route:
>> https://github.com/a
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 master
On Sat, Oct 21, 2017 at 6:36 PM, Benedikt Ritter wrote:
>
>
> > Am 21.10.2017 um 13:54 schrieb Allon Mureinik :
> >
> > Hi guys,
> >
> > This patch break the CI on GitHub (the checkstyle check).
> >
> > It's pretty straight forward to fix [1]
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
w
On Mon, Aug 7, 2017 at 2:36 PM, Gilles wrote:
> On Mon, 7 Aug 2017 14:08:45 +0300, Allon Mureinik wrote:
>
>> On Mon, Aug 7, 2017 at 12:16 PM, Gilles
>> wrote:
>>
>> Hello.
>>>
>>> On Fri, 4 Aug 2017 21:17:43 +0300, Allon Mureinik wrote:
>>
On Mon, Aug 7, 2017 at 12:16 PM, Gilles
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 during the validate phase,
>> b
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
wrote:
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]
https://help.github.com/articles/why-are-my-contributions-not-s
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 with
; Gary
> >
> >>
> >> Claude
> >>
> >> On Fri, Jun 23, 2017 at 4:03 PM, Oliver Heger <
> >> oliver.he...@oliver-heger.de>
> >> wrote:
> >>
> >> >
> >> >
> >> > Am 23.06.2017 um 08:58 schrieb Allon Mureini
On Fri, Jun 23, 2017 at 6:03 PM, Oliver Heger
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 new problem your only option to
> > notice
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 to
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 releas
ache.org/repos/asf/commons-lang/diff/c79e6fb8
> >
> > Branch: refs/heads/master
> > Commit: c79e6fb8f95bb07d2394221b29b75fcc016f4900
> > Parents: 98fa164
> > Author: Allon Mureinik
> > Authored: Tue Feb 28 23:17:51 2017 +0200
> > Committer: pascalschum
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
