Done in r1654980.
This whole incident is a confirmation of murphys law; I must've run
that test 500 times on my machine without failure =:)
K
2015-01-27 0:10 GMT+01:00 Gary Gregory :
> I see you changed the test but the code could benefit from a comment to
> avoid a future regression back to th
In our opinion, the fix is worse than the disease. Here are the comments
from our version:
The following piece of code is new since our 5.2 based version.
It was added in revision 524610 on 2007-04-01, more information is at:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39695 (no
I understand the goal of trying to reuse instructions - an 'iadd' is the
same as any other 'iadd'. However, one 'goto 50' is not the same as
another 'goto 50' due to the way Targeters are implemented. If branch
instructions are reused, then only one entry gets put on the Targeter list.
So when s
Thank you for the detailed summary Mark.
Le 26/01/2015 19:02, Mark Roberts a écrit :
> I'm currently not familiar with your release process and, hence, not sure
> what sorts of changes you are willing to consider at this time. I thought I
> would start with a rough outline of all of our change
I see you changed the test but the code could benefit from a comment to
avoid a future regression back to this problem.
Gary
On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold
wrote:
> Testcase fixed in r1654901
>
> Kristian
>
>
> 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <
> kristian.rose
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "VfsReleaseState" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VfsReleaseState?action=diff&rev1=10&rev2=11
* Preview of Site: http://people.apache
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "VfsReleaseState" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VfsReleaseState?action=diff&rev1=9&rev2=10
Comment:
Opened INFRA ticket
This is a list
The InvokeDynamic and BootstrapMethod changes move some class members around.
So any app that writes a serialized version of the BCEL internal data
structures and re-reads later would have to regenerate those files. Our tools
do not do this; I have no idea if this is common. On the other hand
Testcase fixed in r1654901
Kristian
2015-01-26 22:37 GMT+01:00 Kristian Rosenvold :
> 2015-01-26 22:27 GMT+01:00 Gary Gregory :
>> Tests:
>>
>> Running: 'mvn clean site' gave me
>>
>> Failed tests:
>> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
>> arrays first dif
@sebb: I read this doc when you mentionned it previously and
intentionnaly kept it cause it makes things clearer for me and it is
not mandatory to remove it, just better. I thought more code was from
xerox - why I wanted to keep it. Anyway this is not a blocker at all
and we have to fix it, just wa
2015-01-26 22:27 GMT+01:00 Gary Gregory :
> Tests:
>
> Running: 'mvn clean site' gave me
>
> Failed tests:
> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
> arrays first differed at element [10]; expected:<-16> but was:<-15>
The problem appears to be that time does no
Mark,
This is awesome info. Thank you for taking the time to compile it.
My preference would be to finalize and cut 6.0 ASAP, then start a new
cycle. I am a RERO proponent.
The only caveat here, since we are going for a major version bump is
whether you have some proposal for changes that would
Thank you for preparing this RC Stefan.
Using with src zip from binary dist folder:
MD5 OK.
ASC OK.
Tests:
Running: 'mvn clean site' gave me
Failed tests:
ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
arrays first differed at element [10]; expected:<-16> but was:<
On 26 January 2015 at 17:38, Mark Struberg wrote:
> Sebb, this is nowhere stated in the bylaws. There is just no ground for
> totally blasting a release!
This has come up several times, and the rules are still at:
http://www.apache.org/dev/licensing-howto.html#mod-notice
> It's superfluous and
Good question. When I started work here (at PLSE) in Jan 2013, we had been
using BCEL for some time. We had not released a version of our product in
about three years and one of my tasks was to get back to making regular
releases of the Daikon toolset. So in about May of 2013 I picked up the
Attaching a patch (or pull request) to a JIRA would be a great way for
one of us to take a look at what you have. This is great stuff, man!
We are always glad to have new folks come in and provide patches.
Out of curiosity, what was the reason you rolled your own as opposed
to engaging with the c
I'm currently not familiar with your release process and, hence, not sure what
sorts of changes you are willing to consider at this time. I thought I would
start with a rough outline of all of our changes and then the group could
suggest which ones I should open in JIRA.
We cloned a version of
Sebb, this is nowhere stated in the bylaws. There is just no ground for totally
blasting a release!
It's superfluous and not 100% perfect but it is NOT wrong. The sources
_currenty_ contain this file, so we have it.
For how long is this now in the codebase? 2 years? even longer?
Be glad that Ro
On Mon, Jan 26, 2015 at 11:48 AM, sebb wrote:
>
> Strictly speaking that is true, but when an issue is found, the RM
> should take any vetos into account.
>
They are NOT vetoes.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.
but this is not a blocker and actually can even be considered right
since optional doesn't mean shouldn't be mentioned (in particular I
think it is better to mention it even if optional to avoid ambiguities
and keep the origin explicit)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
htt
On 26 January 2015 at 16:47, Romain Manni-Bucau wrote:
> 2015-01-26 17:41 GMT+01:00 sebb :
>> On 26 January 2015 at 12:20, Romain Manni-Bucau
>> wrote:
>>> Ok so you only speak about dist src bundle?
>>
>> No, it also affects the binary bundle, and it affects the SVN tag
>> (which is also a dist
2015-01-26 17:48 GMT+01:00 sebb :
> On 26 January 2015 at 13:45, James Carman wrote:
>> Release votes cannot be vetoed, so it's just a vote against. If you
>
> The problem here is that there does not appear to be a specific commit
> that can be vetoed which can be said to be the cause of the prob
On 26 January 2015 at 13:45, James Carman wrote:
> Release votes cannot be vetoed, so it's just a vote against. If you
The problem here is that there does not appear to be a specific commit
that can be vetoed which can be said to be the cause of the problem.
> have more +1's than -1's and you h
2015-01-26 17:41 GMT+01:00 sebb :
> On 26 January 2015 at 12:20, Romain Manni-Bucau wrote:
>> Ok so you only speak about dist src bundle?
>
> No, it also affects the binary bundle, and it affects the SVN tag
> (which is also a distribution, though not a release)
>
Not the bundle since aspectj fil
On 26 January 2015 at 12:20, Romain Manni-Bucau wrote:
> Ok so you only speak about dist src bundle?
No, it also affects the binary bundle, and it affects the SVN tag
(which is also a distribution, though not a release)
> Not sure it does need to cancel the vote, this is not a major issue
> IMO
On 26 January 2015 at 11:47, Benedikt Ritter wrote:
> 2015-01-26 12:25 GMT+01:00 sebb :
>
>> On 26 January 2015 at 07:30, Benedikt Ritter wrote:
>> > Hello sebb,
>> >
>> > 2015-01-25 12:55 GMT+01:00 sebb :
>> >
>> >> On 25 January 2015 at 11:12, sebb wrote:
>> >> > On 25 January 2015 at 10:58, B
Release votes cannot be vetoed, so it's just a vote against. If you
have more +1's than -1's and you have at least 3 PMC folks saying +1,
then you can release. However, if we do have an opportunity to clean
something up here, we should take it. If we can just remove this file
and move on without
On Mon, Jan 26, 2015 at 7:03 AM, Benedikt Ritter wrote:
> Hello Adrian
>
> 2015-01-24 19:43 GMT+01:00 Adrian Crum :
>
>> Slightly off-topic but somewhat related...
>>
>> I saw a recent commit where a "performance improvement" went something
>> like this:
>>
>> StringBuilder sb = new StringBuilder(
2015-01-26 14:05 GMT+01:00 Gary Gregory :
> On Mon, Jan 26, 2015 at 7:03 AM, Benedikt Ritter
> wrote:
>
> > Hello Adrian
> >
> > 2015-01-24 19:43 GMT+01:00 Adrian Crum <
> adrian.c...@sandglass-software.com
> > >:
> >
> > > Slightly off-topic but somewhat related...
> > >
> > > I saw a recent com
On Mon, Jan 26, 2015 at 7:03 AM, Benedikt Ritter wrote:
> Hello Adrian
>
> 2015-01-24 19:43 GMT+01:00 Adrian Crum >:
>
> > Slightly off-topic but somewhat related...
> >
> > I saw a recent commit where a "performance improvement" went something
> > like this:
> >
> > StringBuilder sb = new Strin
Ok so you only speak about dist src bundle?
Not sure it does need to cancel the vote, this is not a major issue
IMO and can be fixed for next one
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-26 12:39 GMT+01:0
Hello Adrian
2015-01-24 19:43 GMT+01:00 Adrian Crum :
> Slightly off-topic but somewhat related...
>
> I saw a recent commit where a "performance improvement" went something
> like this:
>
> StringBuilder sb = new StringBuilder();
> sb.append("foo");
>
> was replaced with
>
> StringBuilder sb = n
2015-01-26 12:47 GMT+01:00 Benedikt Ritter :
>
>
> 2015-01-26 12:25 GMT+01:00 sebb :
>
>> On 26 January 2015 at 07:30, Benedikt Ritter wrote:
>> > Hello sebb,
>> >
>> > 2015-01-25 12:55 GMT+01:00 sebb :
>> >
>> >> On 25 January 2015 at 11:12, sebb wrote:
>> >> > On 25 January 2015 at 10:58, Bene
2015-01-26 12:25 GMT+01:00 sebb :
> On 26 January 2015 at 07:30, Benedikt Ritter wrote:
> > Hello sebb,
> >
> > 2015-01-25 12:55 GMT+01:00 sebb :
> >
> >> On 25 January 2015 at 11:12, sebb wrote:
> >> > On 25 January 2015 at 10:58, Benedikt Ritter
> wrote:
> >> >> Hello sebb,
> >> >>
> >> >> 20
On 26 January 2015 at 11:30, Romain Manni-Bucau wrote:
> @sebb: not sure I get it right, it references LICENSE.txt correctly for me
Not sure what you mean by "it" above.
As I already wrote:
The NOTICE file should not reference LICENSE.txt
Nor should it reference LICENSE.xerox, because the Xerox
@sebb: not sure I get it right, it references LICENSE.txt correctly for me
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-26 12:27 GMT+01:00 sebb :
> On 26 January 2015 at 11:19, Romain Manni-Bucau wrote:
>> if t
On 26 January 2015 at 11:19, Romain Manni-Bucau wrote:
> if that's the case +1 but anyway it doesnt hurt
But it does have some consequences, because of the license issues.
> @Thomas: before dropping it can you confirm it a last time please?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.to
On 26 January 2015 at 07:30, Benedikt Ritter wrote:
> Hello sebb,
>
> 2015-01-25 12:55 GMT+01:00 sebb :
>
>> On 25 January 2015 at 11:12, sebb wrote:
>> > On 25 January 2015 at 10:58, Benedikt Ritter wrote:
>> >> Hello sebb,
>> >>
>> >> 2015-01-24 13:16 GMT+01:00 sebb :
>> >>
>> >>> On 24 Januar
if that's the case +1 but anyway it doesnt hurt
@Thomas: before dropping it can you confirm it a last time please?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-26 12:18 GMT+01:00 sebb :
> Why not just drop it e
Why not just drop it entirely?
If that is the only Xerox-licensed file, it is not essential to the
operation of JCS, so why keep it?
On 25 January 2015 at 21:44, Romain Manni-Bucau wrote:
> Hi Mark,
>
> this is not packaged AFAIK, just here as a sample I guess.
>
>
> Romain Manni-Bucau
> @rmanni
40 matches
Mail list logo
