deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: Sandbox for DeltaSpike
Date Thu, 28 Jun 2012 16:54:00 GMT
Maybe we should do a new thread for the security stuff so we don't derail
this one.

Having talked to some of the Seam Contributors here at JBoss World / Red
Hat Summit it seems like a lot of them aren't quite sure how to get the
discussions started for their previous Seam modules, especially since many
of them target EE apis (I'm ccing the Seam dev list so hopefully those who
may not be following DeltaSpike dev will see this). That is a large part of
where this sandbox idea came from. If we want to create a new Apache repo,
or another sub directory in our current repo, or perhaps even different
branches for this work I'm fine. However, I do agree that getting too many
topics going all at once is bad. That happened in Seam and we were
overloaded. Perhaps we should create some sort policy for getting these
ideas in if they're not on the current roadmap. I'm not sure if any of
really know when we'll be tackling some of the EE stuff. Next release,
release after that one? I really don't want to lose these people and see
DeltaSpike stagnate with only a few developers doing it in their spare time.

On Thu, Jun 28, 2012 at 12:35 PM, Mark Struberg <struberg@yahoo.de> wrote:

> Oh yea, that was my fault. I was on a conference earlier that week and
> overlooked his mail. Found it now.
>
>
> Shane, what is the direction you working on? What are the basic ideas and
> what shortcomings did you identify while doing the review?
> I'm not sure if it wouldn't be better we would make that work directly in
> the deltaspike main repo. There are lots of other people looking at the
> repo and we got many questions regarding security already. And not being
> able to point people to a canonical repo which contains the latest stuff...
>
> Btw, welcome Bolek! We've talked on IRC already a few times. Would be
> great if you could introduce yourself with a few words and also if we move
> the technical discussions from IRC more to email. This is much easier to
> follow for people in different timezones. And it will also raise visibility
> and make people aware that there is a new face working on DeltaSpike :)
>
>
>
> There is a general ASF rule "If it isn't on the list, it didn't happen".
>
> Using IRC or even skype calls is fine for _additional_ ad hoc
> communication, but it must not lead to 'silently' doing things without
> having conversation on the list. IRC is just not a mail archive which can
> get scanned easily.
>
>
> txs and LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Jason Porter <lightguard.jp@gmail.com>
> > To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> struberg@yahoo.de>
> > Cc:
> > Sent: Thursday, June 28, 2012 6:20 PM
> > Subject: Re: Sandbox for DeltaSpike
> >
> > On Thu, Jun 28, 2012 at 6:06 AM, Mark Struberg <struberg@yahoo.de>
> 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
> >>
> >>
>



-- 
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message