t; Or maybe just using inverse transform sampling would be okay.
Some of the implemented distributions use the inverse transform.
It's fine and sane to not do everything at once. ;-)
Indeed, if you implement another sampler, it must go into the
"sampling" module of "Commons RNG&
addition for the new "Commons Statistics" component:
http://commons.apache.org/proper/commons-statistics/
in module "distribution":
https://gitbox.apache.org/repos/asf?p=commons-statistics.git;a=tree;f=commons-statistics-distri
ons.
False attribution: We value contributions (Alex posted an explicit
appreciation on GH).
Contributing to an free project is not a popularity contest: If looking
for "visibility" is the primary goal, that's not a good start (IMO).
> You, of course, are free to leave such contrib
Le jeu. 26 nov. 2020 à 16:04, Gary Gregory a écrit :
>
> On Thu, Nov 26, 2020 at 10:00 AM Gilles Sadowski
> wrote:
>
> > Gary,
> >
> > Le jeu. 26 nov. 2020 à 15:47, Gary Gregory a
> > écrit :
> > >
> > > On Thu, Nov 26, 2020 at 9:43 AM
Gary,
Le jeu. 26 nov. 2020 à 15:47, Gary Gregory a écrit :
>
> On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski
> wrote:
>
> > Hello Gary.
> >
> > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory a
> > écrit :
> > >
> > > Please update changes.xml
Hello Gary.
Le jeu. 26 nov. 2020 à 15:09, Gary Gregory a écrit :
>
> Please update changes.xml when you merge a PR.
Since when do we require that for Javadoc clean-up?
Regards,
Gilles
-
To unsubscribe, e-mail: dev-un
s" file.
[Rationale: Display *what* has changed (and *why* if there is an associated
report). *How* (provenance) is provided by the commit.]
Regards,
Gilles
> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
ing project
of the components which you are interested in.
On a personal note, I'd suggest:
https://issues.apache.org/jira/projects/MATH
whose release is long overdue.
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...
It would be so great to be able to act differently (i.e. redirecting
to *different*
lists) depending on whether the sender is a bot or a human being.
This used to be considered a feature (cf. "robots.txt" for web crawlers).
Gilles
Le ven. 16 oct. 2020 à 14:36, Rob Tompkins a écrit :
estions (and
> don’t have an easy way to filter - and frankly I don’t want to spent any time
> on finding one)
>
> So can we turn the notifications off or at least send them to a different
> mailinglist?
+2
(I asked the sa
th the expected probability! :-)
In Commons Math however, it is mildly frightening that some tests only
pass for a small proportion of the possible seeds. At best, such unit
tests seem ill defined...
Regards,
Gilles
P.S. For [RNG], the only thing worth (IMHO) upgrading the minimum
JDK is JPMS inde
actually fails for most
input (i.e. data generated from another seed).
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hello.
[Cc'ing to the "dev" ML, as this discussion belongs there.]
Le ven. 2 oct. 2020 à 18:17, Christoph Läubrich
a écrit :
>
> Thanks Gilles, I'm currently trying to dive into all of this a bit
Your help is very welcome.
> and
> just wondering:
>
&g
Java directly.
> - As special Scala language features are used, it won't be trivial to
> port this code to Java; but maybe some of the ideas could be
> incorporated into [CLI]?
IIRC, last time significant improvements were evoked for [CLI]
someone mentioned "picocli"...
Rega
it brings some value.
There is no value in trying all the versions of all the plugins.
Gilles
>>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann
a écrit :
>
> On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski wrote:
>
> > Isn't what
> >https://spamassassin.apache.org/
> > is about?
>
> Not that I am uptodate, but at least historically it hasn't.
Le mer. 16 sept. 2020 à 14:29, Jochen Wiedmann
a écrit :
>
> On Wed, Sep 16, 2020 at 12:37 PM Gilles Sadowski wrote:
>
> > As I've already stated in the previous "discussion" (from
> > where I was left with the only solution of filtering out), a lot
> >
iscussion" (from
where I was left with the only solution of filtering out), a lot
of the bot-generated messages is just spam.
IMO, it's not needed for traceability, and nobody/norobot is
going to read it, ever; hence why accumulate it in the ML
archive?
Regards,
Gilles
--
te a [POLL] thread for what you propose.
https://markmail.org/message/7xsy4huc22qe2gly
Gilles
> My view is that at
> minimum Dependabot should still be enabled; I don't really care about
> the emails one way or another.
>
> Gary
>
> On Mon, Sep 14, 2020 at 7:12 AM sebb
available from INFRA.
> Do we need to have some CI build to publish
> snapshot versions?
Jenkins provides that functionality.
But currently there is an issue with several projects there.[3][4]
Regards,
Gilles
[1] https://markmail.org/message/l5j7xuojdc4i3ndk
[2] https://markmail.org/mess
RM would indicate in the vote
email that the hash values stored in the "dist" area are the same
as those generated by the build?]
Regards,
Gilles
> > > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le jeu. 3 sept. 2020 à 17:01, Gary Gregory a écrit :
>
> On Thu, Sep 3, 2020 at 10:47 AM Gilles Sadowski
> wrote:
>
> > Le jeu. 3 sept. 2020 à 14:49, Gary Gregory a
> > écrit :
> > >
> > > Over on GH [1], Matt mentions retry APIs like retry4j whic
I wonder what the
> community thinks.
>
Of depending on that library?
Gilles
> Gary
>
> [1] https://github.com/apache/commons-io/pull/72
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For a
applies:
>
> https://cwiki.apache.org/confluence/display/COMMONS/MavenGroupIDChange
Unfortunately, the crucial part (about whether a "relocation POM" would work)
is missing.
There wouldn't be any BC issue.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
e slow
mirrors...
IMHO, you did more than expected, by actively checking that
some server provided the released material.
>
> Fingers crossed we get no missing download complaints.
I beg to differ. ;-)
That would show that people are eagerly waiting for what i
Le jeu. 27 août 2020 à 13:22, Gilles Sadowski a écrit :
>
> Le jeu. 27 août 2020 à 10:06, Mark Thomas a écrit :
> >
> > On 27/08/2020 00:21, Gilles Sadowski wrote:
> > > Hi.
> > >
> > > Something happening recently (apparently unrelated to changes
&
Le jeu. 27 août 2020 à 10:06, Mark Thomas a écrit :
>
> On 27/08/2020 00:21, Gilles Sadowski wrote:
> > Hi.
> >
> > Something happening recently (apparently unrelated to changes
> > in the repository):
> > https://ci-builds.apache.org/job/Commons/job/comm
/console
Any idea about the cause?
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
2020-08-22 16:02 UTC+02:00, Gary Gregory :
> Here is a first cut:
>
> https://github.com/apache/commons-io/security/policy
And here is my suggestion:
https://github.com/apache/commons-rng/security/policy
YMM
rst class citizen in how we put a face on the project.
How does duplicate information improves anything
(marketing or otherwise)?
Ultimately, reports still have to be posted to an ASF-hosted
ML, and not on GH.
Gilles
>
> Gary
>
> On Sat, Aug 22, 2020, 10:15 Gilles Sadowski wrot
s managed via our common web
site.
I'm pretty sure the duplication will proceed; so at least, the
contents of this file should just be a terse:
---CUT---
To report a security problem, please read the
[Apache Commons project's security
page](https://commons.apache.org/security.html).
--
Le jeu. 20 août 2020 à 23:15, sebb a écrit :
>
> On Thu, 20 Aug 2020 at 21:54, Gilles Sadowski wrote:
> >
> > Le jeu. 20 août 2020 à 22:00, sebb a écrit :
> > >
> > > AFAICT the release artifacts have only sha512 files.
> > >
> > > However t
k OK to me.
>
> Anyway the release distribution page [1] does not relate to Maven
> releases AFAIK.
OK.
Then, I'd suggest that we don't bloat the vote message with
files that don't matter.
Gilles
>
> On Thu, 20 Aug 2020 at 18:39, Gary Gregory wrote:
> >
> &
Hi Thomas.
Le jeu. 20 août 2020 à 09:14, Thomas Vandahl a écrit :
>
> Could I please ask for one more PMC vote?
IIUC[1], this release should not ship with SHA1 or MD5 files.
Regards,
Gilles
[1] https://infra.apache.org/release-distribution.html#sigs-and-sums
>
> TIA
> Bye
Hello.
Le jeu. 20 août 2020 à 13:56, Peter Lee a écrit :
>
> Hi all,
>
> The builds in jenkins and github actions are failing.
> For jenkins, the java7, 14 and 16 builds are failing. As we have moved from
> JAVA 7 to 8, maybe we should disable java 7 build in jenkins?
+1
Gil
it won't
> slowly build up older maven wrapper versions like the old style
> jenkins slave.
Thanks for the explanations.
The [Math] component could be used as guinea pig.
Best regards,
Gilles
>
> John
>
> On Wed, 19 Aug 2020 at 22:23, Gilles Sadowski wrote:
> >
> &
to agree that it must at least be optional.
Is someone willing to demonstrate that it is so, i.e. make the
needed changes (for a single component)?
Regards,
Gilles
>>> [...]
-
To unsubscribe, e-mail: dev-unsubs
ervice" (here: automatic builds),
we don't really care whether it is provided by "Vendor A" or
"Vendor B".
If the Travis service is redundant, is there any willingness to
cut the cost by using an equivalent GitHub service?
Will if reduce spending if we stop using Travi
ting time a donation to the ASF?
If so, we could continue using it for providing "convenience"
builds for various architectures and thus spare some load on
the Jenkins cluster, using the latter only for ensuring an
independent build in a stable environment, and the generation
of snapshot
lay out their plan, or we should vote,
component-wise, on the new sets of requirements, a.o. having
a GitHub account in order to be able to manage said component.
Regards,
Gilles
>
> Thoughts?
>
> Cheers,
> -Rob
>
> > On Aug 15, 2020, at 9:45 AM, John Patrick wrote:
> &
PR's, I've not
> checked all the other commons forks I've got.
>
> They are getting automatically closed once I sync the commons fork
> into my forked repo.
>
> Has anyone else seen this issue?
Oh, yes:
https://markmail.org/message/2vutc4p3b3eqv73f
https://markmail
sonar.login and sonar.password. -> [Help 1]
---CUT---
Full log is here:
https://ci-builds.apache.org/job/Commons/job/commons-rng%20(SonarQube)/2/console
[IIRC, a GitHub account was necessary in order to provide a "security
token" to SonarQube.]
Re
Le ven. 14 août 2020 à 17:34, Gilles Sadowski a écrit :
>
> Le ven. 14 août 2020 à 17:05, Alex Herbert a écrit
> :
> >
> > On Fri, 14 Aug 2020 at 15:40, Gilles Sadowski wrote:
> >
> > > Hi Alex.
> > >
> > > Le ven. 14 août 2020 à 16:07, Al
Le ven. 14 août 2020 à 17:05, Alex Herbert a écrit :
>
> On Fri, 14 Aug 2020 at 15:40, Gilles Sadowski wrote:
>
> > Hi Alex.
> >
> > Le ven. 14 août 2020 à 16:07, Alex Herbert a
> > écrit :
> > >
> > > On Fri, 14 Aug 2020 at 13:55, Gary Grego
I will have a look at moving the RNG, Geometry, Statistics and Numbers jobs.
Done already.
But thanks!
Regards,
Gilles
>
> The main jobs for each project all have downstream jobs that run Sonarcloud
> analysis so this is something not ava
v
commons-dbcp
commons-dbutils
commons-email
commons-fileupload
commons-imaging
commons-io-ubuntu
commons-jcs
commons-jexl
commons-lang
Commons Lang
commons-logging
Commons-ognl
commons-pool
commons-rdf
commons-scxml
Regards,
Gilles
>
> Gary
>
> -- Forwarded message -
Le dim. 2 août 2020 à 15:37, Rob Tompkins a écrit :
>
>
>
> > On Aug 2, 2020, at 9:32 AM, Gilles Sadowski wrote:
> >
> > Le dim. 2 août 2020 à 15:13, Gary Gregory a écrit
> > :
> >>
> >> -1: I do not think we should release when a tes
at
it won't happen.
> Then when you look at the site for the build command above, the JApiCmp
> report contains cobertura instrumentation which is quite confusing.
>
> This build should be migrated to JApiCmp from Cobertura.
s/JApiCmp/Jacoco/
(?)
Gilles
>
> Builds OK
was the
best move.
But some people don't forget history...
> and further isolate what already is a small community of committers.
The small community problem predates GH's success.
Regards,
Gilles
>
> Mello
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
in Jira for our release notes
Isn't there a way to do it entirely on GH?
> and gitbox as a mirroring system for the source.
I surely hope that you have it backwards!
> In doing this the ASF isn’t tied to the corporate whims that may occur in the
> landscape.
+1
>
ld be routine for you *before* triggering a PR.
Doing your own filtering is going to help with the review rate.
Gilles
> pinned at https://github.com/apache/commons-lang/pull/565
>
>
> > [...]
-
To unsubscribe, e-
ueeze out as much
> performance as we can, everywhere, because we actually cannot make sure
> which function could be widely used by who.
I specifically commented on LANG-1576.
Where is the benchmark?
Gilles
>
>> For example, following Gary's and Bruno's comments, you
&
mments, you
could set up a branch that would delete all the deprecated
codes, and look for further code bloat that could be removed
from the next major release, and ensure that alternatives are
working and advertised in the Javadoc and release notes.
Regards,
Gilles
[1] https://issues.apache
o any
> reviews?
There are so many components that most committers
feel confident to make significant changes only in 2 or 3.
> For examples about my prs at commons-lang,if my memory is correct, only
> gary (and sometimes kinow) reviewed my prs
Hi.
2020-07-25 21:03 UTC+02:00, Alex Herbert :
>
>
>> On 25 Jul 2020, at 19:25, Gilles Sadowski wrote:
>>
>> Hello.
>>
>> In the thread[1] from which the below quote is extracted:
>>> Would you be willing to provide a PR that deprecates the relevant A
tringUtils"[4] (and removing it too) over
to "Commons Text" that already defines several similar (perhaps all?)
utilities[5] using a more robust approach.
Is everyone on the same page?
Regards,
Gilles
[1] https://markmail.org/message/s2o3c57537id37jt
[2] https://issues.apache.org/jir
Hello.
Le ven. 24 juil. 2020 à 17:45, Stefan Bodewig a écrit :
>
> This is an attempt at answering something raised be Gilles in a
> different thread. I'm afraid it is getting longer than I
> intended. Something seems to need to get out. Sorry.
>
> On 2020-07-23, Gilles
n was released?
Assuming that Jacoco did not shade that library, perhaps some
things would still work with another version of it, while other things
would break (I think this was the scenario pointed out by Stefan).
> Anything offered as a FOSS jar as the potential for reus
Le ven. 24 juil. 2020 à 17:46, Matt Sicker a écrit :
>
> Shading also violates a lot of common ClassLoader assumptions like not
> having multiple copies of the same class in the same visible context (even
> if different packages)
How classes in different packages could be the same cl
Hello.
Le ven. 24 juil. 2020 à 14:48, Gary Gregory a écrit :
>
> On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski
> wrote:
>
> > 2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> > > It still needs a person to decide to merge a PR for a new version.
> > > So this
Hi.
2020-07-23 15:59 UTC+02:00, Matt Sicker :
> [...] make every Commons component
> easily buildable in Jenkins [...]
How to do it practically?
Can we create a text file and drop it somewhere, or has
the configuration to be done in GUI ?
" has a common
policy for dealing with this (so that we don't have to repeat
ourselves every now and then).
A long time ago, the "shade" feature seemed the perfect
answer to that problem. Yet, to avoid dependencies even
on anoth
few days, is
> overwhelmed now and will need time to review what has happened. He
> didn't complain, he was apologizing for not responding immediately -
> which he shouldn't feel was necessary IMHO.
Certainly not he.
Regards,
Gilles
>
> Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hello.
Le jeu. 23 juil. 2020 à 13:21, Olivier Lamy a écrit :
>
> On Thu, 23 Jul 2020 at 20:57, Gilles Sadowski wrote:
>
> > Hi.
> >
> > 2020-07-23 12:38 UTC+02:00, Olivier Lamy :
> > > Hi
> > > As you know the current Jenkins infra is migrating to
Hi.
2020-07-23 8:23 UTC+02:00, Stefan Bodewig :
> On 2020-07-23, Gilles Sadowski wrote:
>
>> If I'm not mistaken, the issues@ ML was intended to keep one
>> posted of and reactive on a human discussion happening on
>> JIRA. With the advent of JIRA-GitHub inte
simple Jenkinsfile saying which jdks to use in
> case the component has different needs.
> I'm happy to help to duplicate similar configuration for commons.
> Just let me know.
+1
How does it work with projects having several Jenkins builds
(e.g. one for running SonarQube)?
Gilles
but I for sure would give preference
to tools controlled by the Apache infrastructure
team.
Gilles
>
> On Wed, Jul 22, 2020 at 22:00 Gilles Sadowski wrote:
>
>> 2020-07-23 3:35 UTC+02:00, Torsten Curdt :
>> >>
>> >> > I realize that a local build seems
e made consistent one way or another?
Is JIRA or GitHub the official issue-tracking system for
"Commons"?
Related to the thread about creating a "bot sink" ML, it seems
that "notifications@" is where a lot of the GitHub-generated
messages should go (instead of "
s causing inconvenience for you and that is bothering you?
The inconvenience is the invalid assumption that everyone
should use GH even though that was never discussed.
> And you want the rest of us to not use the tool because of that?
Where did you get that conclusion from?
Is GH more than a convenience tool like Travis, Coveralls or
SonarQube?
Or is it a core part of the work flow like "git"?
If so, when did this happen? Where is the decision recorded?
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ted.
Again, it is obvious from the contents of those emails that
the primary means to view it is _not_ in an email; hence I
deduce (perhaps hastily) that it is possible to get the pros
(get the info to those interested GH users) without the cons
(relay to "issues@").
At least, the feature is half-baked or maybe badly configured,
i.e. all the more reason to not make bulk changes.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
o are happy to get everything, nothing would
change (apart from a one-time action to subscribe to "botsink@").
For people like me, it's saving tons of mails that won't be send
anymore.
Gilles
>
> -Rob
>
>> [...]
--
e egg (the sources) the other eggs don't really
>> > matter.
>> > Could you explain the problem with the basket?
>>
>> As said above, GitHub is inconvenient for me; thus any move
>> that assumes otherwise, I don't agree with.
>>
>
> Not sure you represent the majority,
Of course not.
Do you mean I should just go away because I don't have
a GH account?
> so maybe elaborate on
> the inconvenience.
Try to do something on GH without being logged in.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
2020-07-23 1:37 UTC+02:00, Torsten Curdt :
> On Thu, Jul 23, 2020 at 12:51 AM Gilles Sadowski
> wrote:
>
>> 2020-07-23 0:14 UTC+02:00, Torsten Curdt :
>> >>
>> >> You act, and I must react?
>> >> Do I really have to spell it in even more words t
king
system (JIRA) is bypassed.]
>
> If anything, it might be clearer to rename issues@ to botsink@ or some
> such.
We should have both.
Gilles
>
> Gary
>
> On Wed, Jul 22, 2020 at 6:27 PM Gilles Sadowski
> wrote:
>
>> Hello.
>>
>> The situation with
xpectations did not change, as I explain in the [VOTE] thread
about the purposes of "issues@".
I've no problem with people wanting more bot-generated email,
but then *they* change their expectations, and they should adapt
(in this instance, by using a new ML).
Gilles
---
ade to play with GitHub or if we should just use
>> > JaCoCo all over even though I am uncertain as to the liveliness of the
>> > JaCoCo project.
>>
>
> I must have missed some of the messages.
> What is the problem using Coveralls?
None for me.
>
&g
a particular set of people)?
Specifically, I propose that
github-iss...@commons.apache.org
be set up for relaying GitHub generated posts (like comments,
PRs merging, and so on) and that
iss...@commons.apache.org
returns to its original purpose (on
2020-07-22 21:21 UTC+02:00, Gary Gregory :
> On Wed, Jul 22, 2020 at 12:39 PM Rob Tompkins wrote:
>
>>
>>
>> > On Jul 22, 2020, at 11:53 AM, Gilles Sadowski
>> wrote:
>> >
>> > Le mer. 22 juil. 2020 à 17:45, Gary Gregory > <mailto:gary
have to have one, I build it locally.
>>
>
> But what about the community who wants to try snapshots build?
>
+1
Gilles
>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
(and the reviewer's) computer.
> A tangential issue is whether to use or keep on using Coveralls and
> whether that can be made to play with GitHub or if we should just use
> JaCoCo all over even though I am uncertain as to the liveliness of the
> JaCoCo project.
I don&#x
t is completly wrong for
> libraries and would prefer to not use it.
At least, it seems that I was not completely off-base in asking what
was going on.
Thanks,
Gilles
>
> Stefan
-
To unsubscribe, e-mail: dev-unsubscr...
Le mer. 22 juil. 2020 à 18:39, Rob Tompkins a écrit :
>
>
>
> > On Jul 22, 2020, at 11:53 AM, Gilles Sadowski wrote:
> >
> > Le mer. 22 juil. 2020 à 17:45, Gary Gregory > <mailto:garydgreg...@gmail.com>> a écrit :
> >>
> >> You can ign
s
should be tested on a _small_ scale, with a suggestion of
how to avoid the nuisance.
Gilles
> if you prefer to look at the GitHub PRs instead.
> That's what I do.
>
> Gary
>
> On Wed, Jul 22, 2020 at 11:20 AM Rob Tompkins wrote:
>
> > I think that Gary tuerned on s
verridden a version provided by CP, there is
probably a reason, and we don't want to get spammed by a bot
(the more so if it's to upgrade plugins or test dependencies).
Gilles
>
> On Wed, Jul 22, 2020 at 10:12 Xeno Amess wrote:
>
> > as title.
> > I see some dependency tr
Le mer. 22 juil. 2020 à 17:19, Gary Gregory a écrit :
>
> On Wed, Jul 22, 2020 at 11:02 AM Gilles Sadowski
> wrote:
>
> > Hello.
> >
> > What's this flood of emails about?
> >
>
> Just read them!
I did a couple, and this is not really helpful:
---C
Hello.
Le mer. 22 juil. 2020 à 16:54, Xeno Amess a écrit :
>
> as title.
> I see some dependency trying to upgrade from v1 to v2.3.1, and some plugin
> from 3.5.1 to 5.1.1
> Just confused.
I don't even know what this is
Hello.
What's this flood of emails about?
Gilles
Le mer. 22 juil. 2020 à 16:35, Rob Tompkins a écrit :
>
> I’m happy to merge them….will get to them by tomorrow morning ok?
>
> -Rob
-
To unsubscribe, e-m
/A
>
> RAT Report:
>
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-beta1-rc3-site/rat-report.html
>
> KEYS:
> https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours
ered).
> Will need time to go through all of the files in nexus….
Possibly one reason why fewer and fewer people participate in votes about
release of a component (where s/lots of submodules/lots of components/
makes for an equally true remark)
> will try to get to it toni
c3
Doing
$ git checkout 1.0-beta1-release
$ git diff master
I see many differences; is that intentional? Not a blocker, but I would
expect to see only things like "1.0-SNAPSHOT" -> "1.0-beta1".
Regards,
Gilles
> [...]
he question asked;
I've been suggesting for more than a couple of years that after the
"upload" part, the same script could download the artefacts: Unless
I'm missing something, this would rule out the scenario which you've
evoked above.
Regards,
Gilles
--
Hi.
Le mar. 7 juil. 2020 à 03:59, Matt Juntunen
a écrit :
>
> This needs to be cancelled again, at the very least to revert a change that
> Gilles was not in favor of.
Sorry for that (kind of).
The point was that a release vote thread is not meant to push further
changes if the
Hello.
Le mar. 7 juil. 2020 à 03:41, Matt Juntunen
a écrit :
>
> Hi Gilles,
>
> I made the change because it seemed logical (to me) and sufficiently trivial
> (internal class with 2 usages). I don't really care too much either way so
> I'll go ahead and
that many components would be willing to enforce it.
This should probably be followed up in a new thread, in order to
probe interest, before you embark on this.
Gilles
>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons
Le lun. 6 juil. 2020 à 05:52, Xeno Amess a écrit :
>
> @Gilles
> > The Commons project has existed for more than 15 years, and
> > the history of the repositories is the best resource for the
> > current style. By spending a few minutes perusing through the
> > comm
hat we forsake that goal?
Gilles
>
> Gary
>
> On Sun, Jul 5, 2020, 15:26 Xeno Amess wrote:
>
> > @Gilles
> > If you want a good commit message you should define good first.
> > And you should understand everybody is using what he think the best style
> > in commit
Hi.
Le dim. 5 juil. 2020 à 21:26, Xeno Amess a écrit :
>
> @Gilles
> If you want a good commit message you should define good first.
I did provide some hints, in the first post. And others have given
additional suggestions.
> And you should understand everybody is using what he th
a good commit message
(cf. advice given in the follow-up posts); suggestions, discussions,
etc. must be directed elsewhere (ML or JIRA).
[In particular, having to modify the commit message is a burden when
the change is trivial; in that case, I would rather make the change and
discard the PR...]
G
private static class GeometryInternalError extends IllegalStateException {
// ...
}
}
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-1
Personally, I don't agree with the rationale.
Anyways, such a change must be proposed on the "dev" ML and, if
agreed upon, be related to a JIRA report.
Regards,
Gilles
Le sam. 4 juil. 2020 à 13:44, a écrit :
>
> This is an automated email from the ASF dual-
601 - 700 of 4400 matches
Mail list logo
