that's a different topic since we should also align it with jsf2.2 (as much as possible). however, in general: agreed - we have to re-visit everything (a reality check is very important) -> if we start too many topics in parallel, the visibility of each topic will be low(er).
regards, gerhard 2012/6/28 Mark Struberg <[email protected]> > 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 > >> >> >>>> > >> >> >>> > >> >> > > >> >> > >> > > >> > > >
