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" <gil...@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-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
