You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@etch.apache.org by Martijn Dashorst <ma...@gmail.com> on 2012/07/23 14:05:05 UTC

Etch work through JIRA

Hey team,

While I appreciate the occasional JIRA issues that are created, I
think that some of those could actually be discussed more in the open
at dev@. The list is available just for this type of discussion.

Unless the list shows some activity, the project looks like a dead
paperweight. What I expect, taken from the most recently created
issues:

ETCH-240

Refactoring of the current lifecycle implementation and the connection
stack management.


I think this is a great thing to discuss on the dev@ list. I'd expect
something like:

Currently the foo of the connection stack management is a bit odd (or
doesn't work), because when I want to do X it takes step1, step2,
step3, step... , stepN to accomplish such task. While we can work
around it, probably if we change the lifecycle implementation in such
and such a way, we can take out steps stepN-100 through stepN-5.

This opens up the possibilities of discussing the framework and the
future. It gives folks that are currently in lurk mode, but get the 1
quarterly message a chance to discuss it with you. Possibly it could
bring in new committers.

Martijn

AW: Etch work through JIRA

Posted by Michael Fitzner <Mi...@bmw-carit.de>.
Hi all,
Over the last weeks we worked a lot to complete a first version of the binding-cpp (runtime and compiler). While the development some open points were collected and entered to the JIRA system as a reminder. That is also the reason why we created so much Jira issues. As we have a complete binding-cpp stack now, we have the chance to discuss topics like new features and some refactoring issue more at the dev@ lists.

Best
Michael

-----Ursprüngliche Nachricht-----
Von: scott comer [mailto:wert1y@mac.com] 
Gesendet: Montag, 23. Juli 2012 14:36
An: etch-dev@incubator.apache.org
Betreff: Re: Etch work through JIRA

agree. it would be good practice for actually planning and discussing the "next release".

scott out

On 7/23/2012 7:05 AM, Martijn Dashorst wrote:
> Hey team,
>
> While I appreciate the occasional JIRA issues that are created, I 
> think that some of those could actually be discussed more in the open 
> at dev@. The list is available just for this type of discussion.
>
> Unless the list shows some activity, the project looks like a dead 
> paperweight. What I expect, taken from the most recently created
> issues:
>
> ETCH-240
>
> Refactoring of the current lifecycle implementation and the connection 
> stack management.
>
>
> I think this is a great thing to discuss on the dev@ list. I'd expect 
> something like:
>
> Currently the foo of the connection stack management is a bit odd (or 
> doesn't work), because when I want to do X it takes step1, step2, 
> step3, step... , stepN to accomplish such task. While we can work 
> around it, probably if we change the lifecycle implementation in such 
> and such a way, we can take out steps stepN-100 through stepN-5.
>
> This opens up the possibilities of discussing the framework and the 
> future. It gives folks that are currently in lurk mode, but get the 1 
> quarterly message a chance to discuss it with you. Possibly it could 
> bring in new committers.
>
> Martijn


Re: Etch work through JIRA

Posted by scott comer <we...@mac.com>.
agree. it would be good practice for actually planning and discussing 
the "next release".

scott out

On 7/23/2012 7:05 AM, Martijn Dashorst wrote:
> Hey team,
>
> While I appreciate the occasional JIRA issues that are created, I
> think that some of those could actually be discussed more in the open
> at dev@. The list is available just for this type of discussion.
>
> Unless the list shows some activity, the project looks like a dead
> paperweight. What I expect, taken from the most recently created
> issues:
>
> ETCH-240
>
> Refactoring of the current lifecycle implementation and the connection
> stack management.
>
>
> I think this is a great thing to discuss on the dev@ list. I'd expect
> something like:
>
> Currently the foo of the connection stack management is a bit odd (or
> doesn't work), because when I want to do X it takes step1, step2,
> step3, step... , stepN to accomplish such task. While we can work
> around it, probably if we change the lifecycle implementation in such
> and such a way, we can take out steps stepN-100 through stepN-5.
>
> This opens up the possibilities of discussing the framework and the
> future. It gives folks that are currently in lurk mode, but get the 1
> quarterly message a chance to discuss it with you. Possibly it could
> bring in new committers.
>
> Martijn