You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@etch.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2010/09/02 03:04:01 UTC
Future of Etch
Guys,
we think that the non-activity of Etch is really "permanent" and will
propose to the Incubator to make the project "Retired".
As it is Reporting Month for Etch in September, I am suggesting that
we send this message instead of fabricating a "weak" report.
If you have any serious objections, now is the time to speak.
As for the codebase; Anyone is free to take it and do what ever they
want, within the limits of the Apache license, the SVN history will
remain, but made read-only. If I new community is to emerge, they can
request Etch to come out of retirement (not common).
This is in no way reflecting negative on the individuals involved in
Etch, as we are well aware of the challenges to bootstrap communities.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: [VOTE] Contents of Release 1.1
Posted by James Dixson <di...@gmail.com>.
* Holger Grandy <Ho...@bmw-carit.de> [2010-09-14 17:36:39 +0200]:
> Hi Scott,
>
> I don't see any reason not to include smaller fixes for bugs which we know today already. We also have some issues with the
> c binding resolved internally in the last weeks and will merge them to the ASF svn.
>
> Which unit tests failed for you?
>
> Regarding external dependencies: We had the same issue with the c binding. It relies on apr, apr-iconv, apr-util and cunit.
> I personally don't like the idea of checking them in because it bloats trunk. The native libs have to be supplied in flavors
> for all OSes which we target, too. In my opinion an environment variable (e.g. "ETCH_EXTERNAL_DEPENDS") which is used in
> build scripts would be best. We did it similarly with the c binding and the main ant build uses "TOOLS_DIR" (which is perhaps
> a little bit too generic).
I like the ETCH_EXTERNAL_DEPENDS idea too :-). The only thing that might
be more convenient would be an autoconf wrapper around the process to
allow dependencies to be specified as args to a configure script. But
autoconf is non-trivial to setup and requires a lot of testing.
>
> Some other frameworks provide third party download packages on their websites...
>
I agree providing links would be helpful.
> I don't think that there is a summary of dependents for the build listed on the website yet. Do you want to add your list
> there?
>
> Holger
>
> -----Original Message-----
> From: scott comer [mailto:wert1y@mac.com]
> Sent: Dienstag, 14. September 2010 16:16
> To: etch-dev@incubator.apache.org
> Cc: Martijn Dashorst
> Subject: Re: [VOTE] Contents of Release 1.1
>
> in our use of etch here at spawn i've run across a couple of bugs.
> lazy me has not posted
> them yet, though the setSockOpt bug has been mentioned. should our 1.1
> include any
> bug fixes, and if so, which ones?
>
> i'll post bugs for what i found a little later today. the setSockOpt fix
> is pretty easy, but might
> need some discussion.
>
> when i tried to build at home on win7 the unit tests failed.
>
> i have condensed the dependents necessary for build, and we had
> discussed checking them
> into a deps or libs directory. should i do that?
>
> scott out
>
> On 9/14/2010 8:40 AM, Martijn Dashorst wrote:
> > +1
> >
> > I don't think a vote was necessary, nor is there any procedure to be
> > followed, however it never hurts to ask to include something, or to
> > poll consensus on an issue. That said, if someone is willing to be a
> > release master, then they get all the leeway they need. If the release
> > master thinks that the C bindings should go with the release, then so
> > be it. If there's objection to doing so in 1.1, why not skip 1.1 and
> > go directly to release 1.2?
> >
> > The ASF fosters meritocratic communities where merit is earned by doing.
> >
> > Martijn
> >
> > On Tue, Sep 14, 2010 at 11:57 AM, Holger Grandy
> > <Ho...@bmw-carit.de> wrote:
> >> Hi guys,
> >>
> >> since Scott is mentioning voting procedures, I would like to pick up that point and start
> >> a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
> >>
> >> I propose that we publish Release 1.1 with the C binding implementation included
> >> in the next weeks (as stated in the mail below).
> >>
> >> Please vote:
> >> -1 : no, release 1.1 should not contain the C binding, because ...
> >> 0 : I don't care
> >> +1 : Release 1.1 should be published with the C binding as described below
> >>
> >> ----
> >> +1 from me
> >>
> >> Regards,
> >> Holger
> >>
> >>
> >> -----Original Message-----
> >> From: scott comer [mailto:wert1y@mac.com]
> >> Sent: Montag, 13. September 2010 15:27
> >> To: etch-dev@incubator.apache.org
> >> Subject: Re: Future of Etch
> >>
> >> well, much as martijn might wish otherwise, there are procedures for
> >> voting such a plan.
> >>
> >> i don't like two things:
> >>
> >> 1) please don't remove the tag.
> >>
> >> 2) why not proceed with the release 1.1 as is, and release 1.2 with c
> >> binding from trunk. less confusion.
> >>
> >> scott out
> >>
> >> On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
> >>> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
> >>> <Ho...@bmw-carit.de> wrote:
> >>>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
> >>>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
> >>>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
> >>>> branch from trunk for 1.1
> >>> This sounds like a good plan. Go for it.
> >>>
> >>> Martijn
> >>
> >
> >
>
Re: [VOTE] Contents of Release 1.1
Posted by James Dixson <di...@gmail.com>.
+1
I am fine with the next release including the c-binding.
--
james
* Martijn Dashorst <ma...@gmail.com> [2010-09-14 15:40:49 +0200]:
> +1
>
> I don't think a vote was necessary, nor is there any procedure to be
> followed, however it never hurts to ask to include something, or to
> poll consensus on an issue. That said, if someone is willing to be a
> release master, then they get all the leeway they need. If the release
> master thinks that the C bindings should go with the release, then so
> be it. If there's objection to doing so in 1.1, why not skip 1.1 and
> go directly to release 1.2?
>
> The ASF fosters meritocratic communities where merit is earned by doing.
>
> Martijn
>
> On Tue, Sep 14, 2010 at 11:57 AM, Holger Grandy
> <Ho...@bmw-carit.de> wrote:
> > Hi guys,
> >
> > since Scott is mentioning voting procedures, I would like to pick up that point and start
> > a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
> >
> > I propose that we publish Release 1.1 with the C binding implementation included
> > in the next weeks (as stated in the mail below).
> >
> > Please vote:
> > -1 : no, release 1.1 should not contain the C binding, because ...
> > 0 : I don't care
> > +1 : Release 1.1 should be published with the C binding as described below
> >
> > ----
> > +1 from me
> >
> > Regards,
> > Holger
> >
> >
> > -----Original Message-----
> > From: scott comer [mailto:wert1y@mac.com]
> > Sent: Montag, 13. September 2010 15:27
> > To: etch-dev@incubator.apache.org
> > Subject: Re: Future of Etch
> >
> > well, much as martijn might wish otherwise, there are procedures for
> > voting such a plan.
> >
> > i don't like two things:
> >
> > 1) please don't remove the tag.
> >
> > 2) why not proceed with the release 1.1 as is, and release 1.2 with c
> > binding from trunk. less confusion.
> >
> > scott out
> >
> > On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
> >> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
> >> <Ho...@bmw-carit.de> wrote:
> >>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
> >>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
> >>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
> >>> branch from trunk for 1.1
> >> This sounds like a good plan. Go for it.
> >>
> >> Martijn
> >
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.4 increases type safety for web applications
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
AW: [VOTE] Contents of Release 1.1
Posted by Michael Fitzner <Mi...@bmw-carit.de>.
Hallo,
I would like to give +1 too, let us try to get the release 1.1 of Etch in place with the mentioned feature set.
Thanks,
Michael
-----Ursprüngliche Nachricht-----
Von: Holger Grandy [mailto:Holger.Grandy@bmw-carit.de]
Gesendet: Dienstag, 14. September 2010 11:58
An: etch-dev@incubator.apache.org
Betreff: [VOTE] Contents of Release 1.1
Hi guys,
since Scott is mentioning voting procedures, I would like to pick up that point and start
a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
I propose that we publish Release 1.1 with the C binding implementation included
in the next weeks (as stated in the mail below).
Please vote:
-1 : no, release 1.1 should not contain the C binding, because ...
0 : I don't care
+1 : Release 1.1 should be published with the C binding as described below
----
+1 from me
Regards,
Holger
-----Original Message-----
From: scott comer [mailto:wert1y@mac.com]
Sent: Montag, 13. September 2010 15:27
To: etch-dev@incubator.apache.org
Subject: Re: Future of Etch
well, much as martijn might wish otherwise, there are procedures for
voting such a plan.
i don't like two things:
1) please don't remove the tag.
2) why not proceed with the release 1.1 as is, and release 1.2 with c
binding from trunk. less confusion.
scott out
On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
> <Ho...@bmw-carit.de> wrote:
>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>> branch from trunk for 1.1
> This sounds like a good plan. Go for it.
>
> Martijn
Re: [VOTE] Contents of Release 1.1
Posted by scott comer <we...@mac.com>.
at cisco we actually maintained a tools tree in the repository
parallel to etch. i like it in the etch tree
myself, but would be willing to go the other route. i like it in the
same checkout because:
1) everything you need to build / use etch is in the single checkout,
2) easier to keep in sync with source.
this last is important as newer versions of tools are integrated (and
enable / require source changes). an
example being an updated dependent library is needed to enable new
functionality. so if someone checks
out the code it won't build until they also update the tools.
somewhat analogous to updating dependent version numbers in poms. they
ride along with the source and the right
thing always happens.
the downside is bigger / longer checkout. how much of a problem is that?
it could get out of hand with non-java
code (windows and linux versions, and other platforms not yet supported).
scott out
On 9/14/2010 10:36 AM, Holger Grandy wrote:
> Hi Scott,
>
> I don't see any reason not to include smaller fixes for bugs which we know today already. We also have some issues with the
> c binding resolved internally in the last weeks and will merge them to the ASF svn.
>
> Which unit tests failed for you?
>
> Regarding external dependencies: We had the same issue with the c binding. It relies on apr, apr-iconv, apr-util and cunit.
> I personally don't like the idea of checking them in because it bloats trunk. The native libs have to be supplied in flavors
> for all OSes which we target, too. In my opinion an environment variable (e.g. "ETCH_EXTERNAL_DEPENDS") which is used in
> build scripts would be best. We did it similarly with the c binding and the main ant build uses "TOOLS_DIR" (which is perhaps
> a little bit too generic).
>
> Some other frameworks provide third party download packages on their websites...
>
> I don't think that there is a summary of dependents for the build listed on the website yet. Do you want to add your list
> there?
>
> Holger
>
> -----Original Message-----
> From: scott comer [mailto:wert1y@mac.com]
> Sent: Dienstag, 14. September 2010 16:16
> To: etch-dev@incubator.apache.org
> Cc: Martijn Dashorst
> Subject: Re: [VOTE] Contents of Release 1.1
>
> in our use of etch here at spawn i've run across a couple of bugs.
> lazy me has not posted
> them yet, though the setSockOpt bug has been mentioned. should our 1.1
> include any
> bug fixes, and if so, which ones?
>
> i'll post bugs for what i found a little later today. the setSockOpt fix
> is pretty easy, but might
> need some discussion.
>
> when i tried to build at home on win7 the unit tests failed.
>
> i have condensed the dependents necessary for build, and we had
> discussed checking them
> into a deps or libs directory. should i do that?
>
> scott out
>
> On 9/14/2010 8:40 AM, Martijn Dashorst wrote:
>> +1
>>
>> I don't think a vote was necessary, nor is there any procedure to be
>> followed, however it never hurts to ask to include something, or to
>> poll consensus on an issue. That said, if someone is willing to be a
>> release master, then they get all the leeway they need. If the release
>> master thinks that the C bindings should go with the release, then so
>> be it. If there's objection to doing so in 1.1, why not skip 1.1 and
>> go directly to release 1.2?
>>
>> The ASF fosters meritocratic communities where merit is earned by doing.
>>
>> Martijn
>>
>> On Tue, Sep 14, 2010 at 11:57 AM, Holger Grandy
>> <Ho...@bmw-carit.de> wrote:
>>> Hi guys,
>>>
>>> since Scott is mentioning voting procedures, I would like to pick up that point and start
>>> a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
>>>
>>> I propose that we publish Release 1.1 with the C binding implementation included
>>> in the next weeks (as stated in the mail below).
>>>
>>> Please vote:
>>> -1 : no, release 1.1 should not contain the C binding, because ...
>>> 0 : I don't care
>>> +1 : Release 1.1 should be published with the C binding as described below
>>>
>>> ----
>>> +1 from me
>>>
>>> Regards,
>>> Holger
>>>
>>>
>>> -----Original Message-----
>>> From: scott comer [mailto:wert1y@mac.com]
>>> Sent: Montag, 13. September 2010 15:27
>>> To: etch-dev@incubator.apache.org
>>> Subject: Re: Future of Etch
>>>
>>> well, much as martijn might wish otherwise, there are procedures for
>>> voting such a plan.
>>>
>>> i don't like two things:
>>>
>>> 1) please don't remove the tag.
>>>
>>> 2) why not proceed with the release 1.1 as is, and release 1.2 with c
>>> binding from trunk. less confusion.
>>>
>>> scott out
>>>
>>> On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
>>>> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
>>>> <Ho...@bmw-carit.de> wrote:
>>>>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>>>>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>>>>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>>>>> branch from trunk for 1.1
>>>> This sounds like a good plan. Go for it.
>>>>
>>>> Martijn
>>
RE: [VOTE] Contents of Release 1.1
Posted by Holger Grandy <Ho...@bmw-carit.de>.
Hi Scott,
I don't see any reason not to include smaller fixes for bugs which we know today already. We also have some issues with the
c binding resolved internally in the last weeks and will merge them to the ASF svn.
Which unit tests failed for you?
Regarding external dependencies: We had the same issue with the c binding. It relies on apr, apr-iconv, apr-util and cunit.
I personally don't like the idea of checking them in because it bloats trunk. The native libs have to be supplied in flavors
for all OSes which we target, too. In my opinion an environment variable (e.g. "ETCH_EXTERNAL_DEPENDS") which is used in
build scripts would be best. We did it similarly with the c binding and the main ant build uses "TOOLS_DIR" (which is perhaps
a little bit too generic).
Some other frameworks provide third party download packages on their websites...
I don't think that there is a summary of dependents for the build listed on the website yet. Do you want to add your list
there?
Holger
-----Original Message-----
From: scott comer [mailto:wert1y@mac.com]
Sent: Dienstag, 14. September 2010 16:16
To: etch-dev@incubator.apache.org
Cc: Martijn Dashorst
Subject: Re: [VOTE] Contents of Release 1.1
in our use of etch here at spawn i've run across a couple of bugs.
lazy me has not posted
them yet, though the setSockOpt bug has been mentioned. should our 1.1
include any
bug fixes, and if so, which ones?
i'll post bugs for what i found a little later today. the setSockOpt fix
is pretty easy, but might
need some discussion.
when i tried to build at home on win7 the unit tests failed.
i have condensed the dependents necessary for build, and we had
discussed checking them
into a deps or libs directory. should i do that?
scott out
On 9/14/2010 8:40 AM, Martijn Dashorst wrote:
> +1
>
> I don't think a vote was necessary, nor is there any procedure to be
> followed, however it never hurts to ask to include something, or to
> poll consensus on an issue. That said, if someone is willing to be a
> release master, then they get all the leeway they need. If the release
> master thinks that the C bindings should go with the release, then so
> be it. If there's objection to doing so in 1.1, why not skip 1.1 and
> go directly to release 1.2?
>
> The ASF fosters meritocratic communities where merit is earned by doing.
>
> Martijn
>
> On Tue, Sep 14, 2010 at 11:57 AM, Holger Grandy
> <Ho...@bmw-carit.de> wrote:
>> Hi guys,
>>
>> since Scott is mentioning voting procedures, I would like to pick up that point and start
>> a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
>>
>> I propose that we publish Release 1.1 with the C binding implementation included
>> in the next weeks (as stated in the mail below).
>>
>> Please vote:
>> -1 : no, release 1.1 should not contain the C binding, because ...
>> 0 : I don't care
>> +1 : Release 1.1 should be published with the C binding as described below
>>
>> ----
>> +1 from me
>>
>> Regards,
>> Holger
>>
>>
>> -----Original Message-----
>> From: scott comer [mailto:wert1y@mac.com]
>> Sent: Montag, 13. September 2010 15:27
>> To: etch-dev@incubator.apache.org
>> Subject: Re: Future of Etch
>>
>> well, much as martijn might wish otherwise, there are procedures for
>> voting such a plan.
>>
>> i don't like two things:
>>
>> 1) please don't remove the tag.
>>
>> 2) why not proceed with the release 1.1 as is, and release 1.2 with c
>> binding from trunk. less confusion.
>>
>> scott out
>>
>> On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
>>> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
>>> <Ho...@bmw-carit.de> wrote:
>>>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>>>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>>>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>>>> branch from trunk for 1.1
>>> This sounds like a good plan. Go for it.
>>>
>>> Martijn
>>
>
>
RE: [VOTE] Contents of Release 1.1
Posted by Holger Grandy <Ho...@bmw-carit.de>.
Hi,
the setSocketOpt in the c# binding bug should be fixed now (did what was suggested in
https://issues.apache.org/jira/browse/ETCH-80), unit tests passed on my machine (win7).
We are currently merging the c binding to trunk.
Holger
-----Original Message-----
From: scott comer [mailto:wert1y@mac.com]
Sent: Dienstag, 14. September 2010 16:16
To: etch-dev@incubator.apache.org
Cc: Martijn Dashorst
Subject: Re: [VOTE] Contents of Release 1.1
in our use of etch here at spawn i've run across a couple of bugs.
lazy me has not posted
them yet, though the setSockOpt bug has been mentioned. should our 1.1
include any
bug fixes, and if so, which ones?
i'll post bugs for what i found a little later today. the setSockOpt fix
is pretty easy, but might
need some discussion.
when i tried to build at home on win7 the unit tests failed.
i have condensed the dependents necessary for build, and we had
discussed checking them
into a deps or libs directory. should i do that?
scott out
On 9/14/2010 8:40 AM, Martijn Dashorst wrote:
> +1
>
> I don't think a vote was necessary, nor is there any procedure to be
> followed, however it never hurts to ask to include something, or to
> poll consensus on an issue. That said, if someone is willing to be a
> release master, then they get all the leeway they need. If the release
> master thinks that the C bindings should go with the release, then so
> be it. If there's objection to doing so in 1.1, why not skip 1.1 and
> go directly to release 1.2?
>
> The ASF fosters meritocratic communities where merit is earned by doing.
>
> Martijn
>
> On Tue, Sep 14, 2010 at 11:57 AM, Holger Grandy
> <Ho...@bmw-carit.de> wrote:
>> Hi guys,
>>
>> since Scott is mentioning voting procedures, I would like to pick up that point and start
>> a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
>>
>> I propose that we publish Release 1.1 with the C binding implementation included
>> in the next weeks (as stated in the mail below).
>>
>> Please vote:
>> -1 : no, release 1.1 should not contain the C binding, because ...
>> 0 : I don't care
>> +1 : Release 1.1 should be published with the C binding as described below
>>
>> ----
>> +1 from me
>>
>> Regards,
>> Holger
>>
>>
>> -----Original Message-----
>> From: scott comer [mailto:wert1y@mac.com]
>> Sent: Montag, 13. September 2010 15:27
>> To: etch-dev@incubator.apache.org
>> Subject: Re: Future of Etch
>>
>> well, much as martijn might wish otherwise, there are procedures for
>> voting such a plan.
>>
>> i don't like two things:
>>
>> 1) please don't remove the tag.
>>
>> 2) why not proceed with the release 1.1 as is, and release 1.2 with c
>> binding from trunk. less confusion.
>>
>> scott out
>>
>> On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
>>> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
>>> <Ho...@bmw-carit.de> wrote:
>>>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>>>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>>>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>>>> branch from trunk for 1.1
>>> This sounds like a good plan. Go for it.
>>>
>>> Martijn
>>
>
>
Re: [VOTE] Contents of Release 1.1
Posted by scott comer <we...@mac.com>.
in our use of etch here at spawn i've run across a couple of bugs.
lazy me has not posted
them yet, though the setSockOpt bug has been mentioned. should our 1.1
include any
bug fixes, and if so, which ones?
i'll post bugs for what i found a little later today. the setSockOpt fix
is pretty easy, but might
need some discussion.
when i tried to build at home on win7 the unit tests failed.
i have condensed the dependents necessary for build, and we had
discussed checking them
into a deps or libs directory. should i do that?
scott out
On 9/14/2010 8:40 AM, Martijn Dashorst wrote:
> +1
>
> I don't think a vote was necessary, nor is there any procedure to be
> followed, however it never hurts to ask to include something, or to
> poll consensus on an issue. That said, if someone is willing to be a
> release master, then they get all the leeway they need. If the release
> master thinks that the C bindings should go with the release, then so
> be it. If there's objection to doing so in 1.1, why not skip 1.1 and
> go directly to release 1.2?
>
> The ASF fosters meritocratic communities where merit is earned by doing.
>
> Martijn
>
> On Tue, Sep 14, 2010 at 11:57 AM, Holger Grandy
> <Ho...@bmw-carit.de> wrote:
>> Hi guys,
>>
>> since Scott is mentioning voting procedures, I would like to pick up that point and start
>> a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
>>
>> I propose that we publish Release 1.1 with the C binding implementation included
>> in the next weeks (as stated in the mail below).
>>
>> Please vote:
>> -1 : no, release 1.1 should not contain the C binding, because ...
>> 0 : I don't care
>> +1 : Release 1.1 should be published with the C binding as described below
>>
>> ----
>> +1 from me
>>
>> Regards,
>> Holger
>>
>>
>> -----Original Message-----
>> From: scott comer [mailto:wert1y@mac.com]
>> Sent: Montag, 13. September 2010 15:27
>> To: etch-dev@incubator.apache.org
>> Subject: Re: Future of Etch
>>
>> well, much as martijn might wish otherwise, there are procedures for
>> voting such a plan.
>>
>> i don't like two things:
>>
>> 1) please don't remove the tag.
>>
>> 2) why not proceed with the release 1.1 as is, and release 1.2 with c
>> binding from trunk. less confusion.
>>
>> scott out
>>
>> On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
>>> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
>>> <Ho...@bmw-carit.de> wrote:
>>>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>>>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>>>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>>>> branch from trunk for 1.1
>>> This sounds like a good plan. Go for it.
>>>
>>> Martijn
>>
>
>
Re: [VOTE] Contents of Release 1.1
Posted by Martijn Dashorst <ma...@gmail.com>.
+1
I don't think a vote was necessary, nor is there any procedure to be
followed, however it never hurts to ask to include something, or to
poll consensus on an issue. That said, if someone is willing to be a
release master, then they get all the leeway they need. If the release
master thinks that the C bindings should go with the release, then so
be it. If there's objection to doing so in 1.1, why not skip 1.1 and
go directly to release 1.2?
The ASF fosters meritocratic communities where merit is earned by doing.
Martijn
On Tue, Sep 14, 2010 at 11:57 AM, Holger Grandy
<Ho...@bmw-carit.de> wrote:
> Hi guys,
>
> since Scott is mentioning voting procedures, I would like to pick up that point and start
> a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
>
> I propose that we publish Release 1.1 with the C binding implementation included
> in the next weeks (as stated in the mail below).
>
> Please vote:
> -1 : no, release 1.1 should not contain the C binding, because ...
> 0 : I don't care
> +1 : Release 1.1 should be published with the C binding as described below
>
> ----
> +1 from me
>
> Regards,
> Holger
>
>
> -----Original Message-----
> From: scott comer [mailto:wert1y@mac.com]
> Sent: Montag, 13. September 2010 15:27
> To: etch-dev@incubator.apache.org
> Subject: Re: Future of Etch
>
> well, much as martijn might wish otherwise, there are procedures for
> voting such a plan.
>
> i don't like two things:
>
> 1) please don't remove the tag.
>
> 2) why not proceed with the release 1.1 as is, and release 1.2 with c
> binding from trunk. less confusion.
>
> scott out
>
> On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
>> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
>> <Ho...@bmw-carit.de> wrote:
>>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>>> branch from trunk for 1.1
>> This sounds like a good plan. Go for it.
>>
>> Martijn
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
[VOTE] Contents of Release 1.1
Posted by Holger Grandy <Ho...@bmw-carit.de>.
Hi guys,
since Scott is mentioning voting procedures, I would like to pick up that point and start
a vote regarding a upcoming release 1.1 of Etch. Vote will run for 72 hours until Friday.
I propose that we publish Release 1.1 with the C binding implementation included
in the next weeks (as stated in the mail below).
Please vote:
-1 : no, release 1.1 should not contain the C binding, because ...
0 : I don't care
+1 : Release 1.1 should be published with the C binding as described below
----
+1 from me
Regards,
Holger
-----Original Message-----
From: scott comer [mailto:wert1y@mac.com]
Sent: Montag, 13. September 2010 15:27
To: etch-dev@incubator.apache.org
Subject: Re: Future of Etch
well, much as martijn might wish otherwise, there are procedures for
voting such a plan.
i don't like two things:
1) please don't remove the tag.
2) why not proceed with the release 1.1 as is, and release 1.2 with c
binding from trunk. less confusion.
scott out
On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
> <Ho...@bmw-carit.de> wrote:
>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>> branch from trunk for 1.1
> This sounds like a good plan. Go for it.
>
> Martijn
Re: Future of Etch
Posted by scott comer <we...@mac.com>.
well, much as martijn might wish otherwise, there are procedures for
voting such a plan.
i don't like two things:
1) please don't remove the tag.
2) why not proceed with the release 1.1 as is, and release 1.2 with c
binding from trunk. less confusion.
scott out
On 9/13/2010 2:36 AM, Martijn Dashorst wrote:
> On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
> <Ho...@bmw-carit.de> wrote:
>> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
>> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
>> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
>> branch from trunk for 1.1
> This sounds like a good plan. Go for it.
>
> Martijn
Re: Future of Etch
Posted by Martijn Dashorst <ma...@gmail.com>.
On Fri, Sep 10, 2010 at 4:14 PM, Holger Grandy
<Ho...@bmw-carit.de> wrote:
> We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
> package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
> Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
> branch from trunk for 1.1
This sounds like a good plan. Go for it.
Martijn
Re: Future of Etch
Posted by Holger Grandy <gr...@apache.org>.
Thanks Doug!
I created the issue here:
https://issues.apache.org/jira/browse/INFRA-2986
According to the discussion below this issue
https://issues.apache.org/jira/browse/INFRA-2867
I think our request will need +1's from our Mentors.
I would be happy if someone of you could do that.
Thanks,
Holger
On Tue, Sep 14, 2010 at 7:00 PM, Doug Cutting <cu...@apache.org> wrote:
> On 09/10/2010 07:14 AM, Holger Grandy wrote:
>>
>> A Hudson user would be best for me (grandyho) and Michael (fitzner).
>
> Turns out you need to be a Hudson admin to add Hudson users, and I am not a
> Hudson admin. Please file an INFRA Jira request with Component=Hudson
> requesting accounts.
>
> https://issues.apache.org/jira/browse/INFRA
>
> Doug
>
Re: Future of Etch
Posted by Doug Cutting <cu...@apache.org>.
On 09/10/2010 07:14 AM, Holger Grandy wrote:
> A Hudson user would be best for me (grandyho) and Michael (fitzner).
Turns out you need to be a Hudson admin to add Hudson users, and I am
not a Hudson admin. Please file an INFRA Jira request with
Component=Hudson requesting accounts.
https://issues.apache.org/jira/browse/INFRA
Doug
RE: Future of Etch
Posted by Holger Grandy <Ho...@bmw-carit.de>.
Hi Doug,
thanks a lot.
Jira works fine, we will make a few issues now and continue with the other points next week.
A Hudson user would be best for me (grandyho) and Michael (fitzner). We will setup a build
using the current ant based build. After that we will probably need machine access for setting
up the C binding builds (ubuntu / windows). I suggest we first start with the general build and
I will contact you again when we start with the C builds. Ok?
Whats missing is the Confluence Account. Should we contact infrastructure@.. or create an issue
in Jira? Or is it possible for any of you to change rights of our current limited confluence
accounts?
We have seen an older mail regarding release 1.1. from April. I propose we start over to prepare a release
package in September and initiate a PMC vote regarding that when its ready. Will create Jiras for that.
Proposal: remove the old release 1.1 branch, merge etch-c into trunk, fix bugs, create new release
branch from trunk for 1.1
Regards,
Holger & Michael
-----Original Message-----
From: Doug Cutting [mailto:cutting@apache.org]
Sent: Mittwoch, 8. September 2010 18:48
To: etch-dev@incubator.apache.org
Subject: Re: Future of Etch
On 09/08/2010 08:01 AM, Holger Grandy wrote:
> - someone (James?) please provide Jira Admin rights for michael
> (user id: fitzner) and holger (user id: grandyho)
> so that we are able to clean up the Jira tasks
Done.
> - please provide some information regarding the workflow to officially releases
> in the ASF. We have seen that the last etch release was packaged to the
> private website "public_html" of Apache.org webspace of James Dixson. Guess that is not how it is
> intended to be. I would like to see releases here:
> - http://www.apache.org/dist/incubator/ or
> - http://projects.apache.org/indexes/releases.html
> Can we follow the process described at
> http://incubator.apache.org/guides/releasemanagement.html#release-distribution ?
Yes.
> - set up Etch builds for windows and linux on hudson build server.
> Following http://wiki.apache.org/general/Hudson it should be possible
> to get access to the build servers for our project. I think our mentors
> are the right persons to answer this question. Perfect would be a hudson user
> account for administration of the builds at https://hudson.apache.org/hudson/ and
> shell accounts for the Ubuntu (minerva.apache.org or vesta.apache.org)
> and the Windows (hudson-win.apache.org) nodes to run the builds.
> How does remote access for Windows work in this case? is remote desktop supported?
I can add a Hudson account for someone. Who should I add?
http://wiki.apache.org/general/Hudson
> - please provide an overview about infrastructure roles inside the
> etch project, so that everyone knows how is the right person to ask
> for certain jobs (e.g. svn rights, mailing list administration, ...)
Any mentor should be able to update svn rights. Once the project
graduates, its chair is given this ability.
Mailing-lists are administered by moderators. Would you and Michael
like to be moderators for Etch's lists? You can submit a request to
moderate through the INFRA Jira, an email to infrastructure@, or
sometimes just by asking nicely on the #asfinfra IRC channel.
Doug
Re: Future of Etch
Posted by Doug Cutting <cu...@apache.org>.
On 09/08/2010 08:01 AM, Holger Grandy wrote:
> - someone (James?) please provide Jira Admin rights for michael
> (user id: fitzner) and holger (user id: grandyho)
> so that we are able to clean up the Jira tasks
Done.
> - please provide some information regarding the workflow to officially releases
> in the ASF. We have seen that the last etch release was packaged to the
> private website "public_html" of Apache.org webspace of James Dixson. Guess that is not how it is
> intended to be. I would like to see releases here:
> - http://www.apache.org/dist/incubator/ or
> - http://projects.apache.org/indexes/releases.html
> Can we follow the process described at
> http://incubator.apache.org/guides/releasemanagement.html#release-distribution ?
Yes.
> - set up Etch builds for windows and linux on hudson build server.
> Following http://wiki.apache.org/general/Hudson it should be possible
> to get access to the build servers for our project. I think our mentors
> are the right persons to answer this question. Perfect would be a hudson user
> account for administration of the builds at https://hudson.apache.org/hudson/ and
> shell accounts for the Ubuntu (minerva.apache.org or vesta.apache.org)
> and the Windows (hudson-win.apache.org) nodes to run the builds.
> How does remote access for Windows work in this case? is remote desktop supported?
I can add a Hudson account for someone. Who should I add?
http://wiki.apache.org/general/Hudson
> - please provide an overview about infrastructure roles inside the
> etch project, so that everyone knows how is the right person to ask
> for certain jobs (e.g. svn rights, mailing list administration, ...)
Any mentor should be able to update svn rights. Once the project
graduates, its chair is given this ability.
Mailing-lists are administered by moderators. Would you and Michael
like to be moderators for Etch's lists? You can submit a request to
moderate through the INFRA Jira, an email to infrastructure@, or
sometimes just by asking nicely on the #asfinfra IRC channel.
Doug
Re: Future of Etch
Posted by James Dixson <di...@gmail.com>.
* Holger Grandy <Ho...@bmw-carit.de> [2010-09-08 17:01:36 +0200]:
> - please provide some information regarding the workflow to officially releases
> in the ASF. We have seen that the last etch release was packaged to the
> private website "public_html" of Apache.org webspace of James Dixson. Guess that is not how it is
> intended to be. I would like to see releases here:
> - http://www.apache.org/dist/incubator/ or
> - http://projects.apache.org/indexes/releases.html
> Can we follow the process described at
> http://incubator.apache.org/guides/releasemanagement.html#release-distribution ?
I think the dist-process as described in the link would be fine. I do
not think that process existed (or it was still very immature) at the
time we did the 1.0 release. I personally have never been very happy
about the public_html approach and I was only copying what other
projects were doing at the time.
..As a side comment: there are very few guidelines about this kind of
thing. I have found every project does it differently based on what
works for them.
> - please provide an overview about infrastructure roles inside the
> etch project, so that everyone knows how is the right person to ask
> for certain jobs (e.g. svn rights, mailing list administration, ...)
>
As has been mentioned, Mentors need to be asked for many
permission-oriented things until the project graduates.
RE: Future of Etch
Posted by Holger Grandy <Ho...@bmw-carit.de>.
Hello,
ok, after Martijn's mail things are quite clear for us. Let's realize alternative "one"
and start over (our mentors votes for that assumed) with the following things:
- publish Release 1.1 in September
- Release 1.1 should contain Java, C# and C bindings
- Release 1.1 will use the build process and structure similar to release 1.0.2,
the new feature will be the C binding and current fixes from trunk from last year.
- current trunk + etch-c branch will be merged, trunk will be the basis for
the next release
- release process will be: merge everything into trunk, if trunk is stable, make a release
branch, provide release using this branch, merge potential fixes back to trunk, iterate
- lets think about integrating and/or using the Eclipse Etch Editor support at
http://github.com/grandyho/Etchclipse
- maybe extend this to call the etch compiler directly from eclipse?
- James (or anyone else with admin rights), please
provide Confluence (CWIKI) rights to edit all pages for
Michael (user id: fitzner) and Holger (user id: grandyho) to
- start over with updating the website
- provide more initial "getting started" documentation
- provide a brief specification of the wire format
- someone (James?) please provide Jira Admin rights for michael
(user id: fitzner) and holger (user id: grandyho)
so that we are able to clean up the Jira tasks
- continue pushing the wireshark plugin code at bugs.wireshark.org
- please provide some information regarding the workflow to officially releases
in the ASF. We have seen that the last etch release was packaged to the
private website "public_html" of Apache.org webspace of James Dixson. Guess that is not how it is
intended to be. I would like to see releases here:
- http://www.apache.org/dist/incubator/ or
- http://projects.apache.org/indexes/releases.html
Can we follow the process described at
http://incubator.apache.org/guides/releasemanagement.html#release-distribution ?
- set up Etch builds for windows and linux on hudson build server.
Following http://wiki.apache.org/general/Hudson it should be possible
to get access to the build servers for our project. I think our mentors
are the right persons to answer this question. Perfect would be a hudson user
account for administration of the builds at https://hudson.apache.org/hudson/ and
shell accounts for the Ubuntu (minerva.apache.org or vesta.apache.org)
and the Windows (hudson-win.apache.org) nodes to run the builds.
How does remote access for Windows work in this case? is remote desktop supported?
- c binding specific tasks (we will turn those into jiras):
- provide a cmake based build environment
- integrate all the stuff to a official release package
- please provide an overview about infrastructure roles inside the
etch project, so that everyone knows how is the right person to ask
for certain jobs (e.g. svn rights, mailing list administration, ...)
We will start to work on those tasks in the near future, given that you support that,
and we ask everyone on this list to participate.
Looking forward to your answers,
Regards,
Holger & Michael
-----Original Message-----
From: Martijn Dashorst [mailto:martijn.dashorst@gmail.com]
Sent: Montag, 6. September 2010 21:26
To: etch-dev@incubator.apache.org
Subject: Re: Future of Etch
Hi Holger,
Thanks for your thoughtful response. The problem is not the technology
aspect but the community aspect. When etch joined the incubator the
project was an in-house cisco project with cisco paid developers.
Since then cisco dismantled the team and the members have gone to
greener pastures. What could have been a great (albeit small)
community was killed with that action: there were no non-cisco
developers working on the technology at that time. In my opinion, had
the project consisted of a diverse team, we would have been in better
shape.
When we asked you and Michael to join the etch team, we were hoping to
see discussions, commits, jira tickets filed, etc. The stuff that
makes a community alive and thrive.
>From a mentoring perspective, it is very hard to do anything when
nothing is happening. No commits means no code being contributed, no
code being contributed means no releases, and no discussions.
Attracting new committers is difficult, but if you only sit back and
do nothing, why would anybody join? How would anybody find out about
etch? An article from 2008? If you look at an open source project and
you see one commit in a year, 5 messages to all lists, would you
conclude that the project is healthy and thriving and a sound choice?
That said, if more folks are willing to make this *community* work,
I'm willing to re-evaluate the viability of etch in six months. But
we're going to need to see activity: releases, commits, discussions,
etc. All those things are necessary to create a healthy project ready
to graduate. However, sustained silence will inevitably result in an
end to the incubation effort.
As far as I'm concerned there are 2 options on the table:
- continue incubation and re-evaluate after 6 months and strive to
become a viable community
- stop incubation, and take the code elsewhere (github, google code,
or just in-house development)
It is up to the etch community and determine its future.
Martijn
On Mon, Sep 6, 2010 at 6:13 PM, Holger Grandy
<Ho...@bmw-carit.de> wrote:
> Hello Etch-*,
>
> regarding the current discussion: Etch is a viable technology.
> BMW uses Etch in products, and Etch has proven itself useful in productive
> environments. If you buy a Mini in the future, Etch will drive around with
> you. We are still using it, and - as I have already written in the past - we
> see good reasons for doing so. Etch provides a good communication model and
> a good architecture for efficient binary two-way RPC.
>
> As a benefit for the community, we have committed our C binding implementation
> with lots of code recently. Since this is company driven development, committing
> to the ASF was not a continous process. We worked on it for around half a year
> continously. If we would have used the ASF SVN repository during development, this
> "non-activity" discussion would not have happened now :) This would change in
> the future as we now are ASF committers.
>
> We have an interest in Etch being publicly available, under the hood of the
> Apache foundation. We want to see it in a continous development path.
> We do not want to see it retired. This project has its weaknesses,
> without a doubt, but remember in this discussion, there are people using Etch
> and there are people developing for Etch, and its not only us.
>
> Regards,
> Holger & Michael
>
>
> -----Original Message-----
> From: Manoj Ganesan [mailto:manoj.ganesan@gmail.com]
> Sent: Freitag, 3. September 2010 16:33
> To: etch-dev@incubator.apache.org
> Subject: Re: Future of Etch
>
> Niclas,
>
> Being the mentor, you would remember the professional transition all the
> original Etch developers went through around a year back. That obviously
> hits the brakes on how fast the technology is adopted, and some time is
> warranted for the project to grow with the creators getting their
> professional lives back on track.
>
> The technology isn't something you can try out, and exclaim success in a few
> days. To see if Etch is a custom-fit for users, it is only reasonable to
> expect that it'll take some time and experimentation. Especially, with some
> similar technologies in existence for longer.
>
> It's not that the project is in oblivion. Holger and folks have been working
> extensively on the C binding and have been reporting success with the
> system. There are other questions/comments, albeit not too frequent,
> including one informing us of their success with using Etch (first version
> of NetKernel Protocol). The creators of the project use it at their
> workplace. I have been investigating Etch being the possible IPC protocol
> for our future architecture at my work.
>
> So there are people who are obviously using it. Why 'retire' it then?
> Doesn't the term itself discourage people from trying the technology out.
> Wouldn't it be better to retire it when it's deemed of being obsolete, or
> that it's giving Apache a bad name, or that no one is really using it?
> Neither of these seem true today.
>
> What do you think?
>
> Thanks,
> Manoj
>
>
> On Fri, Sep 3, 2010 at 1:20 AM, Youngjin Park (youngjpa) <youngjpa@cisco.com
>> wrote:
>
>> I feel pain. I had full of interesting in Etch and I still have it. But, it
>> was very difficult to allocate my extra time to do this in a new team where
>> Apache Etch was not born and especially in a team having so many upcoming
>> projects in front of me. It was obviously interesting project, but it was
>> beyond my control in recent days in a new team and in a new place. Sorry
>> about hearing this.
>>
>> Youngjin
>>
>> -----Original Message-----
>> From: James Dixson [mailto:dixson3@gmail.com]
>> Sent: Wednesday, September 01, 2010 10:31 PM
>> To: etch-dev@incubator.apache.org
>> Subject: Re: Future of Etch
>>
>> If Apache does not like the rate of progress, then that is Apache's
>> prerogative. I do not like it, I do not want it to happen, but I
>> personally have no energy or interest in jumping through any other hoops
>> to try and prevent it.
>>
>> I find it unfortunate that if the project is forcibly retired that it
>> will require any other contributions to the project to be made somewhere
>> else.
>>
>> Looking back over the last 2yrs I have found this whole incubation
>> experience to be a bit too *fussy*. Everything from the long drawn-out
>> discomfort about the "Etch" name to the continual pressure to wrangle
>> new committers, to this latest (and just a little bit patronizing) label
>> of "retirement". It is disappointing because such a label *is*
>> stigmatizing to the technology in a way that is completely not the
>> technology's "fault".
>>
>> I do not blame any of the mentors, past or present. I blame ourselves
>> for thinking that Apache adoption of Etch would be a good thing for both
>> Etch and Apache. Instead the experience has been more like moving into a
>> gated community with an over-aggressive home-owners association who
>> wants us evicted because we are not mowing our grass twice a week.
>>
>> I am sure you have heard this kind of criticism before (I certainly have
>> read things like this in the incubator forum). I feel I understand a lot
>> better what Apache affiliation is and will certainly think twice before
>> considering this again in the future. "Success" as Apache
>> defines it just seems more correlated with the extroverted tendencies of
>> the committers rather than the merits of technology.
>>
>> Finally, despite it all of my belly-aching I do appreciate all of the
>> time and energy the mentors have provided. If I have offended, I do not
>> intend to, I only intend to express my frustration and disappointment
>> with the process.
>>
>> The situation is what it is.
>>
>> --
>> james
>>
>> * Niclas Hedhman <ni...@hedhman.org> [2010-09-02 09:04:01 +0800]:
>>
>> > Guys,
>> > we think that the non-activity of Etch is really "permanent" and will
>> > propose to the Incubator to make the project "Retired".
>> >
>> > As it is Reporting Month for Etch in September, I am suggesting that
>> > we send this message instead of fabricating a "weak" report.
>> >
>> > If you have any serious objections, now is the time to speak.
>> >
>> > As for the codebase; Anyone is free to take it and do what ever they
>> > want, within the limits of the Apache license, the SVN history will
>> > remain, but made read-only. If I new community is to emerge, they can
>> > request Etch to come out of retirement (not common).
>> >
>> > This is in no way reflecting negative on the individuals involved in
>> > Etch, as we are well aware of the challenges to bootstrap communities.
>> >
>> > Cheers
>> > --
>> > Niclas Hedhman, Software Developer
>> > http://www.qi4j.org - New Energy for Java
>> >
>> > I live here; http://tinyurl.com/2qq9er
>> > I work here; http://tinyurl.com/2ymelc
>> > I relax here; http://tinyurl.com/2cgsug
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: Future of Etch
Posted by Florian Weimer <fw...@bfk.de>.
* Martijn Dashorst:
> From a mentoring perspective, it is very hard to do anything when
> nothing is happening. No commits means no code being contributed, no
> code being contributed means no releases, and no discussions.
> Attracting new committers is difficult, but if you only sit back and
> do nothing, why would anybody join? How would anybody find out about
> etch? An article from 2008? If you look at an open source project and
> you see one commit in a year, 5 messages to all lists, would you
> conclude that the project is healthy and thriving and a sound choice?
That are all valid concerns (I was surprised to learn that there
apparently is a C binding, for instance). On the other hand, there
are other similar frameworks which thrive despite a lack of
documentation for basic aspects such as IDL syntax and on-the-wire
format.
> As far as I'm concerned there are 2 options on the table:
> - continue incubation and re-evaluate after 6 months and strive to
> become a viable community
> - stop incubation, and take the code elsewhere (github, google code,
> or just in-house development)
What puzzles me (as someone who is not familiar with the internal
workings of the ASF): there are four or five projects which are quite
similar in scope inside the ASF in the serialization/RPC area (Avro,
Axis2 and Xerces, Etch, Thrift).
Anyway, we're looking into evolving our own internal RPC at some point
in the near feature, and Etch is a candidate. Like most other
candidates, it does not seem to offer one particular feature we're
interested in (streaming of large lists and blobs).
--
Florian Weimer <fw...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Re: Future of Etch
Posted by Martijn Dashorst <ma...@gmail.com>.
Hi Holger,
Thanks for your thoughtful response. The problem is not the technology
aspect but the community aspect. When etch joined the incubator the
project was an in-house cisco project with cisco paid developers.
Since then cisco dismantled the team and the members have gone to
greener pastures. What could have been a great (albeit small)
community was killed with that action: there were no non-cisco
developers working on the technology at that time. In my opinion, had
the project consisted of a diverse team, we would have been in better
shape.
When we asked you and Michael to join the etch team, we were hoping to
see discussions, commits, jira tickets filed, etc. The stuff that
makes a community alive and thrive.
>From a mentoring perspective, it is very hard to do anything when
nothing is happening. No commits means no code being contributed, no
code being contributed means no releases, and no discussions.
Attracting new committers is difficult, but if you only sit back and
do nothing, why would anybody join? How would anybody find out about
etch? An article from 2008? If you look at an open source project and
you see one commit in a year, 5 messages to all lists, would you
conclude that the project is healthy and thriving and a sound choice?
That said, if more folks are willing to make this *community* work,
I'm willing to re-evaluate the viability of etch in six months. But
we're going to need to see activity: releases, commits, discussions,
etc. All those things are necessary to create a healthy project ready
to graduate. However, sustained silence will inevitably result in an
end to the incubation effort.
As far as I'm concerned there are 2 options on the table:
- continue incubation and re-evaluate after 6 months and strive to
become a viable community
- stop incubation, and take the code elsewhere (github, google code,
or just in-house development)
It is up to the etch community and determine its future.
Martijn
On Mon, Sep 6, 2010 at 6:13 PM, Holger Grandy
<Ho...@bmw-carit.de> wrote:
> Hello Etch-*,
>
> regarding the current discussion: Etch is a viable technology.
> BMW uses Etch in products, and Etch has proven itself useful in productive
> environments. If you buy a Mini in the future, Etch will drive around with
> you. We are still using it, and - as I have already written in the past - we
> see good reasons for doing so. Etch provides a good communication model and
> a good architecture for efficient binary two-way RPC.
>
> As a benefit for the community, we have committed our C binding implementation
> with lots of code recently. Since this is company driven development, committing
> to the ASF was not a continous process. We worked on it for around half a year
> continously. If we would have used the ASF SVN repository during development, this
> "non-activity" discussion would not have happened now :) This would change in
> the future as we now are ASF committers.
>
> We have an interest in Etch being publicly available, under the hood of the
> Apache foundation. We want to see it in a continous development path.
> We do not want to see it retired. This project has its weaknesses,
> without a doubt, but remember in this discussion, there are people using Etch
> and there are people developing for Etch, and its not only us.
>
> Regards,
> Holger & Michael
>
>
> -----Original Message-----
> From: Manoj Ganesan [mailto:manoj.ganesan@gmail.com]
> Sent: Freitag, 3. September 2010 16:33
> To: etch-dev@incubator.apache.org
> Subject: Re: Future of Etch
>
> Niclas,
>
> Being the mentor, you would remember the professional transition all the
> original Etch developers went through around a year back. That obviously
> hits the brakes on how fast the technology is adopted, and some time is
> warranted for the project to grow with the creators getting their
> professional lives back on track.
>
> The technology isn't something you can try out, and exclaim success in a few
> days. To see if Etch is a custom-fit for users, it is only reasonable to
> expect that it'll take some time and experimentation. Especially, with some
> similar technologies in existence for longer.
>
> It's not that the project is in oblivion. Holger and folks have been working
> extensively on the C binding and have been reporting success with the
> system. There are other questions/comments, albeit not too frequent,
> including one informing us of their success with using Etch (first version
> of NetKernel Protocol). The creators of the project use it at their
> workplace. I have been investigating Etch being the possible IPC protocol
> for our future architecture at my work.
>
> So there are people who are obviously using it. Why 'retire' it then?
> Doesn't the term itself discourage people from trying the technology out.
> Wouldn't it be better to retire it when it's deemed of being obsolete, or
> that it's giving Apache a bad name, or that no one is really using it?
> Neither of these seem true today.
>
> What do you think?
>
> Thanks,
> Manoj
>
>
> On Fri, Sep 3, 2010 at 1:20 AM, Youngjin Park (youngjpa) <youngjpa@cisco.com
>> wrote:
>
>> I feel pain. I had full of interesting in Etch and I still have it. But, it
>> was very difficult to allocate my extra time to do this in a new team where
>> Apache Etch was not born and especially in a team having so many upcoming
>> projects in front of me. It was obviously interesting project, but it was
>> beyond my control in recent days in a new team and in a new place. Sorry
>> about hearing this.
>>
>> Youngjin
>>
>> -----Original Message-----
>> From: James Dixson [mailto:dixson3@gmail.com]
>> Sent: Wednesday, September 01, 2010 10:31 PM
>> To: etch-dev@incubator.apache.org
>> Subject: Re: Future of Etch
>>
>> If Apache does not like the rate of progress, then that is Apache's
>> prerogative. I do not like it, I do not want it to happen, but I
>> personally have no energy or interest in jumping through any other hoops
>> to try and prevent it.
>>
>> I find it unfortunate that if the project is forcibly retired that it
>> will require any other contributions to the project to be made somewhere
>> else.
>>
>> Looking back over the last 2yrs I have found this whole incubation
>> experience to be a bit too *fussy*. Everything from the long drawn-out
>> discomfort about the "Etch" name to the continual pressure to wrangle
>> new committers, to this latest (and just a little bit patronizing) label
>> of "retirement". It is disappointing because such a label *is*
>> stigmatizing to the technology in a way that is completely not the
>> technology's "fault".
>>
>> I do not blame any of the mentors, past or present. I blame ourselves
>> for thinking that Apache adoption of Etch would be a good thing for both
>> Etch and Apache. Instead the experience has been more like moving into a
>> gated community with an over-aggressive home-owners association who
>> wants us evicted because we are not mowing our grass twice a week.
>>
>> I am sure you have heard this kind of criticism before (I certainly have
>> read things like this in the incubator forum). I feel I understand a lot
>> better what Apache affiliation is and will certainly think twice before
>> considering this again in the future. "Success" as Apache
>> defines it just seems more correlated with the extroverted tendencies of
>> the committers rather than the merits of technology.
>>
>> Finally, despite it all of my belly-aching I do appreciate all of the
>> time and energy the mentors have provided. If I have offended, I do not
>> intend to, I only intend to express my frustration and disappointment
>> with the process.
>>
>> The situation is what it is.
>>
>> --
>> james
>>
>> * Niclas Hedhman <ni...@hedhman.org> [2010-09-02 09:04:01 +0800]:
>>
>> > Guys,
>> > we think that the non-activity of Etch is really "permanent" and will
>> > propose to the Incubator to make the project "Retired".
>> >
>> > As it is Reporting Month for Etch in September, I am suggesting that
>> > we send this message instead of fabricating a "weak" report.
>> >
>> > If you have any serious objections, now is the time to speak.
>> >
>> > As for the codebase; Anyone is free to take it and do what ever they
>> > want, within the limits of the Apache license, the SVN history will
>> > remain, but made read-only. If I new community is to emerge, they can
>> > request Etch to come out of retirement (not common).
>> >
>> > This is in no way reflecting negative on the individuals involved in
>> > Etch, as we are well aware of the challenges to bootstrap communities.
>> >
>> > Cheers
>> > --
>> > Niclas Hedhman, Software Developer
>> > http://www.qi4j.org - New Energy for Java
>> >
>> > I live here; http://tinyurl.com/2qq9er
>> > I work here; http://tinyurl.com/2ymelc
>> > I relax here; http://tinyurl.com/2cgsug
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
RE: Future of Etch
Posted by Holger Grandy <Ho...@bmw-carit.de>.
Hello Etch-*,
regarding the current discussion: Etch is a viable technology.
BMW uses Etch in products, and Etch has proven itself useful in productive
environments. If you buy a Mini in the future, Etch will drive around with
you. We are still using it, and - as I have already written in the past - we
see good reasons for doing so. Etch provides a good communication model and
a good architecture for efficient binary two-way RPC.
As a benefit for the community, we have committed our C binding implementation
with lots of code recently. Since this is company driven development, committing
to the ASF was not a continous process. We worked on it for around half a year
continously. If we would have used the ASF SVN repository during development, this
"non-activity" discussion would not have happened now :) This would change in
the future as we now are ASF committers.
We have an interest in Etch being publicly available, under the hood of the
Apache foundation. We want to see it in a continous development path.
We do not want to see it retired. This project has its weaknesses,
without a doubt, but remember in this discussion, there are people using Etch
and there are people developing for Etch, and its not only us.
Regards,
Holger & Michael
-----Original Message-----
From: Manoj Ganesan [mailto:manoj.ganesan@gmail.com]
Sent: Freitag, 3. September 2010 16:33
To: etch-dev@incubator.apache.org
Subject: Re: Future of Etch
Niclas,
Being the mentor, you would remember the professional transition all the
original Etch developers went through around a year back. That obviously
hits the brakes on how fast the technology is adopted, and some time is
warranted for the project to grow with the creators getting their
professional lives back on track.
The technology isn't something you can try out, and exclaim success in a few
days. To see if Etch is a custom-fit for users, it is only reasonable to
expect that it'll take some time and experimentation. Especially, with some
similar technologies in existence for longer.
It's not that the project is in oblivion. Holger and folks have been working
extensively on the C binding and have been reporting success with the
system. There are other questions/comments, albeit not too frequent,
including one informing us of their success with using Etch (first version
of NetKernel Protocol). The creators of the project use it at their
workplace. I have been investigating Etch being the possible IPC protocol
for our future architecture at my work.
So there are people who are obviously using it. Why 'retire' it then?
Doesn't the term itself discourage people from trying the technology out.
Wouldn't it be better to retire it when it's deemed of being obsolete, or
that it's giving Apache a bad name, or that no one is really using it?
Neither of these seem true today.
What do you think?
Thanks,
Manoj
On Fri, Sep 3, 2010 at 1:20 AM, Youngjin Park (youngjpa) <youngjpa@cisco.com
> wrote:
> I feel pain. I had full of interesting in Etch and I still have it. But, it
> was very difficult to allocate my extra time to do this in a new team where
> Apache Etch was not born and especially in a team having so many upcoming
> projects in front of me. It was obviously interesting project, but it was
> beyond my control in recent days in a new team and in a new place. Sorry
> about hearing this.
>
> Youngjin
>
> -----Original Message-----
> From: James Dixson [mailto:dixson3@gmail.com]
> Sent: Wednesday, September 01, 2010 10:31 PM
> To: etch-dev@incubator.apache.org
> Subject: Re: Future of Etch
>
> If Apache does not like the rate of progress, then that is Apache's
> prerogative. I do not like it, I do not want it to happen, but I
> personally have no energy or interest in jumping through any other hoops
> to try and prevent it.
>
> I find it unfortunate that if the project is forcibly retired that it
> will require any other contributions to the project to be made somewhere
> else.
>
> Looking back over the last 2yrs I have found this whole incubation
> experience to be a bit too *fussy*. Everything from the long drawn-out
> discomfort about the "Etch" name to the continual pressure to wrangle
> new committers, to this latest (and just a little bit patronizing) label
> of "retirement". It is disappointing because such a label *is*
> stigmatizing to the technology in a way that is completely not the
> technology's "fault".
>
> I do not blame any of the mentors, past or present. I blame ourselves
> for thinking that Apache adoption of Etch would be a good thing for both
> Etch and Apache. Instead the experience has been more like moving into a
> gated community with an over-aggressive home-owners association who
> wants us evicted because we are not mowing our grass twice a week.
>
> I am sure you have heard this kind of criticism before (I certainly have
> read things like this in the incubator forum). I feel I understand a lot
> better what Apache affiliation is and will certainly think twice before
> considering this again in the future. "Success" as Apache
> defines it just seems more correlated with the extroverted tendencies of
> the committers rather than the merits of technology.
>
> Finally, despite it all of my belly-aching I do appreciate all of the
> time and energy the mentors have provided. If I have offended, I do not
> intend to, I only intend to express my frustration and disappointment
> with the process.
>
> The situation is what it is.
>
> --
> james
>
> * Niclas Hedhman <ni...@hedhman.org> [2010-09-02 09:04:01 +0800]:
>
> > Guys,
> > we think that the non-activity of Etch is really "permanent" and will
> > propose to the Incubator to make the project "Retired".
> >
> > As it is Reporting Month for Etch in September, I am suggesting that
> > we send this message instead of fabricating a "weak" report.
> >
> > If you have any serious objections, now is the time to speak.
> >
> > As for the codebase; Anyone is free to take it and do what ever they
> > want, within the limits of the Apache license, the SVN history will
> > remain, but made read-only. If I new community is to emerge, they can
> > request Etch to come out of retirement (not common).
> >
> > This is in no way reflecting negative on the individuals involved in
> > Etch, as we are well aware of the challenges to bootstrap communities.
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://www.qi4j.org - New Energy for Java
> >
> > I live here; http://tinyurl.com/2qq9er
> > I work here; http://tinyurl.com/2ymelc
> > I relax here; http://tinyurl.com/2cgsug
>
Re: Future of Etch
Posted by Manoj Ganesan <ma...@gmail.com>.
Niclas,
Being the mentor, you would remember the professional transition all the
original Etch developers went through around a year back. That obviously
hits the brakes on how fast the technology is adopted, and some time is
warranted for the project to grow with the creators getting their
professional lives back on track.
The technology isn't something you can try out, and exclaim success in a few
days. To see if Etch is a custom-fit for users, it is only reasonable to
expect that it'll take some time and experimentation. Especially, with some
similar technologies in existence for longer.
It's not that the project is in oblivion. Holger and folks have been working
extensively on the C binding and have been reporting success with the
system. There are other questions/comments, albeit not too frequent,
including one informing us of their success with using Etch (first version
of NetKernel Protocol). The creators of the project use it at their
workplace. I have been investigating Etch being the possible IPC protocol
for our future architecture at my work.
So there are people who are obviously using it. Why 'retire' it then?
Doesn't the term itself discourage people from trying the technology out.
Wouldn't it be better to retire it when it's deemed of being obsolete, or
that it's giving Apache a bad name, or that no one is really using it?
Neither of these seem true today.
What do you think?
Thanks,
Manoj
On Fri, Sep 3, 2010 at 1:20 AM, Youngjin Park (youngjpa) <youngjpa@cisco.com
> wrote:
> I feel pain. I had full of interesting in Etch and I still have it. But, it
> was very difficult to allocate my extra time to do this in a new team where
> Apache Etch was not born and especially in a team having so many upcoming
> projects in front of me. It was obviously interesting project, but it was
> beyond my control in recent days in a new team and in a new place. Sorry
> about hearing this.
>
> Youngjin
>
> -----Original Message-----
> From: James Dixson [mailto:dixson3@gmail.com]
> Sent: Wednesday, September 01, 2010 10:31 PM
> To: etch-dev@incubator.apache.org
> Subject: Re: Future of Etch
>
> If Apache does not like the rate of progress, then that is Apache's
> prerogative. I do not like it, I do not want it to happen, but I
> personally have no energy or interest in jumping through any other hoops
> to try and prevent it.
>
> I find it unfortunate that if the project is forcibly retired that it
> will require any other contributions to the project to be made somewhere
> else.
>
> Looking back over the last 2yrs I have found this whole incubation
> experience to be a bit too *fussy*. Everything from the long drawn-out
> discomfort about the "Etch" name to the continual pressure to wrangle
> new committers, to this latest (and just a little bit patronizing) label
> of "retirement". It is disappointing because such a label *is*
> stigmatizing to the technology in a way that is completely not the
> technology's "fault".
>
> I do not blame any of the mentors, past or present. I blame ourselves
> for thinking that Apache adoption of Etch would be a good thing for both
> Etch and Apache. Instead the experience has been more like moving into a
> gated community with an over-aggressive home-owners association who
> wants us evicted because we are not mowing our grass twice a week.
>
> I am sure you have heard this kind of criticism before (I certainly have
> read things like this in the incubator forum). I feel I understand a lot
> better what Apache affiliation is and will certainly think twice before
> considering this again in the future. "Success" as Apache
> defines it just seems more correlated with the extroverted tendencies of
> the committers rather than the merits of technology.
>
> Finally, despite it all of my belly-aching I do appreciate all of the
> time and energy the mentors have provided. If I have offended, I do not
> intend to, I only intend to express my frustration and disappointment
> with the process.
>
> The situation is what it is.
>
> --
> james
>
> * Niclas Hedhman <ni...@hedhman.org> [2010-09-02 09:04:01 +0800]:
>
> > Guys,
> > we think that the non-activity of Etch is really "permanent" and will
> > propose to the Incubator to make the project "Retired".
> >
> > As it is Reporting Month for Etch in September, I am suggesting that
> > we send this message instead of fabricating a "weak" report.
> >
> > If you have any serious objections, now is the time to speak.
> >
> > As for the codebase; Anyone is free to take it and do what ever they
> > want, within the limits of the Apache license, the SVN history will
> > remain, but made read-only. If I new community is to emerge, they can
> > request Etch to come out of retirement (not common).
> >
> > This is in no way reflecting negative on the individuals involved in
> > Etch, as we are well aware of the challenges to bootstrap communities.
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://www.qi4j.org - New Energy for Java
> >
> > I live here; http://tinyurl.com/2qq9er
> > I work here; http://tinyurl.com/2ymelc
> > I relax here; http://tinyurl.com/2cgsug
>
RE: Future of Etch
Posted by "Youngjin Park (youngjpa)" <yo...@cisco.com>.
I feel pain. I had full of interesting in Etch and I still have it. But, it was very difficult to allocate my extra time to do this in a new team where Apache Etch was not born and especially in a team having so many upcoming projects in front of me. It was obviously interesting project, but it was beyond my control in recent days in a new team and in a new place. Sorry about hearing this.
Youngjin
-----Original Message-----
From: James Dixson [mailto:dixson3@gmail.com]
Sent: Wednesday, September 01, 2010 10:31 PM
To: etch-dev@incubator.apache.org
Subject: Re: Future of Etch
If Apache does not like the rate of progress, then that is Apache's
prerogative. I do not like it, I do not want it to happen, but I
personally have no energy or interest in jumping through any other hoops
to try and prevent it.
I find it unfortunate that if the project is forcibly retired that it
will require any other contributions to the project to be made somewhere
else.
Looking back over the last 2yrs I have found this whole incubation
experience to be a bit too *fussy*. Everything from the long drawn-out
discomfort about the "Etch" name to the continual pressure to wrangle
new committers, to this latest (and just a little bit patronizing) label
of "retirement". It is disappointing because such a label *is*
stigmatizing to the technology in a way that is completely not the
technology's "fault".
I do not blame any of the mentors, past or present. I blame ourselves
for thinking that Apache adoption of Etch would be a good thing for both
Etch and Apache. Instead the experience has been more like moving into a
gated community with an over-aggressive home-owners association who
wants us evicted because we are not mowing our grass twice a week.
I am sure you have heard this kind of criticism before (I certainly have
read things like this in the incubator forum). I feel I understand a lot
better what Apache affiliation is and will certainly think twice before
considering this again in the future. "Success" as Apache
defines it just seems more correlated with the extroverted tendencies of
the committers rather than the merits of technology.
Finally, despite it all of my belly-aching I do appreciate all of the
time and energy the mentors have provided. If I have offended, I do not
intend to, I only intend to express my frustration and disappointment
with the process.
The situation is what it is.
--
james
* Niclas Hedhman <ni...@hedhman.org> [2010-09-02 09:04:01 +0800]:
> Guys,
> we think that the non-activity of Etch is really "permanent" and will
> propose to the Incubator to make the project "Retired".
>
> As it is Reporting Month for Etch in September, I am suggesting that
> we send this message instead of fabricating a "weak" report.
>
> If you have any serious objections, now is the time to speak.
>
> As for the codebase; Anyone is free to take it and do what ever they
> want, within the limits of the Apache license, the SVN history will
> remain, but made read-only. If I new community is to emerge, they can
> request Etch to come out of retirement (not common).
>
> This is in no way reflecting negative on the individuals involved in
> Etch, as we are well aware of the challenges to bootstrap communities.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
Re: Future of Etch
Posted by James Dixson <di...@gmail.com>.
If Apache does not like the rate of progress, then that is Apache's
prerogative. I do not like it, I do not want it to happen, but I
personally have no energy or interest in jumping through any other hoops
to try and prevent it.
I find it unfortunate that if the project is forcibly retired that it
will require any other contributions to the project to be made somewhere
else.
Looking back over the last 2yrs I have found this whole incubation
experience to be a bit too *fussy*. Everything from the long drawn-out
discomfort about the "Etch" name to the continual pressure to wrangle
new committers, to this latest (and just a little bit patronizing) label
of "retirement". It is disappointing because such a label *is*
stigmatizing to the technology in a way that is completely not the
technology's "fault".
I do not blame any of the mentors, past or present. I blame ourselves
for thinking that Apache adoption of Etch would be a good thing for both
Etch and Apache. Instead the experience has been more like moving into a
gated community with an over-aggressive home-owners association who
wants us evicted because we are not mowing our grass twice a week.
I am sure you have heard this kind of criticism before (I certainly have
read things like this in the incubator forum). I feel I understand a lot
better what Apache affiliation is and will certainly think twice before
considering this again in the future. "Success" as Apache
defines it just seems more correlated with the extroverted tendencies of
the committers rather than the merits of technology.
Finally, despite it all of my belly-aching I do appreciate all of the
time and energy the mentors have provided. If I have offended, I do not
intend to, I only intend to express my frustration and disappointment
with the process.
The situation is what it is.
--
james
* Niclas Hedhman <ni...@hedhman.org> [2010-09-02 09:04:01 +0800]:
> Guys,
> we think that the non-activity of Etch is really "permanent" and will
> propose to the Incubator to make the project "Retired".
>
> As it is Reporting Month for Etch in September, I am suggesting that
> we send this message instead of fabricating a "weak" report.
>
> If you have any serious objections, now is the time to speak.
>
> As for the codebase; Anyone is free to take it and do what ever they
> want, within the limits of the Apache license, the SVN history will
> remain, but made read-only. If I new community is to emerge, they can
> request Etch to come out of retirement (not common).
>
> This is in no way reflecting negative on the individuals involved in
> Etch, as we are well aware of the challenges to bootstrap communities.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug