Need for an alternatives to the main line of code.

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

Need for an alternatives to the main line of code.

Ajo Fod
My 2c worth. It seems like there is a general bottleneck. A lot of ideas
don't get used because there is a hurdle that people have to make change
that satisfy all code requirements like tests/reuse of blocks etc. This
makes for a larger than necessary hurdle for people to contribute.

Looks like Gilles tried to solve this problem. One alternative is to place
alternative/new code in a nursery/experimental package parallel to the main
line of code. This nursery code wouldn't be subject to the deprecation step
or stability guarantees. The nursery packages should be better than the
main line of code or solve an unsolved problem demonstrated with
appropriate tests.

That way, users will be aware of and can benefit from the ability to solve
a problem in CM. This will also be "advertisement" for the needed work to
include the work in the main line of code.

Cheers,
-Ajo
Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

garydgregory
On the point of tests: Considering tests a hurdle is the wrong way to look
at it. Tests are the foundation I can confidently build on and change code.

Gary


On Tue, Aug 20, 2013 at 3:07 PM, Ajo Fod <[hidden email]> wrote:

> My 2c worth. It seems like there is a general bottleneck. A lot of ideas
> don't get used because there is a hurdle that people have to make change
> that satisfy all code requirements like tests/reuse of blocks etc. This
> makes for a larger than necessary hurdle for people to contribute.
>
> Looks like Gilles tried to solve this problem. One alternative is to place
> alternative/new code in a nursery/experimental package parallel to the main
> line of code. This nursery code wouldn't be subject to the deprecation step
> or stability guarantees. The nursery packages should be better than the
> main line of code or solve an unsolved problem demonstrated with
> appropriate tests.
>
> That way, users will be aware of and can benefit from the ability to solve
> a problem in CM. This will also be "advertisement" for the needed work to
> include the work in the main line of code.
>
> Cheers,
> -Ajo
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Ajo Fod
I agree that in general test are necessary to ensure that something useful
is being accomplished by the submitted code as I'd mentioned in my mail.

I admire the rigour of tests in CM. There was one case where I didn't know
what needs be tested and I didn't see the point in taking it further since
I'd copied the code over to a personal package and patched it as I saw fit.

All I'm saying is that sometimes commiters are in a better position to
judge what needs to be tested and either suggest tests or even add it if it
is simple enough.
https://issues.apache.org/jira/browse/MATH-999

Cheers,
-Ajo


On Tue, Aug 20, 2013 at 1:30 PM, Gary Gregory <[hidden email]>wrote:

> On the point of tests: Considering tests a hurdle is the wrong way to look
> at it. Tests are the foundation I can confidently build on and change code.
>
> Gary
>
>
> On Tue, Aug 20, 2013 at 3:07 PM, Ajo Fod <[hidden email]> wrote:
>
> > My 2c worth. It seems like there is a general bottleneck. A lot of ideas
> > don't get used because there is a hurdle that people have to make change
> > that satisfy all code requirements like tests/reuse of blocks etc. This
> > makes for a larger than necessary hurdle for people to contribute.
> >
> > Looks like Gilles tried to solve this problem. One alternative is to
> place
> > alternative/new code in a nursery/experimental package parallel to the
> main
> > line of code. This nursery code wouldn't be subject to the deprecation
> step
> > or stability guarantees. The nursery packages should be better than the
> > main line of code or solve an unsolved problem demonstrated with
> > appropriate tests.
> >
> > That way, users will be aware of and can benefit from the ability to
> solve
> > a problem in CM. This will also be "advertisement" for the needed work to
> > include the work in the main line of code.
> >
> > Cheers,
> > -Ajo
> >
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Gilles Sadowski
On Tue, 20 Aug 2013 14:55:51 -0700, Ajo Fod wrote:

> I agree that in general test are necessary to ensure that something
> useful
> is being accomplished by the submitted code as I'd mentioned in my
> mail.
>
> I admire the rigour of tests in CM. There was one case where I didn't
> know
> what needs be tested and I didn't see the point in taking it further
> since
> I'd copied the code over to a personal package and patched it as I
> saw fit.

Good for you...

> All I'm saying is that sometimes commiters are in a better position
> to
> judge what needs to be tested

A: Everything (ideally).
Q: What should be covered by unit tests?

> and either suggest tests or even add it if it
> is simple enough.
> https://issues.apache.org/jira/browse/MATH-999

CM is a collaborative work. Please refer to the archive for
(re-)reading
what this means (ideally).

On the subject of this thread: I did not imply that an "experimental"
package would allow sloppy or undocumented code or bypass unit testing.
All (the above) things being equal, the purpose would be to compare
alternative designs.


Gilles

>
> Cheers,
> -Ajo
>
>
> On Tue, Aug 20, 2013 at 1:30 PM, Gary Gregory
> <[hidden email]>wrote:
>
>> On the point of tests: Considering tests a hurdle is the wrong way
>> to look
>> at it. Tests are the foundation I can confidently build on and
>> change code.
>>
>> Gary
>>
>>
>> On Tue, Aug 20, 2013 at 3:07 PM, Ajo Fod <[hidden email]> wrote:
>>
>> > My 2c worth. It seems like there is a general bottleneck. A lot of
>> ideas
>> > don't get used because there is a hurdle that people have to make
>> change
>> > that satisfy all code requirements like tests/reuse of blocks etc.
>> This
>> > makes for a larger than necessary hurdle for people to contribute.
>> >
>> > Looks like Gilles tried to solve this problem. One alternative is
>> to
>> place
>> > alternative/new code in a nursery/experimental package parallel to
>> the
>> main
>> > line of code. This nursery code wouldn't be subject to the
>> deprecation
>> step
>> > or stability guarantees. The nursery packages should be better
>> than the
>> > main line of code or solve an unsolved problem demonstrated with
>> > appropriate tests.
>> >
>> > That way, users will be aware of and can benefit from the ability
>> to
>> solve
>> > a problem in CM. This will also be "advertisement" for the needed
>> work to
>> > include the work in the main line of code.
>> >
>> > Cheers,
>> > -Ajo
>> >
>>
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Konstantin Berlin
Before someone spend time rewriting the whole package, wouldn't we want the
ability to comment on a skeleton design that might not pass unit tests?

On Tuesday, August 20, 2013, Gilles wrote:

> On Tue, 20 Aug 2013 14:55:51 -0700, Ajo Fod wrote:
>
>> I agree that in general test are necessary to ensure that something useful
>> is being accomplished by the submitted code as I'd mentioned in my mail.
>>
>> I admire the rigour of tests in CM. There was one case where I didn't know
>> what needs be tested and I didn't see the point in taking it further since
>> I'd copied the code over to a personal package and patched it as I saw
>> fit.
>>
>
> Good for you...
>
>  All I'm saying is that sometimes commiters are in a better position to
>> judge what needs to be tested
>>
>
> A: Everything (ideally).
> Q: What should be covered by unit tests?
>
>  and either suggest tests or even add it if it
>> is simple enough.
>> https://issues.apache.org/**jira/browse/MATH-999<https://issues.apache.org/jira/browse/MATH-999>
>>
>
> CM is a collaborative work. Please refer to the archive for (re-)reading
> what this means (ideally).
>
> On the subject of this thread: I did not imply that an "experimental"
> package would allow sloppy or undocumented code or bypass unit testing.
> All (the above) things being equal, the purpose would be to compare
> alternative designs.
>
>
> Gilles
>
>
>> Cheers,
>> -Ajo
>>
>>
>> On Tue, Aug 20, 2013 at 1:30 PM, Gary Gregory <[hidden email]
>> >wrote:
>>
>>  On the point of tests: Considering tests a hurdle is the wrong way to
>>> look
>>> at it. Tests are the foundation I can confidently build on and change
>>> code.
>>>
>>> Gary
>>>
>>>
>>> On Tue, Aug 20, 2013 at 3:07 PM, Ajo Fod <[hidden email]> wrote:
>>>
>>> > My 2c worth. It seems like there is a general bottleneck. A lot of
>>> ideas
>>> > don't get used because there is a hurdle that people have to make
>>> change
>>> > that satisfy all code requirements like tests/reuse of blocks etc. This
>>> > makes for a larger than necessary hurdle for people to contribute.
>>> >
>>> > Looks like Gilles tried to solve this problem. One alternative is to
>>> place
>>> > alternative/new code in a nursery/experimental package parallel to the
>>> main
>>> > line of code. This nursery code wouldn't be subject to the deprecation
>>> step
>>> > or stability guarantees. The nursery packages should be better than the
>>> > main line of code or solve an unsolved problem demonstrated with
>>> > appropriate tests.
>>> >
>>> > That way, users will be aware of and can benefit from the ability to
>>> solve
>>> > a problem in CM. This will also be "advertisement" for the needed work
>>> to
>>> > include the work in the main line of code.
>>> >
>>> > Cheers,
>>> > -Ajo
>>> >
>>>
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> Java Persistence with Hibernate, Second Edition<
>>> http://www.manning.com/bauer3/**>
>>> JUnit in Action, Second Edition <http://www.manning.com/**tahchiev/<http://www.manning.com/tahchiev/>
>>> >
>>> Spring Batch in Action <http://www.manning.com/**templier/<http://www.manning.com/templier/>
>>> >
>>> Blog: http://garygregory.wordpress.**com<http://garygregory.wordpress.com>
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Ajo Fod
In reply to this post by Gilles Sadowski
Good for you...

Yes just imagine if I'd to get every fix through committers. I'd never get
anything done here.


> On the subject of this thread: I did not imply that an "experimental"
> package would allow sloppy or undocumented code or bypass unit testing.
> All (the above) things being equal, the purpose would be to compare
> alternative designs.
>

Perhaps I was not clear. Once again I repeat: I agree with the need for
comments clean code and unit tests demonstrate the incremental utility of
the contribution in the "experimental" package.

I merely disagree that all contributors have the knowledge or the
incentives to test "Everything (ideally)", reuse other Commons components,
comment on "Everything", and in the case of CM analytically prove that the
underlying math is sound, analyze when the code might fail, compare it with
all other known methods, etc. So, if "half-baked" code (that solves a known
problem) exists in the experimental packages, people who really need it to
be reliably tested can patch in the tests and promote the code to
"fully-baked" status.

I hope you'll agree that as it stands, this makes CM capable of only
solving a subset the mathematical problems of what it can solve with a more
open policy.

The argument for alternative designs of the API is great too because it
allows people to comment on the API design as they use it.

Cheers,
Ajo.
Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Ted Dunning
+1

Sent from my iPhone

On Aug 21, 2013, at 9:42, Ajo Fod <[hidden email]> wrote:

>
> I hope you'll agree that as it stands, this makes CM capable of only
> solving a subset the mathematical problems of what it can solve with a more
> open policy.
>
> The argument for alternative designs of the API is great too because it
> allows people to comment on the API design as they use it.

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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Gilles Sadowski
In reply to this post by Ajo Fod
On Wed, 21 Aug 2013 09:42:09 -0700, Ajo Fod wrote:
> Good for you...
>
> Yes just imagine if I'd to get every fix through committers. I'd
> never get
> anything done here.

Not every fix; commit to start with one.
I've spent a _lot_ of time detailing what you could do to go forward
with the issues which you submitted. And you simply ignored it all,
plainly saying that I'm free to do the work myself.

>> On the subject of this thread: I did not imply that an
>> "experimental"
>> package would allow sloppy or undocumented code or bypass unit
>> testing.
>> All (the above) things being equal, the purpose would be to compare
>> alternative designs.
>>
>
> Perhaps I was not clear. Once again I repeat: I agree with the need
> for
> comments clean code and unit tests demonstrate the incremental
> utility of
> the contribution in the "experimental" package.

And you have been very clear that you expect other people to do the
work.

> I merely disagree that all contributors have the knowledge or the
> incentives to test "Everything (ideally)", reuse other Commons
> components,
> comment on "Everything", and in the case of CM analytically prove
> that the
> underlying math is sound, analyze when the code might fail, compare
> it with
> all other known methods, etc. So, if "half-baked" code (that solves a
> known
> problem) exists in the experimental packages, people who really need
> it to
> be reliably tested can patch in the tests and promote the code to
> "fully-baked" status.

I think that there exist projects out there that collect any code that
purports to solve some problem.

> I hope you'll agree that as it stands, this makes CM capable of only
> solving a subset the mathematical problems of what it can solve with
> a more
> open policy.

I think that you are wrong. Even as we try to abide by rules, cruft
and bugs accumulate; loosening the policy will just make it worse.

Phil explained the policy for Apache Commons projects. Personally, I've
also my reservations about some ill-defined aspects of the policy. But
I'm certainly not backing a proposal that amounts to unbounded
maintenance
work for the committers.

> The argument for alternative designs of the API is great too because
> it
> allows people to comment on the API design as they use it.

There are too many possibilities; that's why design change is usually
driven by new usage (user input) or discovering internal
inconsistencies
(developer input).
Personally, I'm also open to a complete rewrite of some functionality,
but those who propose it must be ready to perform a _committer_ work
(namely, be around in order to maintain what they have asked to be
included in CM).


Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Bernd Eckenfels
Hello,

"but those who propose it must be ready to perform a _committer_ work"

I wonder if this is correct, this is after all (a somewhat annoyingly broad) discussion list. If somebody suggest a new API/Structure and backs it up even with some working proof of concept code (which better explains the concept and explains some points people questioned) then this is a good and huge contribution even if it fails the policy requirements at first. And it is possible that other (non comitters) can improve it from there. No proofs or unit tests are mandatory at this (discussion) state.

But of course nobody can expect such draft work to be committed - but it might find a champion who is convinced by its idea and partial existing work.

In fact it is much better to have a API proposal which can be adopted to further proposals/clarifications without throwing away documentation/test fluff.

And on a unrelated topic - it is not a problem that there is no open SVN repo at this stage. Neigther a policy controlled hosted repo nor SVN are good for the gradual,
distributed brainstorming.

BTW: why is a Optimizer/Algebra System/Math Library a commons project anyway?

Greetings
Bernd

PS: nudge nudge, some feedback the questions I raised in the VFS threads would be great ;)

Am 21.08.2013 um 23:47 schrieb Gilles<[hidden email]>:

> On Wed, 21 Aug 2013 09:42:09 -0700, Ajo Fod wrote:
>> Good for you...
>>
>> Yes just imagine if I'd to get every fix through committers. I'd never get
>> anything done here.
>
> Not every fix; commit to start with one.
> I've spent a _lot_ of time detailing what you could do to go forward
> with the issues which you submitted. And you simply ignored it all,
> plainly saying that I'm free to do the work myself.
>
>>> On the subject of this thread: I did not imply that an "experimental"
>>> package would allow sloppy or undocumented code or bypass unit testing.
>>> All (the above) things being equal, the purpose would be to compare
>>> alternative designs.
>>>
>>
>> Perhaps I was not clear. Once again I repeat: I agree with the need for
>> comments clean code and unit tests demonstrate the incremental utility of
>> the contribution in the "experimental" package.
>
> And you have been very clear that you expect other people to do the work.
>
>> I merely disagree that all contributors have the knowledge or the
>> incentives to test "Everything (ideally)", reuse other Commons components,
>> comment on "Everything", and in the case of CM analytically prove that the
>> underlying math is sound, analyze when the code might fail, compare it with
>> all other known methods, etc. So, if "half-baked" code (that solves a known
>> problem) exists in the experimental packages, people who really need it to
>> be reliably tested can patch in the tests and promote the code to
>> "fully-baked" status.
>
> I think that there exist projects out there that collect any code that
> purports to solve some problem.
>
>> I hope you'll agree that as it stands, this makes CM capable of only
>> solving a subset the mathematical problems of what it can solve with a more
>> open policy.
>
> I think that you are wrong. Even as we try to abide by rules, cruft
> and bugs accumulate; loosening the policy will just make it worse.
>
> Phil explained the policy for Apache Commons projects. Personally, I've
> also my reservations about some ill-defined aspects of the policy. But
> I'm certainly not backing a proposal that amounts to unbounded maintenance
> work for the committers.
>
>> The argument for alternative designs of the API is great too because it
>> allows people to comment on the API design as they use it.
>
> There are too many possibilities; that's why design change is usually
> driven by new usage (user input) or discovering internal inconsistencies
> (developer input).
> Personally, I'm also open to a complete rewrite of some functionality,
> but those who propose it must be ready to perform a _committer_ work
> (namely, be around in order to maintain what they have asked to be
> included in CM).
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Gilles Sadowski
On Thu, 22 Aug 2013 00:07:51 +0200, Bernd Eckenfels wrote:
> Hello,
>
> "but those who propose it must be ready to perform a _committer_
> work"
>
> I wonder if this is correct, this is after all (a somewhat annoyingly
> broad) discussion list.

You seem to answer that below ("nobody can expect such draft work to
be committed").
That's what I mean: To be committed, it must meet our self-inflicted
quality requirements.
Even when it does, we are sometimes surprised how bugs can go unnoticed
for a long time.

> If somebody suggest a new API/Structure and
> backs it up even with some working proof of concept code (which
> better
> explains the concept and explains some points people questioned) then
> this is a good and huge contribution even if it fails the policy
> requirements at first. And it is possible that other (non comitters)
> can improve it from there. No proofs or unit tests are mandatory at
> this (discussion) state.
>
> But of course nobody can expect such draft work to be committed - but
> it might find a champion who is convinced by its idea and partial
> existing work.

Could you spot one example where this happened?
Up to now, either a regular committer picked a feature request and
implemented it all by himself, or a committer helped a non-committer
achieve the required quality.

> In fact it is much better to have a API proposal which can be adopted
> to further proposals/clarifications without throwing away
> documentation/test fluff.

The "problem" is that it is not going to be committed until it meets
the
requirements. And some people don't seem to get that simple fact.

> And on a unrelated topic - it is not a problem that there is no open
> SVN repo at this stage. Neigther a policy controlled hosted repo nor
> SVN are good for the gradual,
> distributed brainstorming.

I think that we can boost the collaboration by having a more "open"
sandbox: a committed non-committer (!) can _show_ that it works; a
skeptic committer can use his usual tool (i.e. maven here) to check
that it works.

> BTW: why is a Optimizer/Algebra System/Math Library a commons project
> anyway?

What do you mean?


Regards,
Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

James Ring
Seems to me that a more distributed change control system like git would
allow would-be contributors to put their code up for scrutiny without
having to create sandbox projects and the like.

If enough people get behind some patches, they could iterate faster and get
it checked into the mainline faster...

What do you think?
On Aug 21, 2013 4:14 PM, "Gilles" <[hidden email]> wrote:

> On Thu, 22 Aug 2013 00:07:51 +0200, Bernd Eckenfels wrote:
>
>> Hello,
>>
>> "but those who propose it must be ready to perform a _committer_ work"
>>
>> I wonder if this is correct, this is after all (a somewhat annoyingly
>> broad) discussion list.
>>
>
> You seem to answer that below ("nobody can expect such draft work to
> be committed").
> That's what I mean: To be committed, it must meet our self-inflicted
> quality requirements.
> Even when it does, we are sometimes surprised how bugs can go unnoticed
> for a long time.
>
>  If somebody suggest a new API/Structure and
>> backs it up even with some working proof of concept code (which better
>> explains the concept and explains some points people questioned) then
>> this is a good and huge contribution even if it fails the policy
>> requirements at first. And it is possible that other (non comitters)
>> can improve it from there. No proofs or unit tests are mandatory at
>> this (discussion) state.
>>
>> But of course nobody can expect such draft work to be committed - but
>> it might find a champion who is convinced by its idea and partial
>> existing work.
>>
>
> Could you spot one example where this happened?
> Up to now, either a regular committer picked a feature request and
> implemented it all by himself, or a committer helped a non-committer
> achieve the required quality.
>
>  In fact it is much better to have a API proposal which can be adopted
>> to further proposals/clarifications without throwing away
>> documentation/test fluff.
>>
>
> The "problem" is that it is not going to be committed until it meets the
> requirements. And some people don't seem to get that simple fact.
>
>  And on a unrelated topic - it is not a problem that there is no open
>> SVN repo at this stage. Neigther a policy controlled hosted repo nor
>> SVN are good for the gradual,
>> distributed brainstorming.
>>
>
> I think that we can boost the collaboration by having a more "open"
> sandbox: a committed non-committer (!) can _show_ that it works; a
> skeptic committer can use his usual tool (i.e. maven here) to check
> that it works.
>
>  BTW: why is a Optimizer/Algebra System/Math Library a commons project
>> anyway?
>>
>
> What do you mean?
>
>
> Regards,
> Gilles
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

sebb-2-2
On 22 August 2013 05:27, James Ring <[hidden email]> wrote:
> Seems to me that a more distributed change control system like git would
> allow would-be contributors to put their code up for scrutiny without
> having to create sandbox projects and the like.
>
> If enough people get behind some patches, they could iterate faster and get
> it checked into the mainline faster...
>
> What do you think?

I think that''s a lot to expect existing developers to learn another
SCM just for this.
And I'm not sure GIT is supported for website publication.

However, all the components are available as read-only git mirrors, so
3rd parties can create patches there.

> On Aug 21, 2013 4:14 PM, "Gilles" <[hidden email]> wrote:
>
>> On Thu, 22 Aug 2013 00:07:51 +0200, Bernd Eckenfels wrote:
>>
>>> Hello,
>>>
>>> "but those who propose it must be ready to perform a _committer_ work"
>>>
>>> I wonder if this is correct, this is after all (a somewhat annoyingly
>>> broad) discussion list.
>>>
>>
>> You seem to answer that below ("nobody can expect such draft work to
>> be committed").
>> That's what I mean: To be committed, it must meet our self-inflicted
>> quality requirements.
>> Even when it does, we are sometimes surprised how bugs can go unnoticed
>> for a long time.
>>
>>  If somebody suggest a new API/Structure and
>>> backs it up even with some working proof of concept code (which better
>>> explains the concept and explains some points people questioned) then
>>> this is a good and huge contribution even if it fails the policy
>>> requirements at first. And it is possible that other (non comitters)
>>> can improve it from there. No proofs or unit tests are mandatory at
>>> this (discussion) state.
>>>
>>> But of course nobody can expect such draft work to be committed - but
>>> it might find a champion who is convinced by its idea and partial
>>> existing work.
>>>
>>
>> Could you spot one example where this happened?
>> Up to now, either a regular committer picked a feature request and
>> implemented it all by himself, or a committer helped a non-committer
>> achieve the required quality.
>>
>>  In fact it is much better to have a API proposal which can be adopted
>>> to further proposals/clarifications without throwing away
>>> documentation/test fluff.
>>>
>>
>> The "problem" is that it is not going to be committed until it meets the
>> requirements. And some people don't seem to get that simple fact.
>>
>>  And on a unrelated topic - it is not a problem that there is no open
>>> SVN repo at this stage. Neigther a policy controlled hosted repo nor
>>> SVN are good for the gradual,
>>> distributed brainstorming.
>>>
>>
>> I think that we can boost the collaboration by having a more "open"
>> sandbox: a committed non-committer (!) can _show_ that it works; a
>> skeptic committer can use his usual tool (i.e. maven here) to check
>> that it works.
>>
>>  BTW: why is a Optimizer/Algebra System/Math Library a commons project
>>> anyway?
>>>
>>
>> What do you mean?
>>
>>
>> Regards,
>> Gilles
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>

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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Evan Ward
In reply to this post by Ted Dunning
I agree with James that this is a problem that git has already solved.
For the changes I'm working on I have already cloned from the git
mirror and plan to upload the patch as a fork + pull request on github.
I think the "branchyness" of distributed version control makes it easy
to have several experimental branches without needing a central
repository for them.

Evan




On Wed 21 Aug 2013 01:01:22 PM EDT, Ted Dunning wrote:

> +1
>
> Sent from my iPhone
>
> On Aug 21, 2013, at 9:42, Ajo Fod <[hidden email]> wrote:
>
>>
>> I hope you'll agree that as it stands, this makes CM capable of only
>> solving a subset the mathematical problems of what it can solve with a more
>> open policy.
>>
>> The argument for alternative designs of the API is great too because it
>> allows people to comment on the API design as they use it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Luc Maisonobe
In reply to this post by James Ring
Le 22/08/2013 06:27, James Ring a écrit :
> Seems to me that a more distributed change control system like git would
> allow would-be contributors to put their code up for scrutiny without
> having to create sandbox projects and the like.

You can already do it this way if you want. Look at
http://git.apache.org/, you will find the repository for Apache Commons
Math along a lot of other repositories. Then you just clone it as you
would clone any repositories and provide a link to your own repository.
If I remember well, Evan just did that a few days ago.

Luc

>
> If enough people get behind some patches, they could iterate faster and get
> it checked into the mainline faster...
>
> What do you think?
> On Aug 21, 2013 4:14 PM, "Gilles" <[hidden email]> wrote:
>
>> On Thu, 22 Aug 2013 00:07:51 +0200, Bernd Eckenfels wrote:
>>
>>> Hello,
>>>
>>> "but those who propose it must be ready to perform a _committer_ work"
>>>
>>> I wonder if this is correct, this is after all (a somewhat annoyingly
>>> broad) discussion list.
>>>
>>
>> You seem to answer that below ("nobody can expect such draft work to
>> be committed").
>> That's what I mean: To be committed, it must meet our self-inflicted
>> quality requirements.
>> Even when it does, we are sometimes surprised how bugs can go unnoticed
>> for a long time.
>>
>>  If somebody suggest a new API/Structure and
>>> backs it up even with some working proof of concept code (which better
>>> explains the concept and explains some points people questioned) then
>>> this is a good and huge contribution even if it fails the policy
>>> requirements at first. And it is possible that other (non comitters)
>>> can improve it from there. No proofs or unit tests are mandatory at
>>> this (discussion) state.
>>>
>>> But of course nobody can expect such draft work to be committed - but
>>> it might find a champion who is convinced by its idea and partial
>>> existing work.
>>>
>>
>> Could you spot one example where this happened?
>> Up to now, either a regular committer picked a feature request and
>> implemented it all by himself, or a committer helped a non-committer
>> achieve the required quality.
>>
>>  In fact it is much better to have a API proposal which can be adopted
>>> to further proposals/clarifications without throwing away
>>> documentation/test fluff.
>>>
>>
>> The "problem" is that it is not going to be committed until it meets the
>> requirements. And some people don't seem to get that simple fact.
>>
>>  And on a unrelated topic - it is not a problem that there is no open
>>> SVN repo at this stage. Neigther a policy controlled hosted repo nor
>>> SVN are good for the gradual,
>>> distributed brainstorming.
>>>
>>
>> I think that we can boost the collaboration by having a more "open"
>> sandbox: a committed non-committer (!) can _show_ that it works; a
>> skeptic committer can use his usual tool (i.e. maven here) to check
>> that it works.
>>
>>  BTW: why is a Optimizer/Algebra System/Math Library a commons project
>>> anyway?
>>>
>>
>> What do you mean?
>>
>>
>> Regards,
>> Gilles
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Ted Dunning
On Thu, Aug 22, 2013 at 11:52 AM, Luc Maisonobe <[hidden email]>wrote:

> Then you just clone it as you
> would clone any repositories and provide a link to your own repository.
> If I remember well, Evan just did that a few days ago.
>

And you can do with it as you will.

Build a prototype without tests to make a point.

Or fork the code into a proprietary product.

Or whatever you like.
Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Phil Steitz
In reply to this post by Bernd Eckenfels
On 8/21/13 3:07 PM, Bernd Eckenfels wrote:

> Hello,
>
> "but those who propose it must be ready to perform a _committer_ work"
>
> I wonder if this is correct, this is after all (a somewhat annoyingly broad) discussion list. If somebody suggest a new API/Structure and backs it up even with some working proof of concept code (which better explains the concept and explains some points people questioned) then this is a good and huge contribution even if it fails the policy requirements at first. And it is possible that other (non comitters) can improve it from there. No proofs or unit tests are mandatory at this (discussion) state.
>
> But of course nobody can expect such draft work to be committed - but it might find a champion who is convinced by its idea and partial existing work.
>
> In fact it is much better to have a API proposal which can be adopted to further proposals/clarifications without throwing away documentation/test fluff.
>
> And on a unrelated topic - it is not a problem that there is no open SVN repo at this stage. Neigther a policy controlled hosted repo nor SVN are good for the gradual,
> distributed brainstorming.
>
> BTW: why is a Optimizer/Algebra System/Math Library a commons project anyway?

You can still see the original proposal linked on the [math] project
page [1].  The basic rationale for the component has not really
changed over the 10 years that we have been working on it here.  We
have talked a few times about "graduating" but the great help and
feedback that we get from members of the commons community has
always outweighed the advantages of going TLP.  Of course, we live
in fear that after too many threads like this, we will eventually
get kicked out ;)

Phil

[1] http://commons.apache.org/proper/commons-math/proposal.html


>
> Greetings
> Bernd
>
> PS: nudge nudge, some feedback the questions I raised in the VFS threads would be great ;)
>
> Am 21.08.2013 um 23:47 schrieb Gilles<[hidden email]>:
>
>> On Wed, 21 Aug 2013 09:42:09 -0700, Ajo Fod wrote:
>>> Good for you...
>>>
>>> Yes just imagine if I'd to get every fix through committers. I'd never get
>>> anything done here.
>> Not every fix; commit to start with one.
>> I've spent a _lot_ of time detailing what you could do to go forward
>> with the issues which you submitted. And you simply ignored it all,
>> plainly saying that I'm free to do the work myself.
>>
>>>> On the subject of this thread: I did not imply that an "experimental"
>>>> package would allow sloppy or undocumented code or bypass unit testing.
>>>> All (the above) things being equal, the purpose would be to compare
>>>> alternative designs.
>>>>
>>> Perhaps I was not clear. Once again I repeat: I agree with the need for
>>> comments clean code and unit tests demonstrate the incremental utility of
>>> the contribution in the "experimental" package.
>> And you have been very clear that you expect other people to do the work.
>>
>>> I merely disagree that all contributors have the knowledge or the
>>> incentives to test "Everything (ideally)", reuse other Commons components,
>>> comment on "Everything", and in the case of CM analytically prove that the
>>> underlying math is sound, analyze when the code might fail, compare it with
>>> all other known methods, etc. So, if "half-baked" code (that solves a known
>>> problem) exists in the experimental packages, people who really need it to
>>> be reliably tested can patch in the tests and promote the code to
>>> "fully-baked" status.
>> I think that there exist projects out there that collect any code that
>> purports to solve some problem.
>>
>>> I hope you'll agree that as it stands, this makes CM capable of only
>>> solving a subset the mathematical problems of what it can solve with a more
>>> open policy.
>> I think that you are wrong. Even as we try to abide by rules, cruft
>> and bugs accumulate; loosening the policy will just make it worse.
>>
>> Phil explained the policy for Apache Commons projects. Personally, I've
>> also my reservations about some ill-defined aspects of the policy. But
>> I'm certainly not backing a proposal that amounts to unbounded maintenance
>> work for the committers.
>>
>>> The argument for alternative designs of the API is great too because it
>>> allows people to comment on the API design as they use it.
>> There are too many possibilities; that's why design change is usually
>> driven by new usage (user input) or discovering internal inconsistencies
>> (developer input).
>> Personally, I'm also open to a complete rewrite of some functionality,
>> but those who propose it must be ready to perform a _committer_ work
>> (namely, be around in order to maintain what they have asked to be
>> included in CM).
>>
>>
>> Gilles
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: Need for an alternatives to the main line of code.

Phil Steitz
In reply to this post by Ajo Fod
On 8/20/13 12:07 PM, Ajo Fod wrote:

> My 2c worth. It seems like there is a general bottleneck. A lot of ideas
> don't get used because there is a hurdle that people have to make change
> that satisfy all code requirements like tests/reuse of blocks etc. This
> makes for a larger than necessary hurdle for people to contribute.
>
> Looks like Gilles tried to solve this problem. One alternative is to place
> alternative/new code in a nursery/experimental package parallel to the main
> line of code. This nursery code wouldn't be subject to the deprecation step
> or stability guarantees. The nursery packages should be better than the
> main line of code or solve an unsolved problem demonstrated with
> appropriate tests.
>
> That way, users will be aware of and can beInefit from the ability to solve
> a problem in CM. This will also be "advertisement" for the needed work to
> include the work in the main line of code.

I think we have agreed that either svn branches or git forks can
address the "scratch space" issue.

I have a comment on the general collaboration approach, though,
which is just my HO.  There are lots of different collaboration
styles in OSS projects.  One thing that is common to pretty much all
of them though is that if your goal is to "get your patches in" you
are actually much better off focusing first on learning how the
community works and becoming a "net energy producer" within the
community.  Just tossing patches in and asking why they are not
committed is net energy drain.  Doing simple stuff like following
the coding guidelines, taking time to understand the existing code,
searching the archives for previous discussion, doing background
research that helps the community get on the same page, you
establish yourself as a *net source of energy.*  That makes others
more willing and interested in working with you.  Then your patches
get committed and you eventually get to commit them yourself :)

I know we have made some bad design decisions.  I know we will make
more.  We honestly vacillate between just focusing on getting
algorithms soundly implemented and good API design.  Pretty much all
of our bad API decisions have been the result of us wanting to just
get useful stuff implemented while trying to keep the API minimally
stable.   I know we are sometimes grouchy and argumentative and we
have some really diverse views among the committers here.  We need
to work on the grouchiness, but the diversity is a strength.  We
honestly welcome better ideas; but I agree with Gilles that vague,
generally negative commentary has zero value to us.  Constructive
criticism, good questions and patches are always welcome.  We
especially appreciate feedback based on practical applications (e.g.
Ward's use cases) and advice/comments from those with expertise
related to the algorithms that we are implementing.

Phil

>
> Cheers,
> -Ajo
>


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