[Statistics]Port codes from Commons Math

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Statistics]Port codes from Commons Math

Gimhana Nadeeshan
Hi devs,

I am an 3rd year Computer Science and Engineering undergraduate of
University of Moratuwa and I am interested in mathematics so much. So I
would like to work on porting codes from Commons Math to Commons Statistics
component as my GSOC 2018 project.

So How to get a head start on this problem? What should I port first and
how to redesign it?

Best Regards,
Gimhana.
Reply | Threaded
Open this post in threaded view
|

Re: [Statistics]Port codes from Commons Math

Gilles Sadowski
Hello.

On Sun, 11 Mar 2018 08:30:02 +0530, Gimhana Nadeeshan wrote:
> Hi devs,
>
> I am an 3rd year Computer Science and Engineering undergraduate of
> University of Moratuwa and I am interested in mathematics so much. So
> I
> would like to work on porting codes from Commons Math to Commons
> Statistics
> component as my GSOC 2018 project.

Welcome!

> So How to get a head start on this problem?

The big picture is that the "Commons Math" code must be
split into either new components (as "sub-projects" are
called within the "Apache Commons" project), or maven module
within "Commons Math" (CM).
Which of the alternatives depends on whether a "scope" (or
"subject matter") can be clearly identified, and whether a
fairly broad usefulness can be assumed.

Practically, you can see how the premise turned out for
functionalities there were/are already in the porting
process:
  * CM's "random" package -> component "Commons RNG"[1]
  * CM's "complex", "fraction", "util", "primes", "special"
    packages -> modules in component "Commons Numbers"[2]
  * CM's "distribution" package -> "distribution" module
    in "Commons Statistics"[3]

At least one other CM package would make an obvious new
component: "geometry".

> What should I port first

The goal is modularization (for easier usage, maintenance,
and development).
The modules must not have circular dependencies.  Hence
the first step is to identify dependencies and define
the "boundaries" of purported modules.

The easiest is of course to define modules that have
zero dependencies.
Then, modules that depend on those.
And so on, up the hierarchy.

In practice, each ported functionality usually becomes
a dependency of CM (whose unit test suites should still
pass when they use the ported code).

Dependency on other "Commons" components is allowed;
runtime dependency on external libraries other than
the JDK is not.

> and
> how to redesign it?

I'm afraid there is no single answer.

Personally, I don't have a clear idea of what should
be the grand vision.  Do you have suggestions?
It would certainly be helpful to have a summary of the
design principles used in other (OO) libraries.
Guidelines could also perhaps be deduced from reported
bugs, some of which are mentioned in the page of the
GSoC report.[4]

I hope that other people reading this will chime in and
help draw a concrete plan.

Best regards,
Gilles

> Best Regards,
> Gimhana.

[1] https://commons.apache.org/rng
[2] https://commons.apache.org/numbers
[3] https://commons.apache.org/proper/commons-statistics/
[4] https://issues.apache.org/jira/browse/STATISTICS-5


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Statistics]Port codes from Commons Math

Gimhana Nadeeshan
Hi devs,

Thanks Gilles for the ideas.

Now I have an idea what to do. I go through the codes in
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/stat

And I could identify the coupling hierarchy at the top level. So I would
like to get a start from Confidence Interval
<https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/stat/interval/ConfidenceInterval.java;h=e41ebf1753e749dd72e647b54f91f5bb6d60b828;hb=HEAD>
. It seems a minor dependencies in the class it self.
How can I begin contributing? Could you please share the repo Links
corresponding to CM Statistics.

Where can we find the old code before port into new Commons components? As
you mentioned it will be a good approach to redesign process. To get a good
comparison, links of CM's Random Package code repo and current CM RNG
component.

Regards,
Gimhana


On 11 March 2018 at 17:07, Gilles <[hidden email]> wrote:

> Hello.
>
> On Sun, 11 Mar 2018 08:30:02 +0530, Gimhana Nadeeshan wrote:
>
>> Hi devs,
>>
>> I am an 3rd year Computer Science and Engineering undergraduate of
>> University of Moratuwa and I am interested in mathematics so much. So I
>> would like to work on porting codes from Commons Math to Commons
>> Statistics
>> component as my GSOC 2018 project.
>>
>
> Welcome!
>
> So How to get a head start on this problem?
>>
>
> The big picture is that the "Commons Math" code must be
> split into either new components (as "sub-projects" are
> called within the "Apache Commons" project), or maven module
> within "Commons Math" (CM).
> Which of the alternatives depends on whether a "scope" (or
> "subject matter") can be clearly identified, and whether a
> fairly broad usefulness can be assumed.
>
> Practically, you can see how the premise turned out for
> functionalities there were/are already in the porting
> process:
>  * CM's "random" package -> component "Commons RNG"[1]
>  * CM's "complex", "fraction", "util", "primes", "special"
>    packages -> modules in component "Commons Numbers"[2]
>  * CM's "distribution" package -> "distribution" module
>    in "Commons Statistics"[3]
>
> At least one other CM package would make an obvious new
> component: "geometry".
>
> What should I port first
>>
>
> The goal is modularization (for easier usage, maintenance,
> and development).
> The modules must not have circular dependencies.  Hence
> the first step is to identify dependencies and define
> the "boundaries" of purported modules.
>
> The easiest is of course to define modules that have
> zero dependencies.
> Then, modules that depend on those.
> And so on, up the hierarchy.
>
> In practice, each ported functionality usually becomes
> a dependency of CM (whose unit test suites should still
> pass when they use the ported code).
>
> Dependency on other "Commons" components is allowed;
> runtime dependency on external libraries other than
> the JDK is not.
>
> and
>> how to redesign it?
>>
>
> I'm afraid there is no single answer.
>
> Personally, I don't have a clear idea of what should
> be the grand vision.  Do you have suggestions?
> It would certainly be helpful to have a summary of the
> design principles used in other (OO) libraries.
> Guidelines could also perhaps be deduced from reported
> bugs, some of which are mentioned in the page of the
> GSoC report.[4]
>
> I hope that other people reading this will chime in and
> help draw a concrete plan.
>
> Best regards,
> Gilles
>
> Best Regards,
>> Gimhana.
>>
>
> [1] https://commons.apache.org/rng
> [2] https://commons.apache.org/numbers
> [3] https://commons.apache.org/proper/commons-statistics/
> [4] https://issues.apache.org/jira/browse/STATISTICS-5
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--

Nadeeshan Gimhana

Batch Representative (15' batch)

Department of Computer Science & Engineering

University of Moratuwa

*Mobile :+94775744613*


*Website : https://ngimhana94.wixsite.com/gimhanadesilva/
<https://ngimhana94.wixsite.com/gimhanadesilva/>*

*L**inkedin **:www.linkedin.com/in/nadeeshangimhana/
<http://www.linkedin.com/in/nadeeshangimhana/>*


* <http://www.linkedin.com/in/nadeeshangimhana/>*


* <http://www.linkedin.com/in/nadeeshangimhana/>*
Reply | Threaded
Open this post in threaded view
|

Re: [Statistics]Port codes from Commons Math

Gilles Sadowski
On Mon, 12 Mar 2018 08:43:29 +0530, Gimhana Nadeeshan wrote:

> Hi devs,
>
> Thanks Gilles for the ideas.
>
> Now I have an idea what to do. I go through the codes in
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/stat
>
> And I could identify the coupling hierarchy at the top level. So I
> would
> like to get a start from Confidence Interval
>
> <https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/stat/interval/ConfidenceInterval.java;h=e41ebf1753e749dd72e647b54f91f5bb6d60b828;hb=HEAD>
> . It seems a minor dependencies in the class it self.
> How can I begin contributing? Could you please share the repo Links
> corresponding to CM Statistics.
>
> Where can we find the old code before port into new Commons
> components?

The code bases are managed by the "git" software; the whole history is
available:
   https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log

[I'd advise to "clone" the repositories on your local computer, and
use the command line tools.]

> As
> you mentioned it will be a good approach to redesign process.

You don't necessarily need to analyze how the code was before
the port/refactoring; looking at how it is now is sufficient,
unless you suspect that something is wrong now and might have
been better before. ;-)

Don't hesitate to post here with your suggestions.

> To get a good
> comparison, links of CM's Random Package code repo and current CM RNG
> component.

I think that you can already get a pretty good idea of the evolution
by comparing the generated "apidocs":
   
http://commons.apache.org/proper/commons-math/javadocs/api-3.6.1/org/apache/commons/math3/random/package-summary.html
vs
   
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html
   
http://commons.apache.org/proper/commons-rng/commons-rng-core/javadocs/api-1.0/index.html
   
http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.0/index.html

Regards,
Gilles

> Regards,
> Gimhana
>
>
> On 11 March 2018 at 17:07, Gilles <[hidden email]>
> wrote:
>
>> Hello.
>>
>> On Sun, 11 Mar 2018 08:30:02 +0530, Gimhana Nadeeshan wrote:
>>
>>> Hi devs,
>>>
>>> I am an 3rd year Computer Science and Engineering undergraduate of
>>> University of Moratuwa and I am interested in mathematics so much.
>>> So I
>>> would like to work on porting codes from Commons Math to Commons
>>> Statistics
>>> component as my GSOC 2018 project.
>>>
>>
>> Welcome!
>>
>> So How to get a head start on this problem?
>>>
>>
>> The big picture is that the "Commons Math" code must be
>> split into either new components (as "sub-projects" are
>> called within the "Apache Commons" project), or maven module
>> within "Commons Math" (CM).
>> Which of the alternatives depends on whether a "scope" (or
>> "subject matter") can be clearly identified, and whether a
>> fairly broad usefulness can be assumed.
>>
>> Practically, you can see how the premise turned out for
>> functionalities there were/are already in the porting
>> process:
>>  * CM's "random" package -> component "Commons RNG"[1]
>>  * CM's "complex", "fraction", "util", "primes", "special"
>>    packages -> modules in component "Commons Numbers"[2]
>>  * CM's "distribution" package -> "distribution" module
>>    in "Commons Statistics"[3]
>>
>> At least one other CM package would make an obvious new
>> component: "geometry".
>>
>> What should I port first
>>>
>>
>> The goal is modularization (for easier usage, maintenance,
>> and development).
>> The modules must not have circular dependencies.  Hence
>> the first step is to identify dependencies and define
>> the "boundaries" of purported modules.
>>
>> The easiest is of course to define modules that have
>> zero dependencies.
>> Then, modules that depend on those.
>> And so on, up the hierarchy.
>>
>> In practice, each ported functionality usually becomes
>> a dependency of CM (whose unit test suites should still
>> pass when they use the ported code).
>>
>> Dependency on other "Commons" components is allowed;
>> runtime dependency on external libraries other than
>> the JDK is not.
>>
>> and
>>> how to redesign it?
>>>
>>
>> I'm afraid there is no single answer.
>>
>> Personally, I don't have a clear idea of what should
>> be the grand vision.  Do you have suggestions?
>> It would certainly be helpful to have a summary of the
>> design principles used in other (OO) libraries.
>> Guidelines could also perhaps be deduced from reported
>> bugs, some of which are mentioned in the page of the
>> GSoC report.[4]
>>
>> I hope that other people reading this will chime in and
>> help draw a concrete plan.
>>
>> Best regards,
>> Gilles
>>
>> Best Regards,
>>> Gimhana.
>>>
>>
>> [1] https://commons.apache.org/rng
>> [2] https://commons.apache.org/numbers
>> [3] https://commons.apache.org/proper/commons-statistics/
>> [4] https://issues.apache.org/jira/browse/STATISTICS-5
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Statistics]Port codes from Commons Math

Eric Barnhill
On Tue, Mar 13, 2018 at 12:47 AM, Gilles <[hidden email]>
wrote:

>
>>
>> Where can we find the old code before port into new Commons components?
>>
>
> The code bases are managed by the "git" software; the whole history is
> available:
>   https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log
>
> [I'd advise to "clone" the repositories on your local computer, and
> use the command line tools.]


I believe you will want to clone the commons-math repositories, but then
develop your own "fork" of the commons-statistics repository. Gilles can
correct me if that is wrong.


>
>
> As
>> you mentioned it will be a good approach to redesign process.
>>
>
> You don't necessarily need to analyze how the code was before
> the port/refactoring; looking at how it is now is sufficient,
> unless you suspect that something is wrong now and might have
> been better before. ;-)
>

In particular, the statistics library was designed before Java 8. Java 8
however has provided both efficient programming strategies for these
statistical methods (in the form of lambdas and streams) as well as some
built-in methods providing summary statistics functions (see discussion at
http://markmail.org/message/7t2mjaprsuvb3waj).

It probably makes sense, as a design strategy, to separate the function
implementation from the streaming implementation. For example, a 2D integer
array will probably require a different streaming implementation than a 1D
double array, but they can  probably both be passed the same function
handle to collect, say, the mean or max value.

The role of commons might then be to provide a convenient interface, so
that the user can simply call a static method like SummaryStats.mean() and
not have to worry about the implementation.

The other difficulty I see, is that quantile and median statistics will not
be as easy to stream as statistics with a closed-form solution like mean or
variance. There may however be great algorithms out there for pulling the
median or the 95% quantile out of a stream -- if so they should be used.

Eric
Reply | Threaded
Open this post in threaded view
|

Re: [Statistics] Port codes from Commons Math

Gilles Sadowski
Hello.

On Tue, 13 Mar 2018 09:25:19 +0100, Eric Barnhill wrote:

> On Tue, Mar 13, 2018 at 12:47 AM, Gilles
> <[hidden email]>
> wrote:
>
>>
>>>
>>> Where can we find the old code before port into new Commons
>>> components?
>>>
>>
>> The code bases are managed by the "git" software; the whole history
>> is
>> available:
>>   https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log
>>
>> [I'd advise to "clone" the repositories on your local computer, and
>> use the command line tools.]
>
>
> I believe you will want to clone the commons-math repositories, but
> then
> develop your own "fork" of the commons-statistics repository. Gilles
> can
> correct me if that is wrong.

Actually, I know only my workflow:
  $ git clone ...
  $ git branch ...
  $ git commit ...
  $ git push

:-}

I didn't find it very easy to cooperate with developers who
fork on GitHub and submit PRs.
I've now found the "git" command that creates a branch from
a PR, but it would be so much more comfortable to just switch
directory and do "git pull".

In the context of GSoC, would it be possible to grant some
privilege to non-committers so that they can update a selected
"git" repository?
If not, what is the next easiest way to share a "common space"
(aka "sandbox") from which it would be easy to copy reviewed
bits over to the official source repository?

>>
>> As
>>> you mentioned it will be a good approach to redesign process.
>>>
>>
>> You don't necessarily need to analyze how the code was before
>> the port/refactoring; looking at how it is now is sufficient,
>> unless you suspect that something is wrong now and might have
>> been better before. ;-)
>>
>
> In particular, the statistics library was designed before Java 8.
> Java 8
> however has provided both efficient programming strategies for these
> statistical methods (in the form of lambdas and streams) as well as
> some
> built-in methods providing summary statistics functions (see
> discussion at
> http://markmail.org/message/7t2mjaprsuvb3waj).

Very good point, indeed.
IMO, the new component should be targeted Java 8.
Even Java 9 (enforcing modularity with JPMS): if by the time we think
of releasing the code, we still want to avoid "multi-release" JARs it
will be easy to just remove the "module-info" files (I don't think much
else Java 9 specific would used by "Commons Statistics").

In fact, given the very slow pace at which new components are being
brought to releasable state, I'd like to ask whether it would be OK
to make "incremental" releases?  That would mean: focus on (maven)
modules that seem close to feature-complete and bug-free, fix the
remaining issues and perform a release with that module added.

It seems that the expectations were set to high (content-wise given
the amount of human resources), so that neither CM can be released
(too many non-fixed issues) nor its "Commons Numbers" spin-off that
contains many modules, some of which are blocked by lack of consensus
or dangling discussions.

> It probably makes sense, as a design strategy, to separate the
> function
> implementation from the streaming implementation. For example, a 2D
> integer
> array will probably require a different streaming implementation than
> a 1D
> double array, but they can  probably both be passed the same function
> handle to collect, say, the mean or max value.
>
> The role of commons might then be to provide a convenient interface,
> so
> that the user can simply call a static method like
> SummaryStats.mean() and
> not have to worry about the implementation.
>
> The other difficulty I see, is that quantile and median statistics
> will not
> be as easy to stream as statistics with a closed-form solution like
> mean or
> variance. There may however be great algorithms out there for pulling
> the
> median or the 95% quantile out of a stream -- if so they should be
> used.
>
> Eric

Eric,

Would you be the official "mentor" for the GSoC participants that
are interested in helping with the porting of "o.a.c.math4.stat"?

Thank you,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Github usage Was: [Statistics] Port codes from Commons Math

Adam Soroka

> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]> wrote:
>
>
> I didn't find it very easy to cooperate with developers who fork on GitHub and submit PRs. I've now found the "git" command that creates a branch from a PR, but it would be so much more comfortable to just switch directory and do "git pull".
>

Just as a point of information, it is possible to reverse the Github <- Apache mirroring most projects use to be Github -> Apache. What that means is that merging PRs from Github becomes one click in the Github UI.

There are other consequences, of course, especially related to other integrations Commons may be using (e.g. integration between Github and JIRA).

Of course, INFRA are the folks to talk to if this sounds interesting. At Apache Jena, we looked into it but have taken no action because we still have some open questions about when some of our workflow integrations will become possible with "reversed mirroring".

Adam Soroka ; [hidden email]
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Statistics] Port codes from Commons Math

Gimhana Nadeeshan
In reply to this post by Gilles Sadowski
Hello Devs,

Thanks Gilles and Eric for guidance.

I have cloned the Commons repos and forked the Common's Stat repo. Is it
possible to make pull requests to that repo to be reviewed? Or should I
follow a specific method?

By referring the API docs I got some idea of the separation of modules.

In the current Commons's stat repo there are some classes under the
package  distribution. I think those can be refactored using java 8 in
build statistics functionalities. Please correct me if I wrong.

As Eric said separation of function and streaming implementations is good
idea as designing. (In my point of view, it means method overloading ->
Again correct me if I didn't understand your fact correctly)

And I will share my draft proposal here for your review soon.

Best Regards.

On 13 March 2018 at 20:50, Gilles <[hidden email]> wrote:

> Hello.
>
> On Tue, 13 Mar 2018 09:25:19 +0100, Eric Barnhill wrote:
>
>> On Tue, Mar 13, 2018 at 12:47 AM, Gilles <[hidden email]>
>> wrote:
>>
>>
>>>
>>>> Where can we find the old code before port into new Commons components?
>>>>
>>>>
>>> The code bases are managed by the "git" software; the whole history is
>>> available:
>>>   https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log
>>>
>>> [I'd advise to "clone" the repositories on your local computer, and
>>> use the command line tools.]
>>>
>>
>>
>> I believe you will want to clone the commons-math repositories, but then
>> develop your own "fork" of the commons-statistics repository. Gilles can
>> correct me if that is wrong.
>>
>
> Actually, I know only my workflow:
>  $ git clone ...
>  $ git branch ...
>  $ git commit ...
>  $ git push
>
> :-}
>
> I didn't find it very easy to cooperate with developers who
> fork on GitHub and submit PRs.
> I've now found the "git" command that creates a branch from
> a PR, but it would be so much more comfortable to just switch
> directory and do "git pull".
>
> In the context of GSoC, would it be possible to grant some
> privilege to non-committers so that they can update a selected
> "git" repository?
> If not, what is the next easiest way to share a "common space"
> (aka "sandbox") from which it would be easy to copy reviewed
> bits over to the official source repository?
>
>
>>> As
>>>
>>>> you mentioned it will be a good approach to redesign process.
>>>>
>>>>
>>> You don't necessarily need to analyze how the code was before
>>> the port/refactoring; looking at how it is now is sufficient,
>>> unless you suspect that something is wrong now and might have
>>> been better before. ;-)
>>>
>>>
>> In particular, the statistics library was designed before Java 8. Java 8
>> however has provided both efficient programming strategies for these
>> statistical methods (in the form of lambdas and streams) as well as some
>> built-in methods providing summary statistics functions (see discussion at
>> http://markmail.org/message/7t2mjaprsuvb3waj).
>>
>
> Very good point, indeed.
> IMO, the new component should be targeted Java 8.
> Even Java 9 (enforcing modularity with JPMS): if by the time we think
> of releasing the code, we still want to avoid "multi-release" JARs it
> will be easy to just remove the "module-info" files (I don't think much
> else Java 9 specific would used by "Commons Statistics").
>
> In fact, given the very slow pace at which new components are being
> brought to releasable state, I'd like to ask whether it would be OK
> to make "incremental" releases?  That would mean: focus on (maven)
> modules that seem close to feature-complete and bug-free, fix the
> remaining issues and perform a release with that module added.
>
> It seems that the expectations were set to high (content-wise given
> the amount of human resources), so that neither CM can be released
> (too many non-fixed issues) nor its "Commons Numbers" spin-off that
> contains many modules, some of which are blocked by lack of consensus
> or dangling discussions.
>
> It probably makes sense, as a design strategy, to separate the function
>> implementation from the streaming implementation. For example, a 2D
>> integer
>> array will probably require a different streaming implementation than a 1D
>> double array, but they can  probably both be passed the same function
>> handle to collect, say, the mean or max value.
>>
>> The role of commons might then be to provide a convenient interface, so
>> that the user can simply call a static method like SummaryStats.mean() and
>> not have to worry about the implementation.
>>
>> The other difficulty I see, is that quantile and median statistics will
>> not
>> be as easy to stream as statistics with a closed-form solution like mean
>> or
>> variance. There may however be great algorithms out there for pulling the
>> median or the 95% quantile out of a stream -- if so they should be used.
>>
>> Eric
>>
>
> Eric,
>
> Would you be the official "mentor" for the GSoC participants that
> are interested in helping with the porting of "o.a.c.math4.stat"?
>
> Thank you,
> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Statistics] Port codes from Commons Math

Gilles Sadowski
Hi.

On Tue, 13 Mar 2018 23:37:24 +0530, Gimhana Nadeeshan wrote:
> Hello Devs,
>
> Thanks Gilles and Eric for guidance.
>
> I have cloned the Commons repos and forked the Common's Stat repo. Is
> it
> possible to make pull requests to that repo to be reviewed?

That's certainly possible, but I'm afraid that it will become
quite unwieldy from my side if I have to delete/create branches
for every PR.

If you want to start playing with the code, we could just begin
by having discussions here (on design) and on JIRA (for processing
minor issues) based on the current state of your repository.
[What's the link to look it up?]

> Or should I
> follow a specific method?

I'll inquire about a more efficient method (than the above)...

> By referring the API docs I got some idea of the separation of
> modules.
>
> In the current Commons's stat repo there are some classes under the
> package  distribution. I think those can be refactored using java 8
> in
> build statistics functionalities. Please correct me if I wrong.

An example perhaps?

> As Eric said separation of function and streaming implementations is
> good
> idea as designing. (In my point of view, it means method overloading
> ->
> Again correct me if I didn't understand your fact correctly)

?

> And I will share my draft proposal here for your review soon.

OK.

Thanks again for your interest,
Gilles

>
> Best Regards.
>
> On 13 March 2018 at 20:50, Gilles <[hidden email]>
> wrote:
>
>> Hello.
>>
>> On Tue, 13 Mar 2018 09:25:19 +0100, Eric Barnhill wrote:
>>
>>> On Tue, Mar 13, 2018 at 12:47 AM, Gilles
>>> <[hidden email]>
>>> wrote:
>>>
>>>
>>>>
>>>>> Where can we find the old code before port into new Commons
>>>>> components?
>>>>>
>>>>>
>>>> The code bases are managed by the "git" software; the whole
>>>> history is
>>>> available:
>>>>  
>>>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log
>>>>
>>>> [I'd advise to "clone" the repositories on your local computer,
>>>> and
>>>> use the command line tools.]
>>>>
>>>
>>>
>>> I believe you will want to clone the commons-math repositories, but
>>> then
>>> develop your own "fork" of the commons-statistics repository.
>>> Gilles can
>>> correct me if that is wrong.
>>>
>>
>> Actually, I know only my workflow:
>>  $ git clone ...
>>  $ git branch ...
>>  $ git commit ...
>>  $ git push
>>
>> :-}
>>
>> I didn't find it very easy to cooperate with developers who
>> fork on GitHub and submit PRs.
>> I've now found the "git" command that creates a branch from
>> a PR, but it would be so much more comfortable to just switch
>> directory and do "git pull".
>>
>> In the context of GSoC, would it be possible to grant some
>> privilege to non-committers so that they can update a selected
>> "git" repository?
>> If not, what is the next easiest way to share a "common space"
>> (aka "sandbox") from which it would be easy to copy reviewed
>> bits over to the official source repository?
>>
>>
>>>> As
>>>>
>>>>> you mentioned it will be a good approach to redesign process.
>>>>>
>>>>>
>>>> You don't necessarily need to analyze how the code was before
>>>> the port/refactoring; looking at how it is now is sufficient,
>>>> unless you suspect that something is wrong now and might have
>>>> been better before. ;-)
>>>>
>>>>
>>> In particular, the statistics library was designed before Java 8.
>>> Java 8
>>> however has provided both efficient programming strategies for
>>> these
>>> statistical methods (in the form of lambdas and streams) as well as
>>> some
>>> built-in methods providing summary statistics functions (see
>>> discussion at
>>> http://markmail.org/message/7t2mjaprsuvb3waj).
>>>
>>
>> Very good point, indeed.
>> IMO, the new component should be targeted Java 8.
>> Even Java 9 (enforcing modularity with JPMS): if by the time we
>> think
>> of releasing the code, we still want to avoid "multi-release" JARs
>> it
>> will be easy to just remove the "module-info" files (I don't think
>> much
>> else Java 9 specific would used by "Commons Statistics").
>>
>> In fact, given the very slow pace at which new components are being
>> brought to releasable state, I'd like to ask whether it would be OK
>> to make "incremental" releases?  That would mean: focus on (maven)
>> modules that seem close to feature-complete and bug-free, fix the
>> remaining issues and perform a release with that module added.
>>
>> It seems that the expectations were set to high (content-wise given
>> the amount of human resources), so that neither CM can be released
>> (too many non-fixed issues) nor its "Commons Numbers" spin-off that
>> contains many modules, some of which are blocked by lack of
>> consensus
>> or dangling discussions.
>>
>> It probably makes sense, as a design strategy, to separate the
>> function
>>> implementation from the streaming implementation. For example, a 2D
>>> integer
>>> array will probably require a different streaming implementation
>>> than a 1D
>>> double array, but they can  probably both be passed the same
>>> function
>>> handle to collect, say, the mean or max value.
>>>
>>> The role of commons might then be to provide a convenient
>>> interface, so
>>> that the user can simply call a static method like
>>> SummaryStats.mean() and
>>> not have to worry about the implementation.
>>>
>>> The other difficulty I see, is that quantile and median statistics
>>> will
>>> not
>>> be as easy to stream as statistics with a closed-form solution like
>>> mean
>>> or
>>> variance. There may however be great algorithms out there for
>>> pulling the
>>> median or the 95% quantile out of a stream -- if so they should be
>>> used.
>>>
>>> Eric
>>>
>>
>> Eric,
>>
>> Would you be the official "mentor" for the GSoC participants that
>> are interested in helping with the porting of "o.a.c.math4.stat"?
>>
>> Thank you,
>> Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github usage Was: [Statistics] Port codes from Commons Math

Gilles Sadowski
In reply to this post by Adam Soroka
On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:

>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>> wrote:
>>
>>
>> I didn't find it very easy to cooperate with developers who fork on
>> GitHub and submit PRs. I've now found the "git" command that creates a
>> branch from a PR, but it would be so much more comfortable to just
>> switch directory and do "git pull".
>>
>
> Just as a point of information, it is possible to reverse the Github
> <- Apache mirroring most projects use to be Github -> Apache.

It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles

> What
> that means is that merging PRs from Github becomes one click in the
> Github UI.
>
> There are other consequences, of course, especially related to other
> integrations Commons may be using (e.g. integration between Github
> and
> JIRA).
>
> Of course, INFRA are the folks to talk to if this sounds interesting.
> At Apache Jena, we looked into it but have taken no action because we
> still have some open questions about when some of our workflow
> integrations will become possible with "reversed mirroring".
>
> Adam Soroka ; [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github usage Was: [Statistics] Port codes from Commons Math

Otto Fowler
We have script to help reviewers checkout PR’s in git, either in their own
repo
or just doing it in ~/tmp or something into a new repo.

So, I would run:

> checkout-pr 999

in the tmp directory, and end up with a local version that I can then build
and do whatever with.
would that help?


On March 14, 2018 at 10:08:47, Gilles ([hidden email]) wrote:

On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:

>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>> wrote:
>>
>>
>> I didn't find it very easy to cooperate with developers who fork on
>> GitHub and submit PRs. I've now found the "git" command that creates a
>> branch from a PR, but it would be so much more comfortable to just
>> switch directory and do "git pull".
>>
>
> Just as a point of information, it is possible to reverse the Github
> <- Apache mirroring most projects use to be Github -> Apache.

It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles

> What
> that means is that merging PRs from Github becomes one click in the
> Github UI.
>
> There are other consequences, of course, especially related to other
> integrations Commons may be using (e.g. integration between Github
> and
> JIRA).
>
> Of course, INFRA are the folks to talk to if this sounds interesting.
> At Apache Jena, we looked into it but have taken no action because we
> still have some open questions about when some of our workflow
> integrations will become possible with "reversed mirroring".
>
> Adam Soroka ; [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Github usage Was: [Statistics] Port codes from Commons Math

Otto Fowler
I should be more specific, this is for looking at github pr’s.
So if your submitters are forking, submitting prs on github.

We also have scripts for committing, but we are doing git -> github mirror

On March 14, 2018 at 10:15:04, Otto Fowler ([hidden email]) wrote:

We have script to help reviewers checkout PR’s in git, either in their own
repo
or just doing it in ~/tmp or something into a new repo.

So, I would run:

> checkout-pr 999

in the tmp directory, and end up with a local version that I can then build
and do whatever with.
would that help?


On March 14, 2018 at 10:08:47, Gilles ([hidden email]) wrote:

On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:

>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>> wrote:
>>
>>
>> I didn't find it very easy to cooperate with developers who fork on
>> GitHub and submit PRs. I've now found the "git" command that creates a
>> branch from a PR, but it would be so much more comfortable to just
>> switch directory and do "git pull".
>>
>
> Just as a point of information, it is possible to reverse the Github
> <- Apache mirroring most projects use to be Github -> Apache.

It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles

> What
> that means is that merging PRs from Github becomes one click in the
> Github UI.
>
> There are other consequences, of course, especially related to other
> integrations Commons may be using (e.g. integration between Github
> and
> JIRA).
>
> Of course, INFRA are the folks to talk to if this sounds interesting.
> At Apache Jena, we looked into it but have taken no action because we
> still have some open questions about when some of our workflow
> integrations will become possible with "reversed mirroring".
>
> Adam Soroka ; [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Gilles Sadowski
Hi.

On Wed, 14 Mar 2018 14:16:42 +0000, Otto Fowler wrote:
> I should be more specific, this is for looking at github pr’s.
> So if your submitters are forking, submitting prs on github.
>
> We also have scripts for committing, but we are doing git -> github
> mirror

My knowledge of "git" is small; my knowledge of GitHub smaller
(and zero for functionalities that require being logged in). :-}

Assuming a "git" repository (where "origin" is on an Apache server)
with a local "clone" (i.e. on my machine), is it possible to create
a branch, say "gimo_work", such that

  $ git checkout gimo_work
  $ git ... ? ... (equivalent to "pull" wrt "origin")

will retrieve the latest Gimo's commits on the fork made
from the Apache repository?

Gilles

> On March 14, 2018 at 10:15:04, Otto Fowler ([hidden email])
> wrote:
>
> We have script to help reviewers checkout PR’s in git, either in
> their own
> repo
> or just doing it in ~/tmp or something into a new repo.
>
> So, I would run:
>
>> checkout-pr 999
>
> in the tmp directory, and end up with a local version that I can then
> build
> and do whatever with.
> would that help?
>
>
> On March 14, 2018 at 10:08:47, Gilles ([hidden email])
> wrote:
>
> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>>> wrote:
>>>
>>>
>>> I didn't find it very easy to cooperate with developers who fork on
>>> GitHub and submit PRs. I've now found the "git" command that
>>> creates a
>>> branch from a PR, but it would be so much more comfortable to just
>>> switch directory and do "git pull".
>>>
>>
>> Just as a point of information, it is possible to reverse the Github
>> <- Apache mirroring most projects use to be Github -> Apache.
>
> It seems that a good-enough-for-me solution would be to "clone"
> (on my local system) the repository forked by the GSoC participant.
>
> Does it make sense?
>
> Thanks,
> Gilles
>
>> What
>> that means is that merging PRs from Github becomes one click in the
>> Github UI.
>>
>> There are other consequences, of course, especially related to other
>> integrations Commons may be using (e.g. integration between Github
>> and
>> JIRA).
>>
>> Of course, INFRA are the folks to talk to if this sounds
>> interesting.
>> At Apache Jena, we looked into it but have taken no action because
>> we
>> still have some open questions about when some of our workflow
>> integrations will become possible with "reversed mirroring".
>>
>> Adam Soroka ; [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Matt Sicker
When you have a GitHub origin, you can checkout pulls/42/head to check out
PR#42. You can pull/merge from that branch as well to merge the PR (by
committing and pushing that merge, GitHub will notice and mark the PR as
merged). You can also use the "hub" command line tool that GitHub publishes
which adds a bunch of convenience commands to do the same thing.

On 14 March 2018 at 10:19, Gilles <[hidden email]> wrote:

> Hi.
>
> On Wed, 14 Mar 2018 14:16:42 +0000, Otto Fowler wrote:
>
>> I should be more specific, this is for looking at github pr’s.
>> So if your submitters are forking, submitting prs on github.
>>
>> We also have scripts for committing, but we are doing git -> github mirror
>>
>
> My knowledge of "git" is small; my knowledge of GitHub smaller
> (and zero for functionalities that require being logged in). :-}
>
> Assuming a "git" repository (where "origin" is on an Apache server)
> with a local "clone" (i.e. on my machine), is it possible to create
> a branch, say "gimo_work", such that
>
>  $ git checkout gimo_work
>  $ git ... ? ... (equivalent to "pull" wrt "origin")
>
> will retrieve the latest Gimo's commits on the fork made
> from the Apache repository?
>
> Gilles
>
> On March 14, 2018 at 10:15:04, Otto Fowler ([hidden email])
>> wrote:
>>
>> We have script to help reviewers checkout PR’s in git, either in their own
>> repo
>> or just doing it in ~/tmp or something into a new repo.
>>
>> So, I would run:
>>
>> checkout-pr 999
>>>
>>
>> in the tmp directory, and end up with a local version that I can then
>> build
>> and do whatever with.
>> would that help?
>>
>>
>> On March 14, 2018 at 10:08:47, Gilles ([hidden email])
>> wrote:
>>
>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>
>>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>>
>>>> I didn't find it very easy to cooperate with developers who fork on
>>>> GitHub and submit PRs. I've now found the "git" command that creates a
>>>> branch from a PR, but it would be so much more comfortable to just
>>>> switch directory and do "git pull".
>>>>
>>>>
>>> Just as a point of information, it is possible to reverse the Github
>>> <- Apache mirroring most projects use to be Github -> Apache.
>>>
>>
>> It seems that a good-enough-for-me solution would be to "clone"
>> (on my local system) the repository forked by the GSoC participant.
>>
>> Does it make sense?
>>
>> Thanks,
>> Gilles
>>
>> What
>>> that means is that merging PRs from Github becomes one click in the
>>> Github UI.
>>>
>>> There are other consequences, of course, especially related to other
>>> integrations Commons may be using (e.g. integration between Github
>>> and
>>> JIRA).
>>>
>>> Of course, INFRA are the folks to talk to if this sounds interesting.
>>> At Apache Jena, we looked into it but have taken no action because we
>>> still have some open questions about when some of our workflow
>>> integrations will become possible with "reversed mirroring".
>>>
>>> Adam Soroka ; [hidden email]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Gilles Sadowski
Hi.

On Wed, 14 Mar 2018 11:27:38 -0500, Matt Sicker wrote:
> When you have a GitHub origin, you can checkout pulls/42/head to
> check out
> PR#42. You can pull/merge from that branch as well to merge the PR
> (by
> committing and pushing that merge, GitHub will notice and mark the PR
> as
> merged). You can also use the "hub" command line tool that GitHub
> publishes
> which adds a bunch of convenience commands to do the same thing.

Following your hint, I've installed (Debian) a package named
"git-hub"; assuming this is the tool.

Now, I'll need the link to Gimo's "forked" repository of the
"Commons Statistics" GitHub mirror...

Regards,
Gilles

> On 14 March 2018 at 10:19, Gilles <[hidden email]>
> wrote:
>
>> Hi.
>>
>> On Wed, 14 Mar 2018 14:16:42 +0000, Otto Fowler wrote:
>>
>>> I should be more specific, this is for looking at github pr’s.
>>> So if your submitters are forking, submitting prs on github.
>>>
>>> We also have scripts for committing, but we are doing git -> github
>>> mirror
>>>
>>
>> My knowledge of "git" is small; my knowledge of GitHub smaller
>> (and zero for functionalities that require being logged in). :-}
>>
>> Assuming a "git" repository (where "origin" is on an Apache server)
>> with a local "clone" (i.e. on my machine), is it possible to create
>> a branch, say "gimo_work", such that
>>
>>  $ git checkout gimo_work
>>  $ git ... ? ... (equivalent to "pull" wrt "origin")
>>
>> will retrieve the latest Gimo's commits on the fork made
>> from the Apache repository?
>>
>> Gilles
>>
>> On March 14, 2018 at 10:15:04, Otto Fowler ([hidden email])
>>> wrote:
>>>
>>> We have script to help reviewers checkout PR’s in git, either in
>>> their own
>>> repo
>>> or just doing it in ~/tmp or something into a new repo.
>>>
>>> So, I would run:
>>>
>>> checkout-pr 999
>>>>
>>>
>>> in the tmp directory, and end up with a local version that I can
>>> then
>>> build
>>> and do whatever with.
>>> would that help?
>>>
>>>
>>> On March 14, 2018 at 10:08:47, Gilles
>>> ([hidden email])
>>> wrote:
>>>
>>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>>
>>>> On Mar 13, 2018, at 11:20 AM, Gilles
>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>
>>>>> I didn't find it very easy to cooperate with developers who fork
>>>>> on
>>>>> GitHub and submit PRs. I've now found the "git" command that
>>>>> creates a
>>>>> branch from a PR, but it would be so much more comfortable to
>>>>> just
>>>>> switch directory and do "git pull".
>>>>>
>>>>>
>>>> Just as a point of information, it is possible to reverse the
>>>> Github
>>>> <- Apache mirroring most projects use to be Github -> Apache.
>>>>
>>>
>>> It seems that a good-enough-for-me solution would be to "clone"
>>> (on my local system) the repository forked by the GSoC participant.
>>>
>>> Does it make sense?
>>>
>>> Thanks,
>>> Gilles
>>>
>>> What
>>>> that means is that merging PRs from Github becomes one click in
>>>> the
>>>> Github UI.
>>>>
>>>> There are other consequences, of course, especially related to
>>>> other
>>>> integrations Commons may be using (e.g. integration between Github
>>>> and
>>>> JIRA).
>>>>
>>>> Of course, INFRA are the folks to talk to if this sounds
>>>> interesting.
>>>> At Apache Jena, we looked into it but have taken no action because
>>>> we
>>>> still have some open questions about when some of our workflow
>>>> integrations will become possible with "reversed mirroring".
>>>>
>>>> Adam Soroka ; [hidden email]
>>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Matt Sicker
I can't find that package on debian's package search page. I'm not sure if
they package it there (it's a go program, so it's pretty easy to install if
you have go already). Here's the official site: https://hub.github.com/

On 15 March 2018 at 10:19, Gilles <[hidden email]> wrote:

> Hi.
>
> On Wed, 14 Mar 2018 11:27:38 -0500, Matt Sicker wrote:
>
>> When you have a GitHub origin, you can checkout pulls/42/head to check out
>> PR#42. You can pull/merge from that branch as well to merge the PR (by
>> committing and pushing that merge, GitHub will notice and mark the PR as
>> merged). You can also use the "hub" command line tool that GitHub
>> publishes
>> which adds a bunch of convenience commands to do the same thing.
>>
>
> Following your hint, I've installed (Debian) a package named
> "git-hub"; assuming this is the tool.
>
> Now, I'll need the link to Gimo's "forked" repository of the
> "Commons Statistics" GitHub mirror...
>
> Regards,
> Gilles
>
>
> On 14 March 2018 at 10:19, Gilles <[hidden email]> wrote:
>>
>> Hi.
>>>
>>> On Wed, 14 Mar 2018 14:16:42 +0000, Otto Fowler wrote:
>>>
>>> I should be more specific, this is for looking at github pr’s.
>>>> So if your submitters are forking, submitting prs on github.
>>>>
>>>> We also have scripts for committing, but we are doing git -> github
>>>> mirror
>>>>
>>>>
>>> My knowledge of "git" is small; my knowledge of GitHub smaller
>>> (and zero for functionalities that require being logged in). :-}
>>>
>>> Assuming a "git" repository (where "origin" is on an Apache server)
>>> with a local "clone" (i.e. on my machine), is it possible to create
>>> a branch, say "gimo_work", such that
>>>
>>>  $ git checkout gimo_work
>>>  $ git ... ? ... (equivalent to "pull" wrt "origin")
>>>
>>> will retrieve the latest Gimo's commits on the fork made
>>> from the Apache repository?
>>>
>>> Gilles
>>>
>>> On March 14, 2018 at 10:15:04, Otto Fowler ([hidden email])
>>>
>>>> wrote:
>>>>
>>>> We have script to help reviewers checkout PR’s in git, either in their
>>>> own
>>>> repo
>>>> or just doing it in ~/tmp or something into a new repo.
>>>>
>>>> So, I would run:
>>>>
>>>> checkout-pr 999
>>>>
>>>>>
>>>>>
>>>> in the tmp directory, and end up with a local version that I can then
>>>> build
>>>> and do whatever with.
>>>> would that help?
>>>>
>>>>
>>>> On March 14, 2018 at 10:08:47, Gilles ([hidden email])
>>>> wrote:
>>>>
>>>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>>>
>>>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> I didn't find it very easy to cooperate with developers who fork on
>>>>>> GitHub and submit PRs. I've now found the "git" command that creates a
>>>>>> branch from a PR, but it would be so much more comfortable to just
>>>>>> switch directory and do "git pull".
>>>>>>
>>>>>>
>>>>>> Just as a point of information, it is possible to reverse the Github
>>>>> <- Apache mirroring most projects use to be Github -> Apache.
>>>>>
>>>>>
>>>> It seems that a good-enough-for-me solution would be to "clone"
>>>> (on my local system) the repository forked by the GSoC participant.
>>>>
>>>> Does it make sense?
>>>>
>>>> Thanks,
>>>> Gilles
>>>>
>>>> What
>>>>
>>>>> that means is that merging PRs from Github becomes one click in the
>>>>> Github UI.
>>>>>
>>>>> There are other consequences, of course, especially related to other
>>>>> integrations Commons may be using (e.g. integration between Github
>>>>> and
>>>>> JIRA).
>>>>>
>>>>> Of course, INFRA are the folks to talk to if this sounds interesting.
>>>>> At Apache Jena, we looked into it but have taken no action because we
>>>>> still have some open questions about when some of our workflow
>>>>> integrations will become possible with "reversed mirroring".
>>>>>
>>>>> Adam Soroka ; [hidden email]
>>>>>
>>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Gilles Sadowski
On Thu, 15 Mar 2018 10:39:50 -0500, Matt Sicker wrote:
> I can't find that package on debian's package search page.

https://packages.debian.org/stretch/git-hub

> I'm not sure if
> they package it there

There is a slew of golang-related packages.

> (it's a go program, so it's pretty easy to install if
> you have go already).

I don't have it installed.

> Here's the official site: https://hub.github.com/

If possible, I'd prefer installing it through the distribution.

Regards,
Gilles

>>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Matt Sicker
Oh, I was looking at the wrong version of Debian I think.

On 15 March 2018 at 11:01, Gilles <[hidden email]> wrote:

> On Thu, 15 Mar 2018 10:39:50 -0500, Matt Sicker wrote:
>
>> I can't find that package on debian's package search page.
>>
>
> https://packages.debian.org/stretch/git-hub
>
> I'm not sure if
>> they package it there
>>
>
> There is a slew of golang-related packages.
>
> (it's a go program, so it's pretty easy to install if
>> you have go already).
>>
>
> I don't have it installed.
>
> Here's the official site: https://hub.github.com/
>>
>
> If possible, I'd prefer installing it through the distribution.
>
> Regards,
> Gilles
>
> [...]
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Adam Soroka
In reply to this post by Matt Sicker
One gotcha that has bit me before-- if the PR isn't rebased over the current master (assuming you are merging into master) it may still be merge-able because maybe there aren't any conflicts. (E.g. maybe no one has worked on that section of the codebase since the PR's branch was branched.)

But if you merge without rebasing, Apache's mirroring won't realize that the PR should be closed (as I understand it, because the commits will have different hashes since they are diffs between different places on the tree). So best to rebase if needed, but you forget and this happens to you, you can still rebase and force-push the PR branch, and then Apache's mirroring will catch up and close the PR "posthumously". Or of course you can always close it manually on Github.

I make this mistake about once a month or so. :(

ajs6f

> On Mar 14, 2018, at 12:27 PM, Matt Sicker <[hidden email]> wrote:
>
> When you have a GitHub origin, you can checkout pulls/42/head to check out
> PR#42. You can pull/merge from that branch as well to merge the PR (by
> committing and pushing that merge, GitHub will notice and mark the PR as
> merged). You can also use the "hub" command line tool that GitHub publishes
> which adds a bunch of convenience commands to do the same thing.
>
> On 14 March 2018 at 10:19, Gilles <[hidden email]> wrote:
>
>> Hi.
>>
>> On Wed, 14 Mar 2018 14:16:42 +0000, Otto Fowler wrote:
>>
>>> I should be more specific, this is for looking at github pr’s.
>>> So if your submitters are forking, submitting prs on github.
>>>
>>> We also have scripts for committing, but we are doing git -> github mirror
>>>
>>
>> My knowledge of "git" is small; my knowledge of GitHub smaller
>> (and zero for functionalities that require being logged in). :-}
>>
>> Assuming a "git" repository (where "origin" is on an Apache server)
>> with a local "clone" (i.e. on my machine), is it possible to create
>> a branch, say "gimo_work", such that
>>
>> $ git checkout gimo_work
>> $ git ... ? ... (equivalent to "pull" wrt "origin")
>>
>> will retrieve the latest Gimo's commits on the fork made
>> from the Apache repository?
>>
>> Gilles
>>
>> On March 14, 2018 at 10:15:04, Otto Fowler ([hidden email])
>>> wrote:
>>>
>>> We have script to help reviewers checkout PR’s in git, either in their own
>>> repo
>>> or just doing it in ~/tmp or something into a new repo.
>>>
>>> So, I would run:
>>>
>>> checkout-pr 999
>>>>
>>>
>>> in the tmp directory, and end up with a local version that I can then
>>> build
>>> and do whatever with.
>>> would that help?
>>>
>>>
>>> On March 14, 2018 at 10:08:47, Gilles ([hidden email])
>>> wrote:
>>>
>>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>>
>>>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>
>>>>> I didn't find it very easy to cooperate with developers who fork on
>>>>> GitHub and submit PRs. I've now found the "git" command that creates a
>>>>> branch from a PR, but it would be so much more comfortable to just
>>>>> switch directory and do "git pull".
>>>>>
>>>>>
>>>> Just as a point of information, it is possible to reverse the Github
>>>> <- Apache mirroring most projects use to be Github -> Apache.
>>>>
>>>
>>> It seems that a good-enough-for-me solution would be to "clone"
>>> (on my local system) the repository forked by the GSoC participant.
>>>
>>> Does it make sense?
>>>
>>> Thanks,
>>> Gilles
>>>
>>> What
>>>> that means is that merging PRs from Github becomes one click in the
>>>> Github UI.
>>>>
>>>> There are other consequences, of course, especially related to other
>>>> integrations Commons may be using (e.g. integration between Github
>>>> and
>>>> JIRA).
>>>>
>>>> Of course, INFRA are the folks to talk to if this sounds interesting.
>>>> At Apache Jena, we looked into it but have taken no action because we
>>>> still have some open questions about when some of our workflow
>>>> integrations will become possible with "reversed mirroring".
>>>>
>>>> Adam Soroka ; [hidden email]
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Matt Sicker <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github usage

Otto Fowler
https://github.com/apache/metron/tree/master/dev-utilities/committer-utils
if you just want the bash


On March 15, 2018 at 13:51:00, ajs6f ([hidden email]) wrote:

One gotcha that has bit me before-- if the PR isn't rebased over the
current master (assuming you are merging into master) it may still be
merge-able because maybe there aren't any conflicts. (E.g. maybe no one has
worked on that section of the codebase since the PR's branch was branched.)

But if you merge without rebasing, Apache's mirroring won't realize that
the PR should be closed (as I understand it, because the commits will have
different hashes since they are diffs between different places on the
tree). So best to rebase if needed, but you forget and this happens to you,
you can still rebase and force-push the PR branch, and then Apache's
mirroring will catch up and close the PR "posthumously". Or of course you
can always close it manually on Github.

I make this mistake about once a month or so. :(

ajs6f

> On Mar 14, 2018, at 12:27 PM, Matt Sicker <[hidden email]> wrote:
>
> When you have a GitHub origin, you can checkout pulls/42/head to check
out
> PR#42. You can pull/merge from that branch as well to merge the PR (by
> committing and pushing that merge, GitHub will notice and mark the PR as
> merged). You can also use the "hub" command line tool that GitHub
publishes

> which adds a bunch of convenience commands to do the same thing.
>
> On 14 March 2018 at 10:19, Gilles <[hidden email]> wrote:
>
>> Hi.
>>
>> On Wed, 14 Mar 2018 14:16:42 +0000, Otto Fowler wrote:
>>
>>> I should be more specific, this is for looking at github pr’s.
>>> So if your submitters are forking, submitting prs on github.
>>>
>>> We also have scripts for committing, but we are doing git -> github
mirror

>>>
>>
>> My knowledge of "git" is small; my knowledge of GitHub smaller
>> (and zero for functionalities that require being logged in). :-}
>>
>> Assuming a "git" repository (where "origin" is on an Apache server)
>> with a local "clone" (i.e. on my machine), is it possible to create
>> a branch, say "gimo_work", such that
>>
>> $ git checkout gimo_work
>> $ git ... ? ... (equivalent to "pull" wrt "origin")
>>
>> will retrieve the latest Gimo's commits on the fork made
>> from the Apache repository?
>>
>> Gilles
>>
>> On March 14, 2018 at 10:15:04, Otto Fowler ([hidden email])
>>> wrote:
>>>
>>> We have script to help reviewers checkout PR’s in git, either in their
own

>>> repo
>>> or just doing it in ~/tmp or something into a new repo.
>>>
>>> So, I would run:
>>>
>>> checkout-pr 999
>>>>
>>>
>>> in the tmp directory, and end up with a local version that I can then
>>> build
>>> and do whatever with.
>>> would that help?
>>>
>>>
>>> On March 14, 2018 at 10:08:47, Gilles ([hidden email])
>>> wrote:
>>>
>>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>>
>>>> On Mar 13, 2018, at 11:20 AM, Gilles <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>
>>>>> I didn't find it very easy to cooperate with developers who fork on
>>>>> GitHub and submit PRs. I've now found the "git" command that creates
a

>>>>> branch from a PR, but it would be so much more comfortable to just
>>>>> switch directory and do "git pull".
>>>>>
>>>>>
>>>> Just as a point of information, it is possible to reverse the Github
>>>> <- Apache mirroring most projects use to be Github -> Apache.
>>>>
>>>
>>> It seems that a good-enough-for-me solution would be to "clone"
>>> (on my local system) the repository forked by the GSoC participant.
>>>
>>> Does it make sense?
>>>
>>> Thanks,
>>> Gilles
>>>
>>> What
>>>> that means is that merging PRs from Github becomes one click in the
>>>> Github UI.
>>>>
>>>> There are other consequences, of course, especially related to other
>>>> integrations Commons may be using (e.g. integration between Github
>>>> and
>>>> JIRA).
>>>>
>>>> Of course, INFRA are the folks to talk to if this sounds interesting.
>>>> At Apache Jena, we looked into it but have taken no action because we
>>>> still have some open questions about when some of our workflow
>>>> integrations will become possible with "reversed mirroring".
>>>>
>>>> Adam Soroka ; [hidden email]
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Matt Sicker <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
123