I would not word it that drastically that we 'delete code if there is no discussion upfront'.
The discussion upfront is mainly important to raise visibility and attention. And to be able to get a response from many people about those new ideas. That way we can make good ideas even better and prevent easily overseen shortcomings. No one of us is perfect, but together we kick butt! Btw, the initial discussion is only a 'basic agreement' to kick off attention imo. If we see during implementation that other ways are superior, then there is no problem to amend the initially discussed topics. LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Thursday, June 28, 2012 9:50 AM > Subject: Re: Sandbox for DeltaSpike > > i agree with mark. > > since we are talking about whole modules: > the idea of apache-labs [1] is a bit different but maybe it works for us as > well. > (potential community members can clone it and follow our git > discussion-workflow.) > > in any case: there needs to be a discussion before moving such parts to the > main repository -> that also means: if there is no agreement, we have to > drop it again. > > regards, > gerhard > > [1] http://labs.apache.org > > > > 2012/6/28 Mark Struberg <[email protected]> > >> With 'public' I meant that the main communication tool is the > mailing >> list. There is a saying "if it's not on the list, it didn't > happen". >> >> IRC is fine as backing channel, but there are different time zones etc. >> It's also not logged (because freenode has a policy about not logging >> chats), thus other uses cannot simply search some archive to find any old >> information. >> >> >> It's perfect if you drop a few lines of mail explaining what >> problem/idea/feature you are working on and add a pointer to some github >> repo. >> But be aware that you must work alone on that gibhut repo or at least must >> _not_ accept patches/pull-requests from non-committers. Otherwise you would >> not be IP clean. And since goog vs orcl (Harmony,...) we _really_ care >> about that! >> >> github is also a great tool, but it doesn't really strengthen the team >> collaboration spirit. It's more fore the lone fighter who works on his >> own... >> >> Maybe I should explain it another way what could happen: >> >> >> Imagine you get a cool new feature which has a decent complexity. Say 45 >> classes and 25000 lines of code. And all that in one big merge-commit! >> Compare that with work that evolves over a few weeks with 5 people working >> on it and adding ideas. There would be much more understanding of the topic >> in the community and the quality would also be much better at the end. >> There will also be much less overlapping with other features in the project >> quite naturally... >> >> LieGrue, >> strub >> >> >> ----- Original Message ----- >> > From: Jason Porter <[email protected]> >> > To: "[email protected]" < >> [email protected]> >> > Cc: "[email protected]" < >> [email protected]>; [email protected] >> > Sent: Wednesday, June 27, 2012 8:32 PM >> > Subject: Re: Sandbox for DeltaSpike >> > >> > Why wouldn't this be in the public? The idea is to get people to >> contribute. >> > If we need a separate Apache repo for a sandbox, okay fine but then > we're >> > back to the icla issue aren't we? >> > >> > Sent from my iPhone >> > >> > On Jun 27, 2012, at 14:10, Mark Struberg <[email protected]> > wrote: >> > >> >> Btw, another thingy. >> >> >> >> It is not the best community building approach to develop > something 'in >> > the dark' and then drop all that on all other community members. >> >> Don't get me wrong, it's perfectly fine to experiment > around if >> > ideas are good at all. But doing this 'in public' is much more >> > appreciated. You can get lots or precious feedback that way. >> >> >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >> >> >> ----- Original Message ----- >> >>> From: Mark Struberg <[email protected]> >> >>> To: "[email protected]" >> > <[email protected]> >> >>> Cc: >> >>> Sent: Wednesday, June 27, 2012 7:33 PM >> >>> Subject: Re: Sandbox for DeltaSpike >> >>> >> >>> basically +1 >> >>> >> >>> >> >>> BUT we really have to be careful that we don't do too > much at >> > github! >> >>> >> >>> All commits done on github must either be done by a > deltaspike >> > committer or >> >>> someone who has at least an iCLA on file. >> >>> >> >>> Commits from other people need to get added via an attachment > in a >> Jira >> > ticket. >> >>> I know this sounds not really git-like, but it's the only > way we >> > can ensure >> >>> IP clearance. >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> ----- Original Message ----- >> >>>> From: Mehdi Heidarzadeh <[email protected]> >> >>>> To: [email protected] >> >>>> Cc: >> >>>> Sent: Wednesday, June 27, 2012 7:28 PM >> >>>> Subject: Re: Sandbox for DeltaSpike >> >>>> >> >>>> +1 >> >>>> Great idea. >> >>>> >> >>>> On Wed, Jun 27, 2012 at 4:52 AM, Shane Bryzak >> > <[email protected]> >> >>> wrote: >> >>>> >> >>>>> Fantastic idea, +1. >> >>>>> >> >>>>> >> >>>>> On 27/06/12 05:39, Jason Porter wrote: >> >>>>> >> >>>>>> Hey everyone! >> >>>>>> >> >>>>>> I wanted to bring up the idea of having a > sandbox to add >> > bits and >> >>> other >> >>>>>> non-core extensions. We have a great bunch of > people from >> > the Seam >> >>>>>> development group looking to add their > extensions, but >> > they're >> >>> >> >>>> either not >> >>>>>> on the roadmap for DS, or are very far down. I > suggest we >> > setup a >> >>>> sandbox >> >>>>>> on github people can write to, or at least do > pull >> > requests to so >> >>> we >> >>>> can >> >>>>>> get some of these modules and other ideas in > and pull >> > them into >> >>> core as >> >>>> we >> >>>>>> get there. We can also use this as a vetting > ground for >> > new ideas >> >>> and >> >>>> other >> >>>>>> things which may not exactly fit into core, > like the >> > forge >> >>> extension. >> >>>>>> >> >>>>>> To do this we need to >> >>>>>> >> >>>>>> 1. Setup the repo somewhere >> >>>>>> 2. Seed it with a basic structure (pom.xml, > contribution >> >>> instructions, >> >>>>>> etc) >> >>>>>> 3. Get some CI setup somewhere (we could > leverage >> > OpenShift for >> >>> this if >> >>>>>> needed) >> >>>>>> >> >>>>>> What does everyone else think? I've > cc'd the Seam >> > >> >>> Development >> >>>> list here >> >>>>>> hoping to get some feedback from them as well > and >> > hopefully >> >>> rekindle >> >>>> some >> >>>>>> of the fire we had there. >> >>>>>> >> >>>>>> -- >> >>>>>> Jason Porter >> >>>>>> http://lightguard-jp.blogspot.**com >> >>>> <http://lightguard-jp.blogspot.com> >> >>>>>> http://twitter.com/**lightguardjp >> >>>> <http://twitter.com/lightguardjp> >> >>>>>> >> >>>>>> Software Engineer >> >>>>>> Open Source Advocate >> >>>>>> Author of Seam Catch - Next Generation Java > Exception >> > Handling >> >>>>>> >> >>>>>> PGP key id: 926CCFF5 >> >>>>>> PGP key available at: keyserver.net >> > <http://keyserver.net>, >> >>>> pgp.mit.edu < >> >>>>>> http://pgp.mit.edu> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> > ______________________________**_________________ >> >>>>>> seam-dev mailing list >> >>>>>> [email protected] >> >>>>>> >> >>>> >> >>> >> > https://lists.jboss.org/**mailman/listinfo/seam-dev< >> https://lists.jboss.org/mailman/listinfo/seam-dev> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Mehdi Heidarzadeh Ardalani >> >>>> Independent JEE Consultant, Architect and Developer. >> >>>> http://www.TheBigJavaBlog.com >> >>>> >> >>> >> > >> >
