Sandbox for DeltaSpike

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Sandbox for DeltaSpike

Jason Porter
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://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
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] Sandbox for DeltaSpike

Lincoln Baxter, III
+1

I think this is a great idea! We certainly want to make sure that we are
supporting innovation of community members, and this would help a great
deal.

~Lincoln

On Tue, Jun 26, 2012 at 3:39 PM, Jason Porter <[hidden email]>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://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
>
> _______________________________________________
> seam-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>


--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Shane Bryzak-2
In reply to this post by Jason Porter
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://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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/seam-dev

Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mehdi Heidarzadeh
+1
Great idea.

On Wed, Jun 27, 2012 at 4:52 AM, Shane Bryzak <[hidden email]> 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
>> [hidden email]
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]> 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
>>>  [hidden email]
>>>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Jason Porter
If they're not official parts of deltaspike but a proving ground and we can
pull things in, or get iCLAs for people when we pull in their stuff, is
that a problem? Or what if we ask them for an iCLA once they do a pull
request?

I'm worried we're losing some momentum (if it's not already gone) from the
community about contributing. We also have a bunch of Seam devs (Cody,
Marius, George, etc.) asking about when they can put their bits into
DeltaSpike because it's not on the roadmap, or it's very far out on the
roadmap.

On Wed, Jun 27, 2012 at 1:33 PM, Mark Struberg <[hidden email]> wrote:

> 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> 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
> >>>  [hidden email]
> >>>
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
In reply to this post by Mark Struberg
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 <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> 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 <[hidden email]>
>>  To: [hidden email]
>>  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 <[hidden email]>
> 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
>>>>   [hidden email]
>>>>
>>
> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Jason Porter
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 <[hidden email]> 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 <[hidden email]>
>> To: "[hidden email]" <[hidden email]>
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>> 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
>>>>>   [hidden email]
>>>>>
>>>
>> 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
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
In reply to this post by Jason Porter
> We also have a bunch of Seam devs (Cody, Marius, George, etc.) asking about when they can put their bits into DeltaSpike


That's perfect, but doing stuff off-list is not increasing the visibility of this work.


Cody, Marius, George are all already DeltaSpike committer!

PLEASE, just put your ideas on the deltaspike-dev mailing list and start a quick introduction about what you like to add!


The momentum is used best if you commit that stuff.
Of course there is a difference in the way the seam3 project and Apache projects are developed. In Apache projects there is no code ownership. Every line gets reviewed and improved 5 times from 10 pairs of eyes. Please be one of those 10++ pairs of eyes and also start reviewing code or add new functionality!

LieGrue,
strub

>________________________________
> From: Jason Porter <[hidden email]>
>To: [hidden email]; Mark Struberg <[hidden email]>
>Cc: Seam Mailing List <[hidden email]>
>Sent: Wednesday, June 27, 2012 7:50 PM
>Subject: Re: Sandbox for DeltaSpike
>
>
>If they're not official parts of deltaspike but a proving ground and we can pull things in, or get iCLAs for people when we pull in their stuff, is that a problem? Or what if we ask them for an iCLA once they do a pull request?
>
>
>I'm worried we're losing some momentum (if it's not already gone) from the community about contributing. We also have a bunch of Seam devs (Cody, Marius, George, etc.) asking about when they can put their bits into DeltaSpike because it's not on the roadmap, or it's very far out on the roadmap. 
>
>
>On Wed, Jun 27, 2012 at 1:33 PM, Mark Struberg <[hidden email]> wrote:
>
>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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]> 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
>>>>>  [hidden email]
>>>>>
>>> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
In reply to this post by Jason Porter
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 <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>; [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
>>>  To: "[hidden email]"
> <[hidden email]>
>>>  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 <[hidden email]>
>>>>  To: [hidden email]
>>>>  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
> <[hidden email]>
>>>  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
>>>>>>   [hidden email]
>>>>>>
>>>>
>>>
> 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
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Gerhard Petracek
Administrator
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 <[hidden email]>

> 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 <[hidden email]>
> > To: "[hidden email]" <
> [hidden email]>
> > Cc: "[hidden email]" <
> [hidden email]>; [hidden email]
> > 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 <[hidden email]> 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 <[hidden email]>
> >>>  To: "[hidden email]"
> > <[hidden email]>
> >>>  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 <[hidden email]>
> >>>>  To: [hidden email]
> >>>>  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
> > <[hidden email]>
> >>>  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
> >>>>>>   [hidden email]
> >>>>>>
> >>>>
> >>>
> > 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
> >>>>
> >>>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>
>>  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 <[hidden email]>
>>  > To: "[hidden email]" <
>>  [hidden email]>
>>  > Cc: "[hidden email]" <
>>  [hidden email]>; [hidden email]
>>  > 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 <[hidden email]>
> 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 <[hidden email]>
>>  >>>  To: "[hidden email]"
>>  > <[hidden email]>
>>  >>>  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 <[hidden email]>
>>  >>>>  To: [hidden email]
>>  >>>>  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
>>  > <[hidden email]>
>>  >>>  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
>>  >>>>>>  [hidden email]
>>  >>>>>>
>>  >>>>
>>  >>>
>>  > 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
>>  >>>>
>>  >>>
>>  >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Gerhard Petracek
Administrator
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 <[hidden email]>

> 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> >
> >>  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 <[hidden email]>
> >>  > To: "[hidden email]" <
> >>  [hidden email]>
> >>  > Cc: "[hidden email]" <
> >>  [hidden email]>; [hidden email]
> >>  > 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 <[hidden email]>
> > 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 <[hidden email]>
> >>  >>>  To: "[hidden email]"
> >>  > <[hidden email]>
> >>  >>>  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 <[hidden email]>
> >>  >>>>  To: [hidden email]
> >>  >>>>  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
> >>  > <[hidden email]>
> >>  >>>  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
> >>  >>>>>>  [hidden email]
> >>  >>>>>>
> >>  >>>>
> >>  >>>
> >>  > 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
> >>  >>>>
> >>  >>>
> >>  >
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>
>>  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 <[hidden email]>
>>  > To: [hidden email]
>>  > 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 <[hidden email]>
>>  >
>>  >>  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 <[hidden email]>
>>  >>  > To: "[hidden email]" <
>>  >>  [hidden email]>
>>  >>  > Cc: "[hidden email]" <
>>  >>  [hidden email]>; [hidden email]
>>  >>  > 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
> <[hidden email]>
>>  > 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 <[hidden email]>
>>  >>  >>>  To: "[hidden email]"
>>  >>  > <[hidden email]>
>>  >>  >>>  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
> <[hidden email]>
>>  >>  >>>>  To: [hidden email]
>>  >>  >>>>  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
>>  >>  > <[hidden email]>
>>  >>  >>>  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
>>  >>  >>>>>>  [hidden email]
>>  >>  >>>>>>
>>  >>  >>>>
>>  >>  >>>
>>  >>  > 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
>>  >>  >>>>
>>  >>  >>>
>>  >>  >
>>  >>
>>  >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Gerhard Petracek
Administrator
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 <[hidden email]>

> 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> >
> >>  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 <[hidden email]>
> >>  > To: [hidden email]
> >>  > 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 <[hidden email]>
> >>  >
> >>  >>  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 <[hidden email]>
> >>  >>  > To: "[hidden email]" <
> >>  >>  [hidden email]>
> >>  >>  > Cc: "[hidden email]" <
> >>  >>  [hidden email]>; [hidden email]
> >>  >>  > 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
> > <[hidden email]>
> >>  > 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 <[hidden email]>
> >>  >>  >>>  To: "[hidden email]"
> >>  >>  > <[hidden email]>
> >>  >>  >>>  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
> > <[hidden email]>
> >>  >>  >>>>  To: [hidden email]
> >>  >>  >>>>  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
> >>  >>  > <[hidden email]>
> >>  >>  >>>  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
> >>  >>  >>>>>>  [hidden email]
> >>  >>  >>>>>>
> >>  >>  >>>>
> >>  >>  >>>
> >>  >>  > 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
> >>  >>  >>>>
> >>  >>  >>>
> >>  >>  >
> >>  >>
> >>  >
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
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?


LieGrue,
strub



----- Original Message -----

> From: Gerhard Petracek <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>
>>  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 <[hidden email]>
>>  > To: [hidden email]
>>  > 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 <[hidden email]>
>>  >
>>  >>  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 <[hidden email]>
>>  >>  > To: [hidden email]
>>  >>  > 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 <[hidden email]>
>>  >>  >
>>  >>  >>  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 <[hidden email]>
>>  >>  >>  > To:
> "[hidden email]" <
>>  >>  >>  [hidden email]>
>>  >>  >>  > Cc:
> "[hidden email]" <
>>  >>  >>  [hidden email]>;
> [hidden email]
>>  >>  >>  > 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
>>  > <[hidden email]>
>>  >>  > 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
> <[hidden email]>
>>  >>  >>  >>>  To:
> "[hidden email]"
>>  >>  >>  > <[hidden email]>
>>  >>  >>  >>>  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
>>  > <[hidden email]>
>>  >>  >>  >>>>  To:
> [hidden email]
>>  >>  >>  >>>>  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
>>  >>  >>  > <[hidden email]>
>>  >>  >>  >>>  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
>>  >>  >>  >>>>>>  [hidden email]
>>  >>  >>  >>>>>>
>>  >>  >>  >>>>
>>  >>  >>  >>>
>>  >>  >>  >
> 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
>>  >>  >>  >>>>
>>  >>  >>  >>>
>>  >>  >>  >
>>  >>  >>
>>  >>  >
>>  >>
>>  >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Jason Porter
On Thu, Jun 28, 2012 at 6:06 AM, Mark Struberg <[hidden email]> 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> >
> >>  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 <[hidden email]>
> >>  > To: [hidden email]
> >>  > 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 <[hidden email]>
> >>  >
> >>  >>  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 <[hidden email]>
> >>  >>  > To: [hidden email]
> >>  >>  > 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 <[hidden email]>
> >>  >>  >
> >>  >>  >>  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 <[hidden email]>
> >>  >>  >>  > To:
> > "[hidden email]" <
> >>  >>  >>  [hidden email]>
> >>  >>  >>  > Cc:
> > "[hidden email]" <
> >>  >>  >>  [hidden email]>;
> > [hidden email]
> >>  >>  >>  > 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
> >>  > <[hidden email]>
> >>  >>  > 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
> > <[hidden email]>
> >>  >>  >>  >>>  To:
> > "[hidden email]"
> >>  >>  >>  > <[hidden email]>
> >>  >>  >>  >>>  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
> >>  > <[hidden email]>
> >>  >>  >>  >>>>  To:
> > [hidden email]
> >>  >>  >>  >>>>  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
> >>  >>  >>  > <[hidden email]>
> >>  >>  >>  >>>  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
> >>  >>  >>  >>>>>>  [hidden email]
> >>  >>  >>  >>>>>>
> >>  >>  >>  >>>>
> >>  >>  >>  >>>
> >>  >>  >>  >
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Mark Struberg
Administrator
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 <[hidden email]>
> To: [hidden email]; Mark Struberg <[hidden email]>
> 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 <[hidden email]> 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
>>
>> 
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Jason Porter
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 <[hidden email]> 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 <[hidden email]>
> > To: [hidden email]; Mark Struberg <
> [hidden email]>
> > 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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox for DeltaSpike

Boleslaw Dawidowicz
In reply to this post by Mark Struberg
Hello,

so late introduction from myself :)

I live in Poland - Warsaw area - and work remotely from there. On the professional side since quite a few years focused on JEE portals. Currently I'm the GateIn Portal Project Lead [0] and Platform Architect of corresponding RedHat product offering [1]. Previously I was also working on PicketLink IDM component [3] which we use internally in portal but is more in maintenance mode currently.

I'm interested mainly in the security and identity part as we are seriously looking forward to build on top of DeltaSpike in the future in those domains. There is also my colleague from portal team here - Marek Posolda who already participated in some discussions on this list and cooperated with me and Shane to build the security use cases [3]. He is also interested in contributing in this area and should be able to invest his time to help with implementation. But maybe I'll let him speak for himself :)

To be honest i'm quite new to how things work in Apache projects and eager to learn how the cooperation should flow between us. I was actually about to start looking at providing simple JPA implementation of IDM IdentityStore [4] so it is a valid question for me where such work should happen. As at the moment it is still only part of prototyping work that Shane is doing and not officially pushed to DS repo.

If I'm not mistaken there are at least 4 different threads related to security that were started on this list while ago but died without resolution. I understand and agree that things should be discussed piece by piece to avoid unnecessary noise and keep things in order. However maybe for such huge domain it is better to first have basic agreement in direction (which I believe already happen) and then cook some initial consistent proposal to discuss at once - which is what Shane is doing now. Security part is so broad and also probably not so fancy to everyone around that it is both hard to decouple separate non related parts to discuss in vacuum and have such fragmented discussion flowing without bigger parts of prototype code to get feedback about. Still like I mentioned before I'm quite used to very different way of cooperation in open source projects so I'm eager to hear from most experienced guys here how things should proceed.
 
Bolek

[0] https://www.jboss.org/gatein
[1] http://www.redhat.com/products/jbossenterprisemiddleware/portal/
[2] http://www.jboss.org/picketlink/IDM.html
[3] https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts
[4] https://github.com/sbryzak/DeltaSpike/blob/security/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/spi/idm/IdentityStore.java


On Jun 28, 2012, at 6:35 PM, Mark Struberg 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 <[hidden email]>
>> To: [hidden email]; Mark Struberg <[hidden email]>
>> 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 <[hidden email]> 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
>>>
>>>  

12