gt;>>-Original Message-
>>>From: Karl Wright [mailto:daddy...@gmail.com]
>>>Sent: Tuesday, April 03, 2012 1:24 PM
>>>To: general@incubator.apache.org
>>>Subject: Re: Question about downloading binaries
>>>
>>>"Also, making sure the
ght [mailto:daddy...@gmail.com]
>>Sent: Tuesday, April 03, 2012 1:24 PM
>>To: general@incubator.apache.org
>>Subject: Re: Question about downloading binaries
>>
>>"Also, making sure the other comments on NOTICEs are addressed as well."
>>
>>I have
the same root. Is that correct?
Karl
On Tue, Apr 3, 2012 at 2:05 PM, Franklin, Matthew B.
wrote:
>>-Original Message-
>>From: Karl Wright [mailto:daddy...@gmail.com]
>>Sent: Tuesday, April 03, 2012 1:24 PM
>>To: general@incubator.apache.org
>>Subject:
>-Original Message-
>From: Karl Wright [mailto:daddy...@gmail.com]
>Sent: Tuesday, April 03, 2012 1:24 PM
>To: general@incubator.apache.org
>Subject: Re: Question about downloading binaries
>
>"Also, making sure the other comments on NOTICEs are addressed
"Also, making sure the other comments on NOTICEs are addressed as well."
I have gotten extremely confusing advice in this area in the past, and
the available documentation does not help. I believe I am adhering to
Roy's principles, but before we spin another release candidate, I'd
like it very mu
> Hope that helps... The question is, will Roy (or anyone else) be
> unwilling to vote for the first option?
Having been one of the people that commented and started the thread, I feel
like I was wearing loose clothing while operating machinery, per Roy's guidance
on the source being the thing
On Tue, Apr 3, 2012 at 5:04 PM, Karl Wright wrote:
> It sounds like I wasn't clear enough.
>
> The proposal is for the following release artifacts:
>
> (1) A source-only tar
> (2) A source+binary dependencies convenience tar
> (3) A binary tar
>
> This is instead of:
>
> (1) A source-only tar
> (2
It sounds like I wasn't clear enough.
The proposal is for the following release artifacts:
(1) A source-only tar
(2) A source+binary dependencies convenience tar
(3) A binary tar
This is instead of:
(1) A source-only tar
(2) A binary dependencies convenience tar
(3) A binary tar
Hope that help
On Tue, Apr 3, 2012 at 3:43 PM, Karl Wright wrote:
> On Tue, Apr 3, 2012 at 10:33 AM, ant elder wrote:
>> On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting
>> wrote:
>>> Hi,
>>>
>>> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright wrote:
Our mentor(s) are pushing strongly for a source release (whi
On Tue, Apr 3, 2012 at 10:33 AM, ant elder wrote:
> On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting wrote:
>> Hi,
>>
>> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright wrote:
>>> Our mentor(s) are pushing strongly for a source release (which
>>> contains the upstream patches), plus a "lib" release, wh
On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting wrote:
> Hi,
>
> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright wrote:
>> Our mentor(s) are pushing strongly for a source release (which
>> contains the upstream patches), plus a "lib" release, which is to be
>> overlaid on the source release to allow it
Hi,
On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright wrote:
> Our mentor(s) are pushing strongly for a source release (which
> contains the upstream patches), plus a "lib" release, which is to be
> overlaid on the source release to allow it to build.
I wouldn't call it "strongly", rather as just one
"Looking into ManifoldCF a bit, I think what you need is
* buildable source release that contains all the source for ManifoldCF
* source release that contains all the custom patches for the
dependencies that need patches"
Our mentor(s) are pushing strongly for a source release (which
contains the
(dropped infra@)
On Mon, Apr 2, 2012 at 10:54 PM, Benson Margulies wrote:
> I'm exceedingly sorry here that the IPMC as a whole let you down by
> not turning into these issues and dealing with them at the outset.
Me too.
> Personally, I have no objection to including mutant jars in a -deps
> bi
On 3 April 2012 00:48, Jukka Zitting wrote:
> Hi,
>
> [dropped infrastructure@]
>
> On Tue, Apr 3, 2012 at 1:43 AM, sebb wrote:
>> Can you be certain that the non-standard jars will not interfere with
>> the standard jars?
>
> ManifoldCF is a standalone application, not a library you'd use as a
>
Hi,
[dropped infrastructure@]
On Tue, Apr 3, 2012 at 1:43 AM, sebb wrote:
> Can you be certain that the non-standard jars will not interfere with
> the standard jars?
ManifoldCF is a standalone application, not a library you'd use as a
dependency of another application. Thus whatever code goes
On 3 April 2012 00:38, Karl Wright wrote:
> "Whether it is necessary is another matter, and is not easy to answer
> in general as "it depends"."
>
> I'm going to treat this as "unnecessary", because we were extremely
> careful to maintain backwards compatibility when writing the changes.
The API
"Whether it is necessary is another matter, and is not easy to answer
in general as "it depends"."
I'm going to treat this as "unnecessary", because we were extremely
careful to maintain backwards compatibility when writing the changes.
Karl
On Mon, Apr 2, 2012 at 6:59 PM, sebb wrote:
> On 2 Ap
On 2 April 2012 22:45, Karl Wright wrote:
> I think the bigger picture here is that resolving differences of this
> kind requires time, and during the interim we need to be able to
> release software anyway. I have no wish to maintain a forked copy of
> either xerces or httpclient indefinitely, b
I think the bigger picture here is that resolving differences of this
kind requires time, and during the interim we need to be able to
release software anyway. I have no wish to maintain a forked copy of
either xerces or httpclient indefinitely, but right at the moment we
are not prepared or able
"what's the use-case for non-well-formed
XML?' This thread is probably not the best place to delve further in
that direction."
Simple use case: parsing malformed RSS feeds. I agree, though, we're
getting into the weeds here; I'd love to have this discussion
elsewhere, but the point does stand tha
Karl,
I'm exceedingly sorry here that the IPMC as a whole let you down by
not turning into these issues and dealing with them at the outset.
There's been a lot of sensitivity expressed lately to Apache projects
stepping on each other's toes.
Personally, I have no objection to including mutant jar
overall build process.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hope this helps.
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf
>>>&g
>>>>
>>>>>> Hope this helps.
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf
>>>>>> wrote:
>>>>>>> Forward to list
>>&g
ther infra@ or legal@ perspective.
>>>>>>
>>>>>> Karl Wright wrote on Mon, Apr 02, 2012 at 12:21:17 -0400:
>>>>>>> "'svn patch' exists in 1.7."
>>>>>>>
>>>>>>> Ok, so that i
patched jar by checking
>>>>>> out the project tag from svn and using svn patch, not by downloading
>>>>>> the source tarball. Do you think it is ok to allow svn access as part
>>>>>> of a project's build process?
>>>>&g
rl
>>>>>
>>>>>
>>>>> On Mon, Apr 2, 2012 at 12:16 PM, Daniel Shahaf
>>>>> wrote:
>>>>> > 'svn patch' exists in 1.7. (and tortoise includes svn.exe as an
>>>>> > optional component, I hear)
. (and tortoise includes svn.exe as an
>>>> > optional component, I hear)
>>>> >
>>>> > Karl Wright wrote on Mon, Apr 02, 2012 at 12:05:47 -0400:
>>>> >> The patches are contained in SVN, yes, but the build process is
>>>>
optional component, I hear)
>>>> >
>>>> > Karl Wright wrote on Mon, Apr 02, 2012 at 12:05:47 -0400:
>>>> >> The patches are contained in SVN, yes, but the build process is
>>>> >> structured to work on Windows as well as Linux, and there isn
; >> structured to work on Windows as well as Linux, and there isn't a
>>> >> standard patch utility on Windows.
>>> >>
>>> >> We could insist that people only build on Linux, I suppose, but that
>>> >> would be a huge inconvenience for a lot of pe
30 matches
Mail list logo
