or the other way around: if GCM/APNs changes.... and a new release comes out... the "UnifiedPush" would increase the number, not really good reflecting the state of SimplePush.

IMO a separate JIRA allows just more fine-tuning, on the different components (especially two servers).

On Wed, Jul 3, 2013 at 5:41 PM, Kris Borchers <kris@redhat.com> wrote:

Hmmm, why wouldn't this work just be captured in AGJS and keep the UP SP related work in AGPUSH … not sure if another JIRA project is necessary.

On Jul 3, 2013, at 8:49 AM, Daniel Bevenius <daniel.bevenius@gmail.com> wrote:

+1

On 3 July 2013 15:39, Lucas Holmquist <lholmqui@redhat.com> wrote:

#agreed

On Jul 3, 2013, at 9:38 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:

+1

On Wed, Jul 3, 2013 at 3:37 PM, Matthias Wessendorf <matzew@apache.org> wrote:

Hi,

I think it does make sense to track all the items for SimplePush (server and client) in a separated JIRA. That way we could have a more straightforward process of individual release, tracking at the right source etc.

The integration between UP and SP would be still tracked at AGPUSH, but that's really just one or two java classes :-)

Motivation:
I think that UP and SP are pretty different. Regarding SP, I think it does make sense to capture that in a different instance:

* SimplePush works standalone or in combination with WildFly/vert.x
--> different targets, different dependencies, different "envirnoments"
* SimplePush is based on a spec (Moz-specific spec).

--> The server (and the client) should reflect that with different cycles/releases, to be more fine grain.
* Independency
--> A release of a new version of SimplePush (based on a Netty bug, for instance), should not be treated in a "Push release", while the UnifiedPush server has no code changes at all. (vice versa)

For the name: AGSIMPLEPUSH

The AGPUSH will stay to "catch" all the UnifiedPush items.

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev