Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java

2013-03-09 Thread sebb 
On 9 March 2013 00:39, Ralph Goers  wrote:
> I'm not sure I understand what the big deal is.  Sebb vetoed a commit and 
> identified exactly what needed to be changed for him to remove the veto.  If 
> the requested change is made then all should be fine with the world again.  
> Sure, he could have said all the same words without the -1 but then it 
> wouldn't be evident that he expected the change to be made.

Thanks.

Yes, I agree that it was perhaps unnecessary for the -1, but we had
already agreed some while ago not to use $Date$ and I did not want to
see that creep back in again.

> Ralph
>
>
> On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
>
>>
>>
>> Niall Pemberton  wrote:
>>
>>> On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas  wrote:
>>
>> 
>>
 One of the primary responsibilities of a PMC member when voting on a
 release is verifying what is being voted on against the tag.
>>> Different
 client locales and $Date$ combine to make every single source file
 different from the tag requiring a manual check of the diff of every
 file to do the verification check properly. Even with good diff
>>> tooling
 the verification process is a lot slower and can't be automated.
>>>
>>> Its not required for a release - although I would agree its a nice
>>> thing to do.Spot check of the files is good enough to see if it has
>>> been created from the tag
>>
>> I very strongly disagree. Any PMC member voting on a release should be
>> verifying every single file in the src tarball with the tag. There are
>> plenty of tools available that make this the work of a few seconds -
>> providing the files agree.
>>
>>> - otherwise we trust our release managers.
>>
>> Not trusting the release managers is not the primary reason that PMC
>> members should be verifying the tarball agrees with the tag (although if
>> a release manager ever does do anything malicious it will catch that
>> to). The primary reason is to catch errors in build process or mistakes
>> made by the release manager. BeanUtils is likely simpler than Tomcat but
>> the sorts of things a full verification has caught has included:
>> - missing files (usually after some form of code re-org)
>> - extra files (IDE files, intermediate files, .svn/.git files,
>> build.properties etc)
>> - wrong line endings (Tomcat tries to use CRLF for zip and LF for tar.gz)
>> - local edits to the source files
>>
>> Some are minor but missing or edited files are clearly serious issues
>> that should cause the release to fail.
>>
>>> BeanUtils has used the $Date$ keyword since 2005 and I cannot remember
>>> it ever coming up in a release vote - so it hasn't stopped it being
>>> released.
>>
>> If the release manager and the people checking the tarball all have the
>> same locale you won't see the issue.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CLI] future and JCommander ?

2013-03-09 Thread Simone Tripodi 
Hi Gary!

they provide same basic features, but Airlines is IMHO a little
stronger in 3 points:

 * drives users on pure command pattern implementation, while in
JCommander you can have just a container of passed parameters;

 * simplifies the building of commands tree, such as `git remote add`
or `git remote show` while on JCommander it is not intuitive how to
reach the 2nd level of commands (undocumented anyway)

 * help usage is handled out of the box, while in JCommander you have
to handle it manually.

HTH, have a nice weekend!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Mar 8, 2013 at 11:29 PM, Gary Gregory  wrote:
> Hi Simo,
>
> Thank you for the pointer. What are the pro and cons of JCommander vs.
> Airline?
>
> Gary
>
>
> On Thu, Mar 7, 2013 at 1:40 AM, Simone Tripodi 
> wrote:
>
>> Hi Gary,
>>
>> there's also new guy in the town, which is called Airline[1], that
>> supports the Git like commands structures. I am JCommander user as
>> well but in one of the last projects I plugged Airline and I really
>> liked it - the Help command is really straightforward! :)
>> Just to say what's the state of the art.
>>
>> I am +1 on moving forward CLI in that direction.
>>
>> Best,
>> -Simo
>>
>> [1] https://github.com/airlift/airline
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Thu, Mar 7, 2013 at 6:32 AM, Gary Gregory 
>> wrote:
>> > Hi All,
>> >
>> > For some new development, I have dropped using our [cli] in favor of
>> > http://jcommander.org/ (also ASL2 licensed), which I find refreshingly
>> > modern and easy to use (annotations!)
>> >
>> > My suggestion is to rapidly move our [cli] in this direction or invite
>> > JCommander in as [cli] 2.0/3/0.
>> >
>> > Thoughts?
>> >
>> > Gary
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> > Spring Batch in Action: http://bit.ly/bqpbCK
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java

2013-03-09 Thread Christian Grobmeier 
On Sat, Mar 9, 2013 at 10:00 AM, sebb  wrote:
> On 9 March 2013 00:39, Ralph Goers  wrote:
>> I'm not sure I understand what the big deal is.  Sebb vetoed a commit and 
>> identified exactly what needed to be changed for him to remove the veto.  If 
>> the requested change is made then all should be fine with the world again.  
>> Sure, he could have said all the same words without the -1 but then it 
>> wouldn't be evident that he expected the change to be made.
>
> Thanks.
>
> Yes, I agree that it was perhaps unnecessary for the -1, but we had
> already agreed some while ago not to use $Date$ and I did not want to
> see that creep back in again.

This is a discussion which seems to come up from time to time, like
the @author tag thing and so on.
Should we start a Wiki page with that kind of decisions? I think it
would be useful, esp for new people. I think Benedikt has asked for
such kind of docs recently.

Cheers
Christian

>> Ralph
>>
>>
>> On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
>>
>>>
>>>
>>> Niall Pemberton  wrote:
>>>
 On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas  wrote:
>>>
>>> 
>>>
> One of the primary responsibilities of a PMC member when voting on a
> release is verifying what is being voted on against the tag.
 Different
> client locales and $Date$ combine to make every single source file
> different from the tag requiring a manual check of the diff of every
> file to do the verification check properly. Even with good diff
 tooling
> the verification process is a lot slower and can't be automated.

 Its not required for a release - although I would agree its a nice
 thing to do.Spot check of the files is good enough to see if it has
 been created from the tag
>>>
>>> I very strongly disagree. Any PMC member voting on a release should be
>>> verifying every single file in the src tarball with the tag. There are
>>> plenty of tools available that make this the work of a few seconds -
>>> providing the files agree.
>>>
 - otherwise we trust our release managers.
>>>
>>> Not trusting the release managers is not the primary reason that PMC
>>> members should be verifying the tarball agrees with the tag (although if
>>> a release manager ever does do anything malicious it will catch that
>>> to). The primary reason is to catch errors in build process or mistakes
>>> made by the release manager. BeanUtils is likely simpler than Tomcat but
>>> the sorts of things a full verification has caught has included:
>>> - missing files (usually after some form of code re-org)
>>> - extra files (IDE files, intermediate files, .svn/.git files,
>>> build.properties etc)
>>> - wrong line endings (Tomcat tries to use CRLF for zip and LF for tar.gz)
>>> - local edits to the source files
>>>
>>> Some are minor but missing or edited files are clearly serious issues
>>> that should cause the release to fail.
>>>
 BeanUtils has used the $Date$ keyword since 2005 and I cannot remember
 it ever coming up in a release vote - so it hasn't stopped it being
 released.
>>>
>>> If the release manager and the people checking the tarball all have the
>>> same locale you won't see the issue.
>>>
>>> Mark
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java

2013-03-09 Thread Niall Pemberton 
On Sat, Mar 9, 2013 at 9:00 AM, sebb  wrote:
> On 9 March 2013 00:39, Ralph Goers  wrote:
>> I'm not sure I understand what the big deal is.  Sebb vetoed a commit and 
>> identified exactly what needed to be changed for him to remove the veto.  If 
>> the requested change is made then all should be fine with the world again.  
>> Sure, he could have said all the same words without the -1 but then it 
>> wouldn't be evident that he expected the change to be made.
>
> Thanks.
>
> Yes, I agree that it was perhaps unnecessary for the -1, but we had
> already agreed some while ago not to use $Date$ and I did not want to
> see that creep back in again.

No, you miss the point - not "unnecessary" - it was an invalid veto
and you should be more circumspect about casting vetos.

Niall


>> Ralph
>>
>>
>> On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
>>
>>>
>>>
>>> Niall Pemberton  wrote:
>>>
 On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas  wrote:
>>>
>>> 
>>>
> One of the primary responsibilities of a PMC member when voting on a
> release is verifying what is being voted on against the tag.
 Different
> client locales and $Date$ combine to make every single source file
> different from the tag requiring a manual check of the diff of every
> file to do the verification check properly. Even with good diff
 tooling
> the verification process is a lot slower and can't be automated.

 Its not required for a release - although I would agree its a nice
 thing to do.Spot check of the files is good enough to see if it has
 been created from the tag
>>>
>>> I very strongly disagree. Any PMC member voting on a release should be
>>> verifying every single file in the src tarball with the tag. There are
>>> plenty of tools available that make this the work of a few seconds -
>>> providing the files agree.
>>>
 - otherwise we trust our release managers.
>>>
>>> Not trusting the release managers is not the primary reason that PMC
>>> members should be verifying the tarball agrees with the tag (although if
>>> a release manager ever does do anything malicious it will catch that
>>> to). The primary reason is to catch errors in build process or mistakes
>>> made by the release manager. BeanUtils is likely simpler than Tomcat but
>>> the sorts of things a full verification has caught has included:
>>> - missing files (usually after some form of code re-org)
>>> - extra files (IDE files, intermediate files, .svn/.git files,
>>> build.properties etc)
>>> - wrong line endings (Tomcat tries to use CRLF for zip and LF for tar.gz)
>>> - local edits to the source files
>>>
>>> Some are minor but missing or edited files are clearly serious issues
>>> that should cause the release to fail.
>>>
 BeanUtils has used the $Date$ keyword since 2005 and I cannot remember
 it ever coming up in a release vote - so it hasn't stopped it being
 released.
>>>
>>> If the release manager and the people checking the tarball all have the
>>> same locale you won't see the issue.
>>>
>>> Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java

2013-03-09 Thread sebb 
On 9 March 2013 11:56, Niall Pemberton  wrote:
> On Sat, Mar 9, 2013 at 9:00 AM, sebb  wrote:
>> On 9 March 2013 00:39, Ralph Goers  wrote:
>>> I'm not sure I understand what the big deal is.  Sebb vetoed a commit and 
>>> identified exactly what needed to be changed for him to remove the veto.  
>>> If the requested change is made then all should be fine with the world 
>>> again.  Sure, he could have said all the same words without the -1 but then 
>>> it wouldn't be evident that he expected the change to be made.
>>
>> Thanks.
>>
>> Yes, I agree that it was perhaps unnecessary for the -1, but we had
>> already agreed some while ago not to use $Date$ and I did not want to
>> see that creep back in again.
>
> No, you miss the point - not "unnecessary" - it was an invalid veto
> and you should be more circumspect about casting vetos.

I think it's borderline.

I would have voted -1 on the RC, because the tag would not agree with
the source archive.

> Niall
>
>
>>> Ralph
>>>
>>>
>>> On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
>>>


 Niall Pemberton  wrote:

> On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas  wrote:

 

>> One of the primary responsibilities of a PMC member when voting on a
>> release is verifying what is being voted on against the tag.
> Different
>> client locales and $Date$ combine to make every single source file
>> different from the tag requiring a manual check of the diff of every
>> file to do the verification check properly. Even with good diff
> tooling
>> the verification process is a lot slower and can't be automated.
>
> Its not required for a release - although I would agree its a nice
> thing to do.Spot check of the files is good enough to see if it has
> been created from the tag

 I very strongly disagree. Any PMC member voting on a release should be
 verifying every single file in the src tarball with the tag. There are
 plenty of tools available that make this the work of a few seconds -
 providing the files agree.

> - otherwise we trust our release managers.

 Not trusting the release managers is not the primary reason that PMC
 members should be verifying the tarball agrees with the tag (although if
 a release manager ever does do anything malicious it will catch that
 to). The primary reason is to catch errors in build process or mistakes
 made by the release manager. BeanUtils is likely simpler than Tomcat but
 the sorts of things a full verification has caught has included:
 - missing files (usually after some form of code re-org)
 - extra files (IDE files, intermediate files, .svn/.git files,
 build.properties etc)
 - wrong line endings (Tomcat tries to use CRLF for zip and LF for tar.gz)
 - local edits to the source files

 Some are minor but missing or edited files are clearly serious issues
 that should cause the release to fail.

> BeanUtils has used the $Date$ keyword since 2005 and I cannot remember
> it ever coming up in a release vote - so it hasn't stopped it being
> released.

 If the release manager and the people checking the tarball all have the
 same locale you won't see the issue.

 Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java

2013-03-09 Thread Niall Pemberton 
On Sat, Mar 9, 2013 at 12:32 PM, sebb  wrote:
> On 9 March 2013 11:56, Niall Pemberton  wrote:
>> On Sat, Mar 9, 2013 at 9:00 AM, sebb  wrote:
>>> On 9 March 2013 00:39, Ralph Goers  wrote:
 I'm not sure I understand what the big deal is.  Sebb vetoed a commit and 
 identified exactly what needed to be changed for him to remove the veto.  
 If the requested change is made then all should be fine with the world 
 again.  Sure, he could have said all the same words without the -1 but 
 then it wouldn't be evident that he expected the change to be made.
>>>
>>> Thanks.
>>>
>>> Yes, I agree that it was perhaps unnecessary for the -1, but we had
>>> already agreed some while ago not to use $Date$ and I did not want to
>>> see that creep back in again.
>>
>> No, you miss the point - not "unnecessary" - it was an invalid veto
>> and you should be more circumspect about casting vetos.
>
> I think it's borderline.

No, not even close - it was an invalid veto - which have to be for
valid *technical* reasons.

> I would have voted -1 on the RC, because the tag would not agree with
> the source archive.

That IMO would have been unfortunate - but votes and vetos are two
completely different things - since a veto *forces" a change - whereas
a -1 vote is by majority and therefore doesn't mean the release would
have been stopped.

Niall


>> Niall
>>
>>
 Ralph


 On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:

>
>
> Niall Pemberton  wrote:
>
>> On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas  wrote:
>
> 
>
>>> One of the primary responsibilities of a PMC member when voting on a
>>> release is verifying what is being voted on against the tag.
>> Different
>>> client locales and $Date$ combine to make every single source file
>>> different from the tag requiring a manual check of the diff of every
>>> file to do the verification check properly. Even with good diff
>> tooling
>>> the verification process is a lot slower and can't be automated.
>>
>> Its not required for a release - although I would agree its a nice
>> thing to do.Spot check of the files is good enough to see if it has
>> been created from the tag
>
> I very strongly disagree. Any PMC member voting on a release should be
> verifying every single file in the src tarball with the tag. There are
> plenty of tools available that make this the work of a few seconds -
> providing the files agree.
>
>> - otherwise we trust our release managers.
>
> Not trusting the release managers is not the primary reason that PMC
> members should be verifying the tarball agrees with the tag (although if
> a release manager ever does do anything malicious it will catch that
> to). The primary reason is to catch errors in build process or mistakes
> made by the release manager. BeanUtils is likely simpler than Tomcat but
> the sorts of things a full verification has caught has included:
> - missing files (usually after some form of code re-org)
> - extra files (IDE files, intermediate files, .svn/.git files,
> build.properties etc)
> - wrong line endings (Tomcat tries to use CRLF for zip and LF for tar.gz)
> - local edits to the source files
>
> Some are minor but missing or edited files are clearly serious issues
> that should cause the release to fail.
>
>> BeanUtils has used the $Date$ keyword since 2005 and I cannot remember
>> it ever coming up in a release vote - so it hasn't stopped it being
>> released.
>
> If the release manager and the people checking the tarball all have the
> same locale you won't see the issue.
>
> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] release Apache Commons-FileUpload 1.3 based on RC1

2013-03-09 Thread Simone Tripodi 
Hi all,

I've prepared the RC1 of  Apache Commons-FileUpload 1.3 so I am here
to call for a vote:

Release Notes:

http://people.apache.org/builds/commons/fileupload/1.3/RC1/RELEASE-NOTES.txt

Tag:

https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_RC1

Site:

http://people.apache.org/builds/commons/fileupload/1.3/RC1/site/index.html
(possible broken links will be fixed once site will be properly
deployed)

Binaries:

http://people.apache.org/builds/commons/fileupload/1.3/RC1/binaries

Staging Maven Artifacts:

https://repository.apache.org/content/repositories/orgapachecommons-008/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because

Vote is open for at least 72h and is closing ~ on March 12, 2013, at 1:30pm GMT.

Many thanks in advance for reviewing,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] release Apache Commons-FileUpload 1.3 based on RC1

2013-03-09 Thread Simone Tripodi 
My own +1

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sat, Mar 9, 2013 at 2:32 PM, Simone Tripodi  wrote:
> Hi all,
>
> I've prepared the RC1 of  Apache Commons-FileUpload 1.3 so I am here
> to call for a vote:
>
> Release Notes:
>
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/RELEASE-NOTES.txt
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_RC1
>
> Site:
>
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/site/index.html
> (possible broken links will be fixed once site will be properly
> deployed)
>
> Binaries:
>
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/binaries
>
> Staging Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecommons-008/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> Vote is open for at least 72h and is closing ~ on March 12, 2013, at 1:30pm 
> GMT.
>
> Many thanks in advance for reviewing,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] release Apache Commons-FileUpload 1.3 based on RC1

2013-03-09 Thread Thomas Neidhart 
On 03/09/2013 02:32 PM, Simone Tripodi wrote:
> Hi all,
> 
> I've prepared the RC1 of  Apache Commons-FileUpload 1.3 so I am here
> to call for a vote:
> 
> Release Notes:
> 
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/RELEASE-NOTES.txt
> 
> Tag:
> 
> https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_RC1
> 
> Site:
> 
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/site/index.html
> (possible broken links will be fixed once site will be properly
> deployed)
> 
> Binaries:
> 
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/binaries
> 
> Staging Maven Artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-008/
> 
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because

there is a critical bug (FILEUPLOAD-212) which an attacker can exploit
(especially as the bug is open and visible to everybody).

The fix would be quite easy as the author already outlined: always use a
LimitedInputStream by default and do not blindly trust the
content-length value provided by the user.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] release Apache Commons-FileUpload 1.3 based on RC1

2013-03-09 Thread Simone Tripodi 
Hi Thomas,

The user proposed a solution - without a patch - that, in his opinion,
should work.
We do not have a testcase which proves the reported issue, which would
affect all past FileUpload releases.

So, my question (to everybody) is: could the resolution of that issue
postponed to 1.3.1 or it is a blocker for 1.3?
TIA,

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sat, Mar 9, 2013 at 2:51 PM, Thomas Neidhart
 wrote:
> On 03/09/2013 02:32 PM, Simone Tripodi wrote:
>> Hi all,
>>
>> I've prepared the RC1 of  Apache Commons-FileUpload 1.3 so I am here
>> to call for a vote:
>>
>> Release Notes:
>>
>> http://people.apache.org/builds/commons/fileupload/1.3/RC1/RELEASE-NOTES.txt
>>
>> Tag:
>>
>> https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_RC1
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/fileupload/1.3/RC1/site/index.html
>> (possible broken links will be fixed once site will be properly
>> deployed)
>>
>> Binaries:
>>
>> http://people.apache.org/builds/commons/fileupload/1.3/RC1/binaries
>>
>> Staging Maven Artifacts:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-008/
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>
> there is a critical bug (FILEUPLOAD-212) which an attacker can exploit
> (especially as the bug is open and visible to everybody).
>
> The fix would be quite easy as the author already outlined: always use a
> LimitedInputStream by default and do not blindly trust the
> content-length value provided by the user.
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] release Apache Commons-FileUpload 1.3 based on RC1

2013-03-09 Thread Thomas Neidhart 
On 03/09/2013 03:23 PM, Simone Tripodi wrote:
> Hi Thomas,
> 
> The user proposed a solution - without a patch - that, in his opinion,
> should work.
> We do not have a testcase which proves the reported issue, which would
> affect all past FileUpload releases.
> 
> So, my question (to everybody) is: could the resolution of that issue
> postponed to 1.3.1 or it is a blocker for 1.3?
> TIA,

I do not think its the responsibility of the users that our provided
software is bug-free. If they do submit patches, great, if not, somebody
has to step in.

The more interesting question for me is if there is any specific reason
why this component has to be rushed out? Any important bugfix that
somebody needs? I ask, because I see more bugs which seem to be easy to
fix. Do you need help for that?

Thomas


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] release Apache Commons-FileUpload 1.3 based on RC1

2013-03-09 Thread sebb 
On 9 March 2013 14:31, Thomas Neidhart  wrote:
> On 03/09/2013 03:23 PM, Simone Tripodi wrote:
>> Hi Thomas,
>>
>> The user proposed a solution - without a patch - that, in his opinion,
>> should work.
>> We do not have a testcase which proves the reported issue, which would
>> affect all past FileUpload releases.
>>
>> So, my question (to everybody) is: could the resolution of that issue
>> postponed to 1.3.1 or it is a blocker for 1.3?
>> TIA,
>
> I do not think its the responsibility of the users that our provided
> software is bug-free. If they do submit patches, great, if not, somebody
> has to step in.

+1

> The more interesting question for me is if there is any specific reason
> why this component has to be rushed out? Any important bugfix that
> somebody needs? I ask, because I see more bugs which seem to be easy to
> fix. Do you need help for that?

+1, we ought to try and fix any critical bugs, even if they are not regressions.

> Thomas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] release Apache Commons-FileUpload 1.3 based on RC1

2013-03-09 Thread Simone Tripodi 
> I do not think its the responsibility of the users that our provided
> software is bug-free. If they do submit patches, great, if not, somebody
> has to step in.
>

I agree, but at least a patch with unit test that proves the issue,
would certainly help.

> The more interesting question for me is if there is any specific reason
> why this component has to be rushed out? Any important bugfix that
> somebody needs? I ask, because I see more bugs which seem to be easy to
> fix. Do you need help for that?

as always, when working with me, any help is much more than
appreciated and welcomed, so if you have spare time to help me on
squashing bugs on FileUpload, I can only be more than happy :)

I have anyway a silly questions: open bugs have never be blocking for
releases here, have I missed some discussion?

Just for the sake of not looking impatient, I notified in ML that I
was going to cut a RC, asking for feedbacks before I open the VOTE
thread - got no reply, I went ahead :)

TIA Thomas, looking forward to come back working with you!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Commons Wiki] Update of "CodeStyle" by BenediktRitter

2013-03-09 Thread Apache Wiki 
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "CodeStyle" page has been changed by BenediktRitter:
http://wiki.apache.org/commons/CodeStyle?action=diff&rev1=5&rev2=6

Comment:
Added guidelines regarding SVN keywords and @author tag, that were discussed on 
the ML lately.

  ||Imports: Order by groups: java, javax, org, com ||warning ||
  ||Imports: Order in alphabetical order with a group ||warning ||
  ||Indentation: (Java) use 4 spaces || warning ||
+ ||SVN keywords: $Date$ should not be used|| warning ||
  ||Indentation: (POM) prefer 4 spaces, allow 2, but be consistent within a 
file (1) || info ||
+ ||JavaDoc: @author Tag should not be used || info ||
  ||Add your rule here ||warning ||
  
  Notes:
  1. POMs tend to have quite deeply nested elements, and many elements can be 
long and awkward to wrap, so using 2 spaces is sometimes easier to read.
+ 2. The SVN $Date$ keyword should not be used, because it relies on the 
clients locale. Use the $Id$ keyword instead (see 
http://markmail.org/message/zx4ii6pq4iin2tol).
+ 3. Document authors in POM, not in source files (see 
http://markmail.org/message/k34w6gsx5iic45z2).
  

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Commons Wiki] Trivial Update of "CodeStyle" by BenediktRitter

2013-03-09 Thread Apache Wiki 
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "CodeStyle" page has been changed by BenediktRitter:
http://wiki.apache.org/commons/CodeStyle?action=diff&rev1=6&rev2=7

Comment:
Let the wiki format ordered listing

  ||Add your rule here ||warning ||
  
  Notes:
- 1. POMs tend to have quite deeply nested elements, and many elements can be 
long and awkward to wrap, so using 2 spaces is sometimes easier to read.
+  1. POMs tend to have quite deeply nested elements, and many elements can be 
long and awkward to wrap, so using 2 spaces is sometimes easier to read.
- 2. The SVN $Date$ keyword should not be used, because it relies on the 
clients locale. Use the $Id$ keyword instead (see 
http://markmail.org/message/zx4ii6pq4iin2tol).
+  1. The SVN $Date$ keyword should not be used, because it relies on the 
clients locale. Use the $Id$ keyword instead (see 
http://markmail.org/message/zx4ii6pq4iin2tol).
- 3. Document authors in POM, not in source files (see 
http://markmail.org/message/k34w6gsx5iic45z2).
+  1. Document authors in POM, not in source files (see 
http://markmail.org/message/k34w6gsx5iic45z2).
  

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java

2013-03-09 Thread Benedikt Ritter 
2013/3/9 Christian Grobmeier 

> On Sat, Mar 9, 2013 at 10:00 AM, sebb  wrote:
> > On 9 March 2013 00:39, Ralph Goers  wrote:
> >> I'm not sure I understand what the big deal is.  Sebb vetoed a commit
> and identified exactly what needed to be changed for him to remove the
> veto.  If the requested change is made then all should be fine with the
> world again.  Sure, he could have said all the same words without the -1
> but then it wouldn't be evident that he expected the change to be made.
> >
> > Thanks.
> >
> > Yes, I agree that it was perhaps unnecessary for the -1, but we had
> > already agreed some while ago not to use $Date$ and I did not want to
> > see that creep back in again.
>
> This is a discussion which seems to come up from time to time, like
> the @author tag thing and so on.
> Should we start a Wiki page with that kind of decisions? I think it
> would be useful, esp for new people. I think Benedikt has asked for
> such kind of docs recently.
>

I have documented both, the use of SVN keywords and @author tags in the
wiki: http://wiki.apache.org/commons/CodeStyle.

Benedikt


>
> Cheers
> Christian
>
> >> Ralph
> >>
> >>
> >> On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
> >>
> >>>
> >>>
> >>> Niall Pemberton  wrote:
> >>>
>  On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas 
> wrote:
> >>>
> >>> 
> >>>
> > One of the primary responsibilities of a PMC member when voting on a
> > release is verifying what is being voted on against the tag.
>  Different
> > client locales and $Date$ combine to make every single source file
> > different from the tag requiring a manual check of the diff of every
> > file to do the verification check properly. Even with good diff
>  tooling
> > the verification process is a lot slower and can't be automated.
> 
>  Its not required for a release - although I would agree its a nice
>  thing to do.Spot check of the files is good enough to see if it has
>  been created from the tag
> >>>
> >>> I very strongly disagree. Any PMC member voting on a release should be
> >>> verifying every single file in the src tarball with the tag. There are
> >>> plenty of tools available that make this the work of a few seconds -
> >>> providing the files agree.
> >>>
>  - otherwise we trust our release managers.
> >>>
> >>> Not trusting the release managers is not the primary reason that PMC
> >>> members should be verifying the tarball agrees with the tag (although
> if
> >>> a release manager ever does do anything malicious it will catch that
> >>> to). The primary reason is to catch errors in build process or mistakes
> >>> made by the release manager. BeanUtils is likely simpler than Tomcat
> but
> >>> the sorts of things a full verification has caught has included:
> >>> - missing files (usually after some form of code re-org)
> >>> - extra files (IDE files, intermediate files, .svn/.git files,
> >>> build.properties etc)
> >>> - wrong line endings (Tomcat tries to use CRLF for zip and LF for
> tar.gz)
> >>> - local edits to the source files
> >>>
> >>> Some are minor but missing or edited files are clearly serious issues
> >>> that should cause the release to fail.
> >>>
>  BeanUtils has used the $Date$ keyword since 2005 and I cannot remember
>  it ever coming up in a release vote - so it hasn't stopped it being
>  released.
> >>>
> >>> If the release manager and the people checking the tarball all have the
> >>> same locale you won't see the issue.
> >>>
> >>> Mark
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter