I know what you mean, but you worded it a bit too drastically :) If a proposed feature is somehow related to CDI and sounds valuable, then we will for sure add it. But only after collecting additional ideas and doing a 'reality check' on the topic ;)
And if it helps I like to make this clear again: we will not even import stuff like the CODI window handling 1:1 without a review. Actually I know quite a few parts which I like to do radically different/easier. LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Thursday, June 28, 2012 10:42 AM > Subject: Re: Sandbox for DeltaSpike > > for sure at least a vote can drop such parts - we did it already. > i just mentioned the possibility because everybody has to be aware of it. > (with an external sandbox it would be even worse.) > > @ rest: > agreed > > regards, > gerhard > > > > 2012/6/28 Mark Struberg <[email protected]> > >> 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 >> >> >>>> >> >> >>> >> >> > >> >> >> > >> >
