commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: Need for an alternatives to the main line of code.
Date Thu, 22 Aug 2013 18:52:08 GMT
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" <gilles@harfang.homelinux.org> 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<dev-unsubscribe@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message