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