commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Need for an alternatives to the main line of code.
Date Thu, 22 Aug 2013 08:42:58 GMT
On 22 August 2013 05:27, James Ring <> 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" <> 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.**<>
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message