On Thu, Jun 28, 2012 at 6:06 AM, Mark Struberg <[email protected]> wrote:
> But if we don't talk about that stuff at all, then there will be no > visibility and no progress neither. > > There is really no problem with spreading out parallel topics, IF there > are people interested in contributing. > > > What I do _not_ like to have is starting with 15 different topics and not > finishing anything! > > Btw, what is the state of deltaspike-security? > > I have no clue about it nor did I do any review. I've also not seen any > commit lately. > > Who is working on that? Or is noone working on it at all? https://github.com/sbryzak/DeltaSpike/tree/security I believe Shane has been working on it apparently, but there hasn't been much discussion. > LieGrue, > strub > > > > ----- Original Message ----- > > From: Gerhard Petracek <[email protected]> > > To: [email protected] > > Cc: > > Sent: Thursday, June 28, 2012 11:24 AM > > Subject: Re: Sandbox for DeltaSpike > > > >t hat'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 > >> >> >> >>>> > >> >> >> >>> > >> >> >> > > >> >> >> > >> >> > > >> >> > >> > > >> > > > -- Jason Porter http://lightguard-jp.blogspot.com 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, pgp.mit.edu
