If we are going to vote let's make a decision per project. I originally
brought this issue up because I wanted to provide snapshots for cli and
configuration to people willing to try out new features/bug fixes.
As I understand math is probably not interested in having daily
snapshots, I don't
Hi,
Gary Gregory wrote:
> On Wed, Aug 3, 2011 at 10:02 AM, Jörg Schaible
> wrote:
>> Hi Hen,
>>
>> Henri Yandell wrote:
>>
>>> I'd like to release 3.0.1 of Lang.
>>
>> Do we have any policies regarding Serializable types? I'd like to make
>> StrMatcher, StrLookup and StrSubstitutor serializable.
On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory wrote:
> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict wrote:
>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>> feature requests would be implemented quicker, I hope.
>
> I like Log4J just fine thank you very much :)
>
> I'm lo
I think we should move the current trunk off and call it generics-RnD.
Then we should copy 3.2 over to trunk (or maybe 3.3, I seem to recall
that prior to merging the generics in we had a 3.3 ready for release).
We then release 3.3.
Then we start 3.4. We genericize some tiny part of it in a bina
To quote the Infra team; ENOCARE :)
Now, if you're going to deploy the Maven generated website
automatically, I may care.
Hen
On Thu, Aug 4, 2011 at 10:57 PM, Ralph Goers wrote:
> We can hold a vote. I would be persuaded to vote no if someone could point to
> an ASF or incubator policy that sa
We can hold a vote. I would be persuaded to vote no if someone could point to
an ASF or incubator policy that says we should not do this.
Ralph
On Aug 4, 2011, at 10:08 PM, Phil Steitz wrote:
> Looks like we have been experimenting with this. Before actually
> turning anything on, we need shou
Looks like we have been experimenting with this. Before actually
turning anything on, we need should agree that we actually want to
to do this and probably VOTE, as I assume the generated artifacts
are going to be publicly available. My personal opinion is that we
should not do this.
Phil
-
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10941&projectId=206
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 5 Aug 2011 04:07:01 +
Finished at: Fri 5 Aug 2011 04:08:31 +
Total time: 1m 29s
Build Trigger: Forced
Bui
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10931&projectId=116
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 5 Aug 2011 04:00:33 +
Finished at: Fri 5 Aug 2011 04:00:49 +
Total time: 15s
Build Trigger: Forced
Build
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10929&projectId=108
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 5 Aug 2011 03:58:35 +
Finished at: Fri 5 Aug 2011 04:00:16 +
Total time: 1m 41s
Build Trigger: Forced
Bui
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10905&projectId=70
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 5 Aug 2011 03:37:19 +
Finished at: Fri 5 Aug 2011 03:37:58 +
Total time: 38s
Build Trigger: Forced
Build Numbe
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10896&projectId=67
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 5 Aug 2011 02:15:04 +
Finished at: Fri 5 Aug 2011 02:15:24 +
Total time: 20s
Build Trigger: Forced
Build Numbe
2011/8/4 Gilles Sadowski :
>> [...]
>>
>> The management of the exception messages through String constants and enums
>> is
>> in my view a very clean thing. Should we do the same for exception context
>> keys? Have a big enum holding keys?
>
> I'd rather not, but I'm afraid that others will think
On 2011-08-04 Stefan Bodewig wrote:
> On 2011-08-04, Lasse Collin wrote:
> > Using bits from the end of stream magic doesn't make sense, because
> > then one would be forced to finish the stream. Using the bits from
> > the block header magic means that one must add at least one more
> > block. Thi
On 2011-08-04 Stefan Bodewig wrote:
> There are a few places where our implementation doesn't allow for the
> full range the ZIP format would support. Some are easy to fix, some
> hard and I'm asking for feedback whether you consider it worth the
> effort to fix them at all.
I guess that these ar
On 2011-08-04, Lasse Collin wrote:
> On 2011-08-04 Stefan Bodewig wrote:
>> This is in a big part due to the history of Commons Compress which
>> combined several different codebases with separate APIs and provided a
>> first attempt to layer a unifying API on top of it. We are aware of
>> quite
> ZipFile relies on RandomAccessFile so any archive can't be bigger than
> the maximum size supported by RandomAccessFile. In particular the seek
> method expects a long as argument so the hard limit would be an archive
> size of 2^63-1 bytes. In practice I expect RandomAccessFile to not
> suppor
> [...]
>
> The management of the exception messages through String constants and enums is
> in my view a very clean thing. Should we do the same for exception context
> keys? Have a big enum holding keys?
I'd rather not, but I'm afraid that others will think otherwise :-}.
> Or should we define
Hi all,
ZIP64 support in trunk is almost complete except for a case that is
pretty easy to implement but where I'll ask for API feedback once I've
managed to read up on how the InfoZIP people handle it.
There are a few places where our implementation doesn't allow for the
full range the ZIP forma
2011/8/4 Gilles Sadowski :
>> >
>> >> I'm OK to define a new exception. From your PS, I understand that I
should
>> >> wait until what I've already submitted (MATH-581-06.zip) has been
>> committed
>> >> until I submit a patch containing the new exception. Is that right?
>> >
>> > I would have th
Actually if you just reattach revised files using the original names Kira
will do a great job of managing which is the latest. That let's curious folk
go back in history if they want to see what has changed.
On Thursday, August 4, 2011, Gilles Sadowski
wrote:
>> >
>> >> I'm OK to define a new exc
> >
> >> I'm OK to define a new exception. From your PS, I understand that I should
> >> wait until what I've already submitted (MATH-581-06.zip) has been
> committed
> >> until I submit a patch containing the new exception. Is that right?
> >
> > I would have thought the other way around: First co
Hi,
thanks for your answer.
2011/8/4 Gilles Sadowski :
> Hello.
>
>> I'm OK to define a new exception. From your PS, I understand that I should
>> wait until what I've already submitted (MATH-581-06.zip) has been
committed
>> until I submit a patch containing the new exception. Is that right?
>
>
Hello.
> I'm OK to define a new exception. From your PS, I understand that I should
> wait until what I've already submitted (MATH-581-06.zip) has been committed
> until I submit a patch containing the new exception. Is that right?
I would have thought the other way around: First commit the excep
On 2011-08-04 Stefan Bodewig wrote:
> On 2011-08-03, Lasse Collin wrote:
> > I looked at the APIs and code in Commons Compress to see how XZ
> > support could be added. I was especially looking for details where
> > one would need to be careful to make different compressors behave
> > consistently
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Hi Gilles,
I'm OK to define a new exception. From your PS, I understand that I should
wait until what I've already submitted (MATH-581-06.zip) has been committed
until I submit a patch containing the new exception. Is that right?
I don't think it's necessary to open a new JIRA ticket for this, do y
Hello.
> please review a proposal for the definition of general iterative linear
> solvers, as well as the implementation of the conjugate gradient method. This
> is file MATH-581-06.zip attached to the JIRA MATH-581 ticket.
> Thanks for your comments!
>
> Actually, I *do* have a comment. For the
On 04.08.11 01:08, Rahul Akolkar wrote:
> On Wed, Jul 27, 2011 at 3:54 PM, Rahul Akolkar
> wrote:
> I cp -R'ed the site over, but it should be republished more gracefully.
Sorry for the delay, I still need to find the time to move the site to
Maven-2. Will re-publish when that is done.
Bye, Tho
29 matches
Mail list logo
