Hello.
Le lun. 27 juin 2022 à 01:18, Alex Herbert a écrit :
>
> On Sun, 26 Jun 2022 at 21:27, Gilles Sadowski wrote:
>
> >
> >
> > >
> > > Strangely I am not receiving emails from GH actions (or jenkins) to
> > inform
> > > me that
lpful for all the single
> operations.
>
I may be one or more steps behind, sorry, but I still cannot figure
out how the API is supposed to be applied (IOW, the "use cases").
I'm still at "provide functions that operate on a list of complex numbers".
But the subsequent question: For what purpose?
Some weeks ago (IIRC), I asked the same and whether the only use
case was FFT...
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hello.
Le lun. 27 juin 2022 à 11:34, sebb a écrit :
>
> JSON files don't support comments, so it's not feasible to add an AL
> header to them.
What are files in this format used for (in a "Commons" component)?
Gilles
>
> So rather than have to add such excludes at
Hello.
Le dim. 26 juin 2022 à 22:17, Alex Herbert a écrit :
>
> On Sun, 26 Jun 2022 at 21:12, Gilles Sadowski wrote:
>
> > Hello.
> >
> > Jenkins (as well as local build of [Math]) is failing:
> > https://ci-builds.apache.org/job/Commons/job/commons-math/336/
in commit 1497df18dfb77f454450d71733c31a47560c6845.
There, parentheses have been removed in logical tests.
Could this seemingly innocuous change be causing this issue?
If so, there is a probably unwanted side-effect (either in [Numbers] or in
[Math]).
Regar
Hello.
Le ven. 24 juin 2022 à 16:59, Sumanth Rajkumar
a écrit :
>
> Hi Alex, Gilles, and Matt,
>
> I have raised a PR to the complex-gsoc-22 branch and it has been linked to
> the NUMBERS-188 jira.
One tenet of a project such as "Commons" is that everyth
u have use-cases?
Could perhaps extend the benchmarks to all the JDK collections
that could target the same use-cases?
Also, it may be worth actually testing different sizes.
[For easier reading, please make a table with the JMH results.]
Thanks,
Gilles
-
(unless you have a use
case).
> If yes, for operations on float types, can we reuse functions (part of
> NUMBERS-188) that operate on double types
An example?
> and use Java float-double
> widening and narrowing conversions?
That would be a cast (from "float" to
nd of common practice that should be voted on, and
eventually enforced.
> If not, I'd prefer to wait for the next release since "2.8" is
> consistent with previous commons-configuration releases and the vote
> has already started on rc2.
Sure.
Regards,
Gilles
>
> Regards,
&
plex" is better managed
through links between JIRA issues than by lengthy threads here.]
Thanks,
Gilles
>
> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
uld always expect to make changes
in his code?
If so, shouldn't we always mention both kinds of compatibility in the
release notes?
Regards,
Gilles
>
> Regards,
> Matt J
>
> On Sun, Jun 19, 2022 at 10:50 AM Matt Juntunen
> wrote:
> >
> > Hello,
> >
> > Th
Le ven. 17 juin 2022 à 15:16, sebb a écrit :
>
> As the subject says - maybe we should update from v24 to v26
Why not?
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
Hello.
Le jeu. 16 juin 2022 à 19:36, Alex Remily a écrit :
>
> Do you think we could simply use CRYPTO-120
> <https://issues.apache.org/jira/browse/CRYPTO-120>?
Maybe.
Or open a new one with an up-to-date description,
and signal that it replaces old/obsolete reports...
Gilles
&
Hello.
Since there is an issue to be solved, could you file a report on JIRA?
[And post there patches or new files, and instructions.]
Thanks,
Gilles
Le jeu. 16 juin 2022 à 19:18, Alex Remily a écrit :
>
> I just ran [2], and whatever it does, it doesn't appear to do a build of
>
Windows for the Windows binary, that's
> the only hurdle I think.
Of course, that is the problem.
> Linux/Ubuntu is free and anyone can do that
> with Docker.
Or without it.
Gilles
>
> Gary
>
> On Tue, Jun 14, 2022 at 9:21 AM Gilles Sadowski wrote:
> >
&
rtable
managing it.
> and packages them into the commons-crypto jar.
See also my other post, about the possible (?) security implications.
Regards,
Gilles
[1] https://commons.apache.org/proper/commons-crypto
> Anyway, that's my $0.02.
>
> Alex
>
> On Tue, Jun 14, 2022 at 9:10 AM
can find them.
>From a security POV, it seems (?) that this approach could dramatically
lower (or even remove) Commons' responsibility (and ensuing burden)
in case of vulnerabilities in the native code(s).
Regards,
Gil
plications in Java?
Is it both? Does it intend to be more?
In order to simplify maintenance (and clarify expectations), shouldn't it
become a (maven) multi-module project, with explicit separation between
platform-agnostic functionality and platform-specific (native) codes?
Regards,
Gilles
visible (from the application)?
What will be hidden ("implementation details")?
Do we have use-cases of non-trivial processing of N-dimensional
cubes of complex numbers? [I imagine that the same API should
be able to also process cubes of rea
tations such as jtransform)
Yes (because of the gain in RAM usage).
But AFAICT, the goal would be to make the "double[]" an "implementation
detail" of "ComplexList" and have all operators handle "ComplexList" (or
any n-dimensional "cube") as their input/output (
or interfacing with external tools (or perhaps
internally too, e.g. to minimize RAM usage when processing a large list
of complex numbers) but from a OO point of view, we should come up
with an encapsulation that ensures robustness (e.g. featuring
immutability).
Also the type(s
leFunction getReal() ;
> > ToDoubleFunction getImaginary() ;
> > }
> >
> >
> This has concerns for efficiency.
First thought that came to my mind, being confirmed when looking
at the "conj" example (where "applyAsDouble" is called twice)...
Gilles
> [
YT?
IMO, such information belong on that page[1]:
https://commons.apache.org/index.html
[1] There we should probably remove the link to the article meant to
introduce "Commons" components...
Regards,
Gilles
>
> -Bruno
>
> On Tue, 7 Jun 2022 at 00:33, Gary Gregory wrote:
>
> &g
Responding below to some of my own questions following commit
ddfd5bf859d04cc5da604b20021ceaba9de7def6
in branch
feature__MATH-1563__genetic_algorithm
Le mar. 24 mai 2022 à 01:54, Gilles Sadowski a écrit :
>
> Hello.
>
> Le mer. 18 mai 2022 à 16:34, Avijit Basak a écrit :
&g
ctionalities mentioned in the
discussion (a.o. the "adaptive rate"[4]) although it is not complete (and
perhaps contains a few bugs):
* Better names for some classes?
* Should "Population" allow duplicates?
* Port unit tests suite.
* Which genotype representation(s) to suppor
as?
>
> I already refactored some methods which can be viewed here [2]
Renaming is typically something to be first discussed here and/or
on JIRA.
Unless other non BC changes are foreseen for the next release,
such "cosmetic" changes must be avoided.
Thanks,
Gilles
>
> Th
the underlying data structure of the newly created chromosome. [The
> >> >doc assumes immutability of the representation but this cannot be
> >> >enforced, and mixed ownership can entail subtle bugs.]
> >> -- I think this a
should not report otherwise, and if
some specific component has additional requirements, let it modify
its own POM.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
w to get the native library. Not on the website, not in the
> top-level docs.
File "BUILDING.txt" at the top-level seems to contain
related information.
>
> Can anyone help with that?
>
> Thanks,
>
> Jochen
>
> P.S: My OS would be Windows, or Fedora Linux.
ome classes.
> What about the nextGeneration() method of ListPopulation class. Renaming
> this to create() or from() won't convey the purpose of it.
I agree, and that's why the new "Population" class (in MATH-1618) does
not provide a factory method (see also the "GeneticAlgor
apshot" on the right of
commit message) leads to GitHub.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
mmutability of the representation but this cannot be
enforced, and mixed ownership can entail subtle bugs.]
(11)
Do we agree that, in a GA, the most time-consuming task is the fitness
computation? Hence IMO, it should be the focus of the multithreading
tools (i.e. "ExecutorService"), probab
Hello.
> [...]
> -- Created a new PR https://github.com/apache/commons-math/pull/209.
Merged in branch "feature__MATH-1563__genetic_algorithm".
> > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
Lang. If an app has a plugin system it seems evident to me that it would be
> the kind of app that depends on other libraries anyway.
Question remains: Start something here or not (advantages vs drawbacks)?
>
> Gary
>
> On Tue, Apr 12, 2022, 05:57 Gilles Sadowski wrote:
>
> >
FTR: Reported to INFRA:
https://issues.apache.org/jira/browse/INFRA-23133
Le lun. 11 avr. 2022 à 23:30, Gilles Sadowski a écrit :
>
> Hello.
>
> Fetching the "same" branch from either "github" or "gitbox", I don't
> end up with the same contents;
ed here), and
* modules with external dependencies whenever required.
[If the latter modules are considered out-of-scope for Commons, then
the glue code would be left for the respective projects to implement.]
Regards,
Gilles
>> [...]
--
nality (WIP).
Closes #208.
commit 57dda85533fbac18389a3ddc70e3640aa4484a91
[...]
Any idea of what is going on?
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Also, in all recent codes, there is no blank line between the instance
> >fields; the (mandatory) Javadoc is enough to logically (and visually)
> >separate the fields.
> -- I have rectified this.
Thanks!
> [...]
>
> >* Are annotations (@SafeVarargs, .
s Configuration. We could bring in the Log4j version, now safer than
> other implementations into Commons Text or a new component and everyone
> depends on this new version.
+1
TBD in another thread (name, etc.) ?
Regards,
Gilles
---
stenerRigistry" method (note: There is a typo in that name).]
* Are annotations (@SafeVarargs, ...) necessary? Please document.
In "AdaptiveGeneticAlgorithm":
* There should be a single constructor (same remark as above).
* Why the use of reflection ("isAssignableFrom")?
the report. No-one else seems to have
> commented either way. But I think it important that any PR has automated
> checks that the new code is executed.
IMO, it would be a regression if the move to GH has removed that feature.
Gilles
>
> [...]
--
ly
> jxpath
> math
> numbers
> rng
> weaver
statistics
>
> Do we need to move these as well?
For consistency, or ease of maintenance, provided it is indeed
the case that everything can be configured from ".asf.yaml" (i.e.
no "login in on GH" require
Hello.
Le lun. 28 mars 2022 à 00:32, Sumanth Rajkumar
a écrit :
>
> Thanks Alex and Gilles for your feedback
>
> So currently Commons Math transform depends on Common complex numbers, and
> the API involves usage of Complex Object Arrays instead of primitive array
> data str
the same problem).
Whenever we then decide that the new code has been thoroughly
tested, removal of the
o.a.c.m.examples.ga.mathfunctions.legacy
package will be a minimal change (as compared to the removal
of a module).
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
;NullPointerException".[2]
Regards,
Gilles
[1]
https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy-exception/src/main/java/org/apache/commons/math4/legacy/exception/NullArgumentException.java;h=ec371bb20a7acc41692789029c9bfa424cf14fb9;hb=HEAD
[2]
https://doc
Hi.
Le mer. 23 mars 2022 à 03:27, Matt Juntunen
a écrit :
>
> Gilles,
>
> > Say, for example, that "V" holds a single (floating-point) value. We
> > insert entries
> > map.put(x, 2);
> > map.put(y, 8);
> > assuming that "x" and
etrieve data from the map.
Then, there is also
map.put(z, 10);
Currently "10" will replace either the value at "x" or the value at "y".
But is it the right behaviour in all cases, or should there be a
"replacement policy" (to apply whenever points are al
form" module,
with zero dependency, so it would bring zero bloat to [Imaging] users if
we consolidate usage.
Of course, that would imply testing and benchmarking all current
implementations, and retain the best (taking v
in Commons Math.[1]
It could be construed as a (high priority) use case. Thus, it should
be included in benchmarks and possibly adapted to work with the
proposed data-structure(s).
Regards,
Gilles
[1]
https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-transform/src/ma
ersion.
What about
* changing the location if it makes things simpler for us, and
* writing a script that generates the old layout (symbolic links)
to keep things simple for users.
?
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
as said, I'd
favour #1 only if there were an actual security promise. Otherwise,
immutability is a false claim.
Unless I'm mistaken, calling "put" in order to update the "value" is
necessarily less performant than calling "setValue" (map search in
the former, no
"setValue" (on the entry).
So we have a somewhat crippled API that does not bring any
advantage since reference immutability doesn't provide any
security to the map's user (any other caller who is being passed
the same map, is able to change its contents anyways).
I suggest to carefully c
n't make a difference in performance.
>
> Do you prefer the "get" verb over "resolve",
Yes (I'm missing what is being resolved; it's just something
being accessed).
Best,
Gilles
> e.g. "getEntry" vs "resolveEntry"?
>
> Regards,
> Matt
>
", and ask INFRA to proceed[2]
for the "math-related" components of "Commons" i.e.
Commons RNG
Commons Numbers
Commons Geometry
Commons Statistics
Commons Math
Please list ASAP any other Commons sub-project for which
those additional JIRA fields may be
Hello.
Le lun. 14 mars 2022 à 16:19, Matt Juntunen
a écrit :
>
> Gilles,
>
> > it would be great to keep the tutorials/userguide in sync.
>
> Sounds good. I'll update the user guide in this PR.
>
> > I'm a little bit confused: Isn't it always the case that
> g
he ComplexList for
> higher dimensions (2D, 3D, 4D etc..)
This class could be useful:
https://commons.apache.org/proper/commons-numbers/commons-numbers-arrays/apidocs/org/apache/commons/numbers/arrays/MultidimensionalCounter.html
Alex will probably further comment on whether this is going
mented in a follow-up issue. [1]
Thanks.
However, my impression is that the API should be more general:
---CUT---
public Iterable closestInRange(P point, double radius);
---CUT---
Unless I'm missing a standard use-case, the specialized methods
ne" classes also look quite similar; consolidating the
"examples-ga" module (including full Javadoc) is necessary. I still don't
understand why there are "...-legacy" modules in module "examples-ga".
If you want to offer the option of running the "old" i
y resolveEntry(P pt);
> }
>
> PointSet {
> // return the key corresponding to pt, or null if not found
> P resolve(P pt);
> }
I don't quite follow; which are the corresponding "non-canonical"
accessors?
>
> Reviews and comments are welcome.
Is there a not
Le ven. 25 févr. 2022 à 04:39, Matt Juntunen
a écrit :
>
> I just added a similar placeholder issue for geometry:
Thanks!
I've added GEOMETRY-144 to the list.
Regards,
Gilles
> [...]
-
To unsubscribe, e-mail: dev
Ping.
Nothing for "Geometry", "Statistics", ... (?)
;-)
Regards,
Gilles
Le mer. 9 févr. 2022 à 14:57, Gilles Sadowski a écrit :
>
> Hi.
>
> >>> [...]
> > > >
> > > > Shall we open a "GSoC 2022" report in each concerned
ions
for the user (like default values, ...). Please keep the API as simple
as possible.
Thanks,
Gilles
>>>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
e the
intention is to keep the history clean until the agreed-on
code is merged to "master".]
Thanks,
Gilles
> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
mosome"
> >* "Network" is the counterpart of "Population".
> --"multiple instance of AbstractGeneticAlgorithm" is related to parallel GA
> with multiple populations not multi-threading.
Yes, as I also mentioned above.
But I'm interested in where mu
https://issues.apache.org/jira/browse/INFRA-22893
>
> On Fri, 18 Feb 2022 at 12:49, Gilles Sadowski wrote:
> >
> > Hello.
> >
> > To help with automatic collection of tasks for GSoC[1] INFRA is
> > willing to add fields to our JIRA template.
> >
> > P
ne (free entry?) fields akin
to (perhaps with a better name):
* "required-knowledge" (things that candidates can learn by
themselves like how to build the project, etc.)
* "nice-to-have-knowledge" (i.e. for GSoC something that could
be acquired during the "bonding period&qu
to move
> there?
Which discussion (since this thread covered more than one subject)?
If you mean the "migration to Junit 5" task for [Codec], it's already
there.[1]
If you mean the method rename (to remove the "test" prefix), then
the "dev" ML is where to
quot;.
When migrating to the newer Junit, the "same style" rule is
intentionally broken; hence it is *not* obvious that one should
not also change the method name.
It certainly would not hurt to add a sentence to that effect, and
it would avoid repeating ourselves.
Gilles
>
> Gary
e chance that a contribution is based on another
convention that's perhaps becoming more natural for new developers)?
Thanks,
Gilles
> > > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
F
ges
but you can certainly start a discussion about changing the
convention. I agree that, in
---CUT---
@Test
public void testSomething() {
// ...
}
---CUT---
there is one "test" too many.
Regards,
Gilles
> > [...]
--
t multiple instances
> of AbstractGeneticAlgorithm class and converge them in parallel. Users who
> does not care for robustness would go for current implementations of the
> algorithm with single population. For a better optimization quality users
> would chose the new class
Hello.
Le mer. 16 févr. 2022 à 16:01, Alex Herbert a écrit :
>
> On Wed, 16 Feb 2022 at 14:07, Gilles Sadowski wrote:
>
> > >
> > > Use Double.MIN_VALUE for the SAFE_MIN constant.
> >
> > Nit-pick: s/VALUE/NORMAL/ ?
>
> Oops. However
n a single massive PR or should I create a
> PR for each package?
A good start for another post (changing the "Subject:" line).
>
> Should I step in on this issue?
Sure. Welcome!
> Can someone guide me in those small doubts
> I have?
Hopefully yes.
Best,
Gilles
>
> Regards,
>
> Itamar Carvalho
>
>
>
>>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
8e68387d2b03c966365cd
> Author: aherbert
> AuthorDate: Wed Feb 16 12:33:14 2022 +
>
> Use Double.MIN_VALUE for the SAFE_MIN constant.
Nit-pick: s/VALUE/NORMAL/ ?
Regards,
Gilles
> ---
> .../main/java/org/apache/commons/numbers/core/Precision.java | 11
> +++
>
well, are really lacking, it is the truth.
[1] Largely "thanks" to GitHub IMO.
[2] Which the number of PRs cannot be by itself.
>
> Gilles Sadowski 于2022年2月14日周一 22:34写道：
>
> > Le lun. 14 févr. 2022 à 14:34, Gary Gregory a
> > écrit :
> > >
> > >
itiatives, not even whether to respond.[1]
It occurs to me that it is not necessary to be a PMC member, or
even a committer, in order to help within GSoC (or just team with
newcomers until all the issues with their PR are ironed out).
Regards,
Gilles
[1] https://markmail.org/message/2qckwxw
uot; anymore; it is backed by the fact that
"Commons Math" API modernization had stalled on the basis
of that rationale; yet since the path has been unblocked, work
on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself
demonstrated how much room there was for improving[1] those
icial forum
(this ML) to GitHub is aggravating[2][3] the maintenance problem:
Most components now rely on less than the 3 required votes for
release, and can thus easily become "attic" candidates.
Regards,
Gilles
[1] The concept of "mature" library (often floated around here) has
bee
on
> >that processes the population using multiple threads.
> --This needs to be done. However, I would like to address this along with
> parallel GA i.e. convergence of multiple populations together.
The two features (multi-thread vs multiple populations) should
be implemented independently: Users that only need the "basic"
GA should also be able to take advantage of their machine's
multiple CPUs.
[This is related to the design issue which I mentioned previously.]
>
> (8)
> >Do not use explicit "\n" and "\r" characters.[1]
> --Done
Thanks,
Gilles
>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hello.
Le jeu. 10 févr. 2022 à 20:40, Gary Gregory a écrit :
>
> On Wed, Feb 9, 2022 at 11:06 AM Gilles Sadowski
> wrote:
>
> > Le mer. 9 févr. 2022 à 16:32, Gary Gregory a
> > écrit :
> > >
> > > Crafting a compressed file for a test fixture that c
y, it must be documented that the class is a
shortcut workaround for a specific issue (to be clarified)
and should not be mistaken as a general-purpose utility
to add two numbers (in which case "ExactMath" and
"add" are bad names for the intended purpose).
>
> Gary
>
obvious why those
hoops are necessary; thus documenting the rationale would
prevent someone scrapping them (with just as terse a commit
message).
The other part of the remark signals a potential bug and/or
unintended behaviour; this also calls for clarification (and/or
unit tests).
Th
> last time to repurpose or use as templates for new ones.
>
> Actually, I was thinking of creating one global "GSoC 2022" issue
> in each component, that would list all the topics and a complete
> description of their respective goal,
.ArchiveEntry;
> +import org.apache.commons.compress.utils.ExactMath;
Why is this class used rather than "Math.addExact"[1]?
[If there is a reason, then the Javadoc of method "add(int,long)"
should document the purpose and rationale of the odd signature
(and its caveat that it can throw even
The currently available GA implementations are sequential.
IIUC, the "nextGeneration" methods should provide an option
that processes the population using multiple threads.
(8)
Do not use explicit "\n" and "\r" characters.[1]
Regards,
Gilles
[1] See
https://
Hello.
Le mer. 2 févr. 2022 à 10:47, Alex Herbert a écrit :
>
> On Mon, 31 Jan 2022 at 15:06, Gilles Sadowski wrote:
> >
> > Hello.
> >
> > Le jeu. 27 janv. 2022 à 18:09, Alex Herbert a
> > écrit :
> > >
> > > I would be willing to g
ble: GUIs
> entail unnecessary hassle for someone working from a remote
> (text) terminal.
> -- I shall remove that and the corresponding part of the code.
Thanks.
Please note that I don't suggest that you remove the tracking of
the optimization process (it is useful to have a trace in
Le dim. 30 janv. 2022 à 19:34, Gilles Sadowski a écrit :
>
> I filed a JIRA report:
>https://issues.apache.org/jira/browse/INFRA-22818
No answer yet; I created another Jenkins job in the meantime:
https://ci-builds.apache.org/job/Commons/job/commons-math__ga_branch
heck spotbugs:check javadoc:javadoc*".
As Alex noted, you should ensure that the build is successful with
the supported version of the JDK (i.e. Java 8 currently).
[If you encounter problems with a later version, it's always nice to
file a JIRA report, but fixing such issues is probably low
in goal: ensure accuracy and performance and better API,
add other functions (?).
> Without this set of skills there will be little progress in the formal
> code period.
:-}
Shall we open a "GSoC 2022" report in each concerned JIRA project?
Regards,
Gilles
>
> [...]
>
> On the same topic, should we increase the version number to 1.3.0?
Yes.
Regards,
Gilles
> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands
el Wed/Thu/Friday. So if you join you
> should be able to get it answered pretty quickly over the next week, or use
> JIRA if you don't want to use Slack, they normally respond quickly over
> there too.
I filed a JIRA report:
https://issues.apach
ges added to it. The summary
> report is attached herewith. Kindly look into it and do the needful.
There is no attachment (I think that the ML manager strips those).
Please copy/paste the relevant part of the console log (or provide
a link to it).
Thanks,
Gilles
P.S. I'll stop trying to "rebas
Hello.
Le dim. 30 janv. 2022 à 01:17, Alex Herbert a écrit :
>
> On Sun, 30 Jan 2022 at 00:09, Alex Herbert wrote:
> >
> > Gilles, the Slack tool is the same one we used for GSOC 2020. I just
> > clicked the link and could sign in as before and see the previous GSOC
>
https://the-asf.slack.com/
However, it is not the "apache.org" domain; thus I'm wary of
supplying the ASF credentials there...
Gilles
>
> Bruno
>
> On Sat, 29 Jan 2022 at 05:10, Gilles Sadowski wrote:
>
> > Should I ask INFRA?
> >
> > Le mar. 25 janv. 2022 à 17:
Should I ask INFRA?
Le mar. 25 janv. 2022 à 17:58, Gilles Sadowski a écrit :
>
> Hello.
>
> I've modified the configuration of the "commons-math" job[1] in a
> way that seems to indicate that Jenkins would check out the
> "master" and the "featur
uired from candidates and how to
assess it (before they are selected).]
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
g[2] of the build started
manually after saving the new configuration.
Is the job's config wrong/incomplete?
Should another job (Jenkins "item") be created for both branches
to be built?
Regards,
Gilles
[1] https://ci-builds.apache.org/job/Commons/job/commons-math/
[2] https://ci-
Hello.
I just did "git push" (no "force" this time) on the feature branch.
The problem arose from changes applied a few hours ago in
"master" and not merge into the other branch yet. Sorry; please
rebase on the latest update.
Regards,
Gilles
Le mar. 25 janv. 2022
.
Please note that nowadays several maintainers are more
responsive to GitHub pull requests. However, if your
enhancement implies a lot of work, you should indeed
get some beforehand acknowledgment that your contribution
will be accepted (pending that it complies with the code
requirements).
Regar
201 - 300 of 4251 matches
Mail list logo
