etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott comer <>
Subject Re: [VOTE] Contents of Release 1.1
Date Tue, 14 Sep 2010 16:44:21 GMT
  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 []
> Sent: Dienstag, 14. September 2010 16:16
> To:
> 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
>> <>   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
>>> 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 []
>>> Sent: Montag, 13. September 2010 15:27
>>> To:
>>> 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
>>>> <>     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

View raw message