You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2013/10/13 07:31:38 UTC
[VOTE] Release Commons Compress 1.6
Hi
since Compress 1.5 we've fixed a few bugs but most notably added
read-only support for LZMA standalone, uncompressed ARJ and full support
for 7z.
I have not created a RC website as the only difference to the current
website would be the download page and the version number - and I'd
immediately change the site after the release to include the release
date anyway.
Foo 1.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 3254)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
Details of changes since 1.5 are in the release notes:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
The tag is here:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
(svn revision 1531616)
Site:
http://commons.apache.org/compress/
Clirr Report (compared to 1.5):
http://commons.apache.org/compress/clirr-report.html
RAT Report:
http://commons.apache.org/compress/rat-report.html
KEYS:
http://www.apache.org/dist/commons/KEYS
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now, i.e. after 0530
GMT 16-October 2013 - given that I'll be traveling the second half of
this week I'd rather expect the release to happen next Saturday.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Gary Gregory <ga...@gmail.com>.
"Foo 1.2 RC1 is available for review" ? ;)
Gary
On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org> wrote:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
>
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 3254)
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>
> Details of changes since 1.5 are in the release notes:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> (svn revision 1531616)
>
> Site:
> http://commons.apache.org/compress/
>
> Clirr Report (compared to 1.5):
> http://commons.apache.org/compress/clirr-report.html
>
> RAT Report:
> http://commons.apache.org/compress/rat-report.html
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after 0530
> GMT 16-October 2013 - given that I'll be traveling the second half of
> this week I'd rather expect the release to happen next Saturday.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[compress] Clirr (was Re: [VOTE] Release Commons Compress 1.6)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-14, Oliver Heger wrote:
> Am 14.10.2013 06:11, schrieb Stefan Bodewig:
>> On 2013-10-13, Oliver Heger wrote:
>>> When I build the site locally, I get a different clirr report showing 9
>>> errors because some public methods have been made final.
>> Strange. Why would Clirr create different reports? We're supposed to
>> be using the same versions of Clirr, aren't we?
>> Can you make your Clirr reports available so we can evaluate whether we
>> should fix those additional errors in a second RC?
> I have no clue why Clirr produces different results for me, and the
> errors it reports look indeed a bit strange.
> I uploaded my results of mvn site:site (using JDK 1.7 - maybe this is
> the reason for the difference?) to [1]
> [1] http://people.apache.org/~oheger/compress-site/
Thanks!
For the site build I tend to use OpenJDK 7 - the release artifacts have
been built on a different machine than the site.
All "extra" errors are about the values method of enums. The code
hasn't changed, maybe your compiler creates final values methods in
enums while the one used to build 1.5 did not?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 14.10.2013 06:11, schrieb Stefan Bodewig:
> On 2013-10-13, Oliver Heger wrote:
>
>> The artifacts look good, the build works fine with Java 1.7 on Windows
>> 7. I tried to build with Java 1.5, but got:
>
>> Tests in error:
>
>> SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37->testSevenZArchiveCreati
>> on:59 ╗ OutOfMemory
>> XZTestCase.testXZCreation:44 ╗ OutOfMemory Java heap space
>
>> Tests run: 374, Failures: 0, Errors: 2, Skipped: 0
>
>> ISTR that I had similar problems with other [compress] releases, so I
>> don't consider this as blocking.
>
> I don't recall it, but XZ is pretty heavy on GC pressure. Given that
> our XZ implementation is a very thin layer on top of XZ for Java there
> wouldn't be anything we could do - apart from increasing the heap size
> for the tests - anyway.
>
>> The title in the release notes says "Apache Commons Compress 1.5 RELEASE
>> NOTES"; it refers to the old version. I think, this requires another RC.
>
> Ouch.
>
>> The RC was built using Java 1.6.0_27. Does this version already contain
>> the Javadoc security fix?
>
> The javadoc plugin used by the Commons Parent took care of it.
>
>> When I build the site locally, I get a different clirr report showing 9
>> errors because some public methods have been made final.
>
> Strange. Why would Clirr create different reports? We're supposed to
> be using the same versions of Clirr, aren't we?
>
> Can you make your Clirr reports available so we can evaluate whether we
> should fix those additional errors in a second RC?
I have no clue why Clirr produces different results for me, and the
errors it reports look indeed a bit strange. I uploaded my results of
mvn site:site (using JDK 1.7 - maybe this is the reason for the
difference?) to [1]
Oliver
[1] http://people.apache.org/~oheger/compress-site/
>
> Thanks
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-13, Oliver Heger wrote:
> The artifacts look good, the build works fine with Java 1.7 on Windows
> 7. I tried to build with Java 1.5, but got:
> Tests in error:
> SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37->testSevenZArchiveCreati
> on:59 ╗ OutOfMemory
> XZTestCase.testXZCreation:44 ╗ OutOfMemory Java heap space
> Tests run: 374, Failures: 0, Errors: 2, Skipped: 0
> ISTR that I had similar problems with other [compress] releases, so I
> don't consider this as blocking.
I don't recall it, but XZ is pretty heavy on GC pressure. Given that
our XZ implementation is a very thin layer on top of XZ for Java there
wouldn't be anything we could do - apart from increasing the heap size
for the tests - anyway.
> The title in the release notes says "Apache Commons Compress 1.5 RELEASE
> NOTES"; it refers to the old version. I think, this requires another RC.
Ouch.
> The RC was built using Java 1.6.0_27. Does this version already contain
> the Javadoc security fix?
The javadoc plugin used by the Commons Parent took care of it.
> When I build the site locally, I get a different clirr report showing 9
> errors because some public methods have been made final.
Strange. Why would Clirr create different reports? We're supposed to
be using the same versions of Clirr, aren't we?
Can you make your Clirr reports available so we can evaluate whether we
should fix those additional errors in a second RC?
Thanks
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Oliver Heger <ol...@oliver-heger.de>.
The artifacts look good, the build works fine with Java 1.7 on Windows
7. I tried to build with Java 1.5, but got:
Tests in error:
SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37->testSevenZArchiveCreati
on:59 ╗ OutOfMemory
XZTestCase.testXZCreation:44 ╗ OutOfMemory Java heap space
Tests run: 374, Failures: 0, Errors: 2, Skipped: 0
ISTR that I had similar problems with other [compress] releases, so I
don't consider this as blocking.
However, I found the following problems:
The title in the release notes says "Apache Commons Compress 1.5 RELEASE
NOTES"; it refers to the old version. I think, this requires another RC.
The RC was built using Java 1.6.0_27. Does this version already contain
the Javadoc security fix?
When I build the site locally, I get a different clirr report showing 9
errors because some public methods have been made final.
Oliver
Am 13.10.2013 07:31, schrieb Stefan Bodewig:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
>
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 3254)
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>
> Details of changes since 1.5 are in the release notes:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> (svn revision 1531616)
>
> Site:
> http://commons.apache.org/compress/
>
> Clirr Report (compared to 1.5):
> http://commons.apache.org/compress/clirr-report.html
>
> RAT Report:
> http://commons.apache.org/compress/rat-report.html
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after 0530
> GMT 16-October 2013 - given that I'll be traveling the second half of
> this week I'd rather expect the release to happen next Saturday.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-13, Gary Gregory wrote:
> +1
Thanks.
> BUT the following are not blockers but should be improved if another RC is cut:
> - Low (27%) code coverage for the new class
> https://commons.apache.org/proper/commons-compress/cobertura/org.apache.commons.compress.archivers.arj.ArjArchiveEntry.html
> - PMD violations in new code, for example ArjArchiveInputStream.
I'll look into that later, but I'll likely now cut a new RC for that.
> - The change report should have the date of the RC instead of "not
> released, yet".
Why? It is going to be changed to the date of the relase anyway.
> - Using the live site for the RC is a bad idea IMO because the source
> will have to be changed to update the version, for example "The
> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
> and who knows what else will have to be changed. This means that what
> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
> site.
I'll start a separate thread to discuss this to not clutter the vote
thread. IMHO the site is completely irrelevant for release votes.
> - Site overview page: I do not want to read a history lesson ('The
> code in this component has many origins:') first, please tell me how
> to use the software first, then at the bottom, I can read about
> history.
> - Site overview page: too much redundant information (should be
> collapsed into one place):
> - Status (1st line): The current release is 1.5.
> - Documentation (1st line): Commons Compress 1.5 requires Java 5.
> - Releases (1st line): The latest version v1.5, is Java5 compatible
> - Add a "What's new in 1.6" section instead of burying the
> information in the middle of the text: "As of Commons Compress 1.6
> support for the dump and arj formats is read-only".
The main page - and in fact all of the Compress site - hasn't really
changed in three or four years. I agree it could use a major overhaul
but that's really nothing I see my strength in - this should be driven
by other people.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Site Builds and Release Votes
Posted by Phil Steitz <ph...@gmail.com>.
On 10/13/13 11:51 AM, Henri Yandell wrote:
> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe <Lu...@free.fr>wrote:
>
>> Le 13/10/2013 17:35, Stefan Bodewig a écrit :
>>> Hi all
>>>
>>> in the recent release vote for Compress Gary and I had very different
>>> opinions on the importance of the site build for release candidates.
>>>
>>> On 2013-10-13, Gary Gregory wrote:
>>>
>>>> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org>
>> wrote:
>>>>> I have not created a RC website as the only difference to the current
>>>>> website would be the download page and the version number - and I'd
>>>>> immediately change the site after the release to include the release
>>>>> date anyway.
>>>> - Using the live site for the RC is a bad idea IMO because the source
>>>> will have to be changed to update the version, for example "The
>>>> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
>>>> and who knows what else will have to be changed. This means that what
>>>> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
>>>> site.
>>> To me creating the site is one of the completely unnecessary steps to
>>> perform when cutting a release candidate. Building and uploading the
>>> site takes something > 15 minutes to me. So far I have never published
>>> the RC site when the RC was accepted but rather created a new site build
>>> that contained the release date, updated the changes report with a
>>> placeholder for the next release and so on.
>>>
>>> We can - and should - update the site outside of any release anyway, so
>>> to me the site content is completely irrelevant when I evaluate
>>> releases.
>>>
>>> I'll admit that this mirrors my suspicion that nobody looks at the site
>>> build contained in the binary release anyway. People use their
>>> dependency manager of choice and the online docs in my experience.
>>>
>>> How do others think about the release candidate site build?
>> I agree the site build is orthogonal to release.
>> The main thing we release is source code. Then on top of that we add
>> some binaries, but it is already a by-product. The site itself is not
>> something we should consider to be in the scope of the release.
>>
>>
> Agreed - the site build as a whole is for informative purposes during a
> vote. If there are any bugs in a site, they never block the release as they
> can be fixed out of band.
>
> The only items that should be blockers on the site build are those included
> in the distribution. I thought that was only the javadoc instead of the
> whole site? I'd definitely consider a bad javadoc to be something we should
> consider a new RC for, though it would depend on the severity. The cost of
> building a new RC is greater than fixing a typo in javadoc.
+1 - though I think we should be carefully reviewing the javadoc in
prep for releases and evaluation of RCs. The other exception to
this rule is when components ship user guides. These should be
updated for releases and should be evaluated as part of RC
evaluation. But I agree strongly with the view that updating the
public site can and should be viewed as a post-release activity. I
also don't think we should be shipping full site contents in binary
releases if somehow we have reverted to doing that. The
xdoc/apt/whatever should be tagged and included as part of source
release, but nits with it should not be release blockers, IMO.
Phil
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Site Builds and Release Votes
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 13.10.2013 20:51, schrieb Henri Yandell:
> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe <Lu...@free.fr>wrote:
>
>> Le 13/10/2013 17:35, Stefan Bodewig a écrit :
>>> Hi all
>>>
>>> in the recent release vote for Compress Gary and I had very different
>>> opinions on the importance of the site build for release candidates.
>>>
>>> On 2013-10-13, Gary Gregory wrote:
>>>
>>>> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org>
>> wrote:
>>>
>>>>> I have not created a RC website as the only difference to the current
>>>>> website would be the download page and the version number - and I'd
>>>>> immediately change the site after the release to include the release
>>>>> date anyway.
>>>
>>>> - Using the live site for the RC is a bad idea IMO because the source
>>>> will have to be changed to update the version, for example "The
>>>> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
>>>> and who knows what else will have to be changed. This means that what
>>>> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
>>>> site.
>>>
>>> To me creating the site is one of the completely unnecessary steps to
>>> perform when cutting a release candidate. Building and uploading the
>>> site takes something > 15 minutes to me. So far I have never published
>>> the RC site when the RC was accepted but rather created a new site build
>>> that contained the release date, updated the changes report with a
>>> placeholder for the next release and so on.
>>>
>>> We can - and should - update the site outside of any release anyway, so
>>> to me the site content is completely irrelevant when I evaluate
>>> releases.
>>>
>>> I'll admit that this mirrors my suspicion that nobody looks at the site
>>> build contained in the binary release anyway. People use their
>>> dependency manager of choice and the online docs in my experience.
>>>
>>> How do others think about the release candidate site build?
>>
>> I agree the site build is orthogonal to release.
>> The main thing we release is source code. Then on top of that we add
>> some binaries, but it is already a by-product. The site itself is not
>> something we should consider to be in the scope of the release.
>>
>>
> Agreed - the site build as a whole is for informative purposes during a
> vote. If there are any bugs in a site, they never block the release as they
> can be fixed out of band.
>
> The only items that should be blockers on the site build are those included
> in the distribution. I thought that was only the javadoc instead of the
> whole site? I'd definitely consider a bad javadoc to be something we should
> consider a new RC for, though it would depend on the severity. The cost of
> building a new RC is greater than fixing a typo in javadoc.
>
> Hen
>
But shouldn't the site at least be in sync with a new release regarding
stuff like descriptions of new features, updated user guides, etc.?
It is part of the release process to deploy the site. So it should not
be too much additional effort to prepare this for an RC.
I remember that in past we also had problems with sites that were
updated during development. Then we received bug reports because
features advertised in the documentation were not available in the
released version. So I cannot agree to the statement that a site update
can be done at any time.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Site Builds and Release Votes
Posted by sebb <se...@gmail.com>.
On 13 October 2013 20:26, Benedikt Ritter <br...@apache.org> wrote:
> The problem I'm seeing with deploying the side as needed is, that the
> JavaDoc report will the so latest trunk and not the latest released API. In
> [LANG] we have the link to the latest realese JavaDoc. Compress for example
> has no such link. So a redeploy (for example to add some more
> documentation) will override the JavaDoc report. This may confuse users.
> In other words: if the site build and deploy is decoupled from releases,
> there should be a link to the JavaDoc of the latest release.
+1
I think the site should reflect the current release(s).
That does not mean it cannot be updated post-release, e.g. to correct
errors / improve the documentation.
But it's very confusing to have a site that contains documentation for
code that has not been released.
What we do on the JMeter project is to create an SVN branch for the
documentation.
Any necessary changes are applied to the branch (and trunk if
relevant) and the site regenerated from the branch.
> Benedikt
>
>
> 2013/10/13 Henri Yandell <fl...@gmail.com>
>
>> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe <Luc.Maisonobe@free.fr
>> >wrote:
>>
>> > Le 13/10/2013 17:35, Stefan Bodewig a écrit :
>> > > Hi all
>> > >
>> > > in the recent release vote for Compress Gary and I had very different
>> > > opinions on the importance of the site build for release candidates.
>> > >
>> > > On 2013-10-13, Gary Gregory wrote:
>> > >
>> > >> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org>
>> > wrote:
>> > >
>> > >>> I have not created a RC website as the only difference to the current
>> > >>> website would be the download page and the version number - and I'd
>> > >>> immediately change the site after the release to include the release
>> > >>> date anyway.
>> > >
>> > >> - Using the live site for the RC is a bad idea IMO because the source
>> > >> will have to be changed to update the version, for example "The
>> > >> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
>> > >> and who knows what else will have to be changed. This means that what
>> > >> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
>> > >> site.
>> > >
>> > > To me creating the site is one of the completely unnecessary steps to
>> > > perform when cutting a release candidate. Building and uploading the
>> > > site takes something > 15 minutes to me. So far I have never published
>> > > the RC site when the RC was accepted but rather created a new site
>> build
>> > > that contained the release date, updated the changes report with a
>> > > placeholder for the next release and so on.
>> > >
>> > > We can - and should - update the site outside of any release anyway, so
>> > > to me the site content is completely irrelevant when I evaluate
>> > > releases.
>> > >
>> > > I'll admit that this mirrors my suspicion that nobody looks at the site
>> > > build contained in the binary release anyway. People use their
>> > > dependency manager of choice and the online docs in my experience.
>> > >
>> > > How do others think about the release candidate site build?
>> >
>> > I agree the site build is orthogonal to release.
>> > The main thing we release is source code. Then on top of that we add
>> > some binaries, but it is already a by-product. The site itself is not
>> > something we should consider to be in the scope of the release.
>> >
>> >
>> Agreed - the site build as a whole is for informative purposes during a
>> vote. If there are any bugs in a site, they never block the release as they
>> can be fixed out of band.
>>
>> The only items that should be blockers on the site build are those included
>> in the distribution. I thought that was only the javadoc instead of the
>> whole site? I'd definitely consider a bad javadoc to be something we should
>> consider a new RC for, though it would depend on the severity. The cost of
>> building a new RC is greater than fixing a typo in javadoc.
>>
>> Hen
>>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Site Builds and Release Votes
Posted by Benedikt Ritter <br...@apache.org>.
The problem I'm seeing with deploying the side as needed is, that the
JavaDoc report will the so latest trunk and not the latest released API. In
[LANG] we have the link to the latest realese JavaDoc. Compress for example
has no such link. So a redeploy (for example to add some more
documentation) will override the JavaDoc report. This may confuse users.
In other words: if the site build and deploy is decoupled from releases,
there should be a link to the JavaDoc of the latest release.
Benedikt
2013/10/13 Henri Yandell <fl...@gmail.com>
> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe <Luc.Maisonobe@free.fr
> >wrote:
>
> > Le 13/10/2013 17:35, Stefan Bodewig a écrit :
> > > Hi all
> > >
> > > in the recent release vote for Compress Gary and I had very different
> > > opinions on the importance of the site build for release candidates.
> > >
> > > On 2013-10-13, Gary Gregory wrote:
> > >
> > >> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org>
> > wrote:
> > >
> > >>> I have not created a RC website as the only difference to the current
> > >>> website would be the download page and the version number - and I'd
> > >>> immediately change the site after the release to include the release
> > >>> date anyway.
> > >
> > >> - Using the live site for the RC is a bad idea IMO because the source
> > >> will have to be changed to update the version, for example "The
> > >> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
> > >> and who knows what else will have to be changed. This means that what
> > >> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
> > >> site.
> > >
> > > To me creating the site is one of the completely unnecessary steps to
> > > perform when cutting a release candidate. Building and uploading the
> > > site takes something > 15 minutes to me. So far I have never published
> > > the RC site when the RC was accepted but rather created a new site
> build
> > > that contained the release date, updated the changes report with a
> > > placeholder for the next release and so on.
> > >
> > > We can - and should - update the site outside of any release anyway, so
> > > to me the site content is completely irrelevant when I evaluate
> > > releases.
> > >
> > > I'll admit that this mirrors my suspicion that nobody looks at the site
> > > build contained in the binary release anyway. People use their
> > > dependency manager of choice and the online docs in my experience.
> > >
> > > How do others think about the release candidate site build?
> >
> > I agree the site build is orthogonal to release.
> > The main thing we release is source code. Then on top of that we add
> > some binaries, but it is already a by-product. The site itself is not
> > something we should consider to be in the scope of the release.
> >
> >
> Agreed - the site build as a whole is for informative purposes during a
> vote. If there are any bugs in a site, they never block the release as they
> can be fixed out of band.
>
> The only items that should be blockers on the site build are those included
> in the distribution. I thought that was only the javadoc instead of the
> whole site? I'd definitely consider a bad javadoc to be something we should
> consider a new RC for, though it would depend on the severity. The cost of
> building a new RC is greater than fixing a typo in javadoc.
>
> Hen
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: Site Builds and Release Votes
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe <Lu...@free.fr>wrote:
> Le 13/10/2013 17:35, Stefan Bodewig a écrit :
> > Hi all
> >
> > in the recent release vote for Compress Gary and I had very different
> > opinions on the importance of the site build for release candidates.
> >
> > On 2013-10-13, Gary Gregory wrote:
> >
> >> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >
> >>> I have not created a RC website as the only difference to the current
> >>> website would be the download page and the version number - and I'd
> >>> immediately change the site after the release to include the release
> >>> date anyway.
> >
> >> - Using the live site for the RC is a bad idea IMO because the source
> >> will have to be changed to update the version, for example "The
> >> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
> >> and who knows what else will have to be changed. This means that what
> >> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
> >> site.
> >
> > To me creating the site is one of the completely unnecessary steps to
> > perform when cutting a release candidate. Building and uploading the
> > site takes something > 15 minutes to me. So far I have never published
> > the RC site when the RC was accepted but rather created a new site build
> > that contained the release date, updated the changes report with a
> > placeholder for the next release and so on.
> >
> > We can - and should - update the site outside of any release anyway, so
> > to me the site content is completely irrelevant when I evaluate
> > releases.
> >
> > I'll admit that this mirrors my suspicion that nobody looks at the site
> > build contained in the binary release anyway. People use their
> > dependency manager of choice and the online docs in my experience.
> >
> > How do others think about the release candidate site build?
>
> I agree the site build is orthogonal to release.
> The main thing we release is source code. Then on top of that we add
> some binaries, but it is already a by-product. The site itself is not
> something we should consider to be in the scope of the release.
>
>
Agreed - the site build as a whole is for informative purposes during a
vote. If there are any bugs in a site, they never block the release as they
can be fixed out of band.
The only items that should be blockers on the site build are those included
in the distribution. I thought that was only the javadoc instead of the
whole site? I'd definitely consider a bad javadoc to be something we should
consider a new RC for, though it would depend on the severity. The cost of
building a new RC is greater than fixing a typo in javadoc.
Hen
Re: Site Builds and Release Votes
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 13/10/2013 17:35, Stefan Bodewig a écrit :
> Hi all
>
> in the recent release vote for Compress Gary and I had very different
> opinions on the importance of the site build for release candidates.
>
> On 2013-10-13, Gary Gregory wrote:
>
>> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org> wrote:
>
>>> I have not created a RC website as the only difference to the current
>>> website would be the download page and the version number - and I'd
>>> immediately change the site after the release to include the release
>>> date anyway.
>
>> - Using the live site for the RC is a bad idea IMO because the source
>> will have to be changed to update the version, for example "The
>> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
>> and who knows what else will have to be changed. This means that what
>> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
>> site.
>
> To me creating the site is one of the completely unnecessary steps to
> perform when cutting a release candidate. Building and uploading the
> site takes something > 15 minutes to me. So far I have never published
> the RC site when the RC was accepted but rather created a new site build
> that contained the release date, updated the changes report with a
> placeholder for the next release and so on.
>
> We can - and should - update the site outside of any release anyway, so
> to me the site content is completely irrelevant when I evaluate
> releases.
>
> I'll admit that this mirrors my suspicion that nobody looks at the site
> build contained in the binary release anyway. People use their
> dependency manager of choice and the online docs in my experience.
>
> How do others think about the release candidate site build?
I agree the site build is orthogonal to release.
The main thing we release is source code. Then on top of that we add
some binaries, but it is already a by-product. The site itself is not
something we should consider to be in the scope of the release.
Luc
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Site Builds and Release Votes
Posted by Stefan Bodewig <bo...@apache.org>.
Hi all
in the recent release vote for Compress Gary and I had very different
opinions on the importance of the site build for release candidates.
On 2013-10-13, Gary Gregory wrote:
> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> I have not created a RC website as the only difference to the current
>> website would be the download page and the version number - and I'd
>> immediately change the site after the release to include the release
>> date anyway.
> - Using the live site for the RC is a bad idea IMO because the source
> will have to be changed to update the version, for example "The
> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
> and who knows what else will have to be changed. This means that what
> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
> site.
To me creating the site is one of the completely unnecessary steps to
perform when cutting a release candidate. Building and uploading the
site takes something > 15 minutes to me. So far I have never published
the RC site when the RC was accepted but rather created a new site build
that contained the release date, updated the changes report with a
placeholder for the next release and so on.
We can - and should - update the site outside of any release anyway, so
to me the site content is completely irrelevant when I evaluate
releases.
I'll admit that this mirrors my suspicion that nobody looks at the site
build contained in the binary release anyway. People use their
dependency manager of choice and the online docs in my experience.
How do others think about the release candidate site build?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Gary Gregory <ga...@gmail.com>.
+1
BUT the following are not blockers but should be improved if another RC is cut:
- Low (27%) code coverage for the new class
https://commons.apache.org/proper/commons-compress/cobertura/org.apache.commons.compress.archivers.arj.ArjArchiveEntry.html
- PMD violations in new code, for example ArjArchiveInputStream.
- The change report should have the date of the RC instead of "not
released, yet".
- Using the live site for the RC is a bad idea IMO because the source
will have to be changed to update the version, for example "The
current release is 1.5." and "Commons Compress 1.5 requires Java 5"
and who knows what else will have to be changed. This means that what
is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
site.
- Site overview page: I do not want to read a history lesson ('The
code in this component has many origins:') first, please tell me how
to use the software first, then at the bottom, I can read about
history.
- Site overview page: too much redundant information (should be
collapsed into one place):
- Status (1st line): The current release is 1.5.
- Documentation (1st line): Commons Compress 1.5 requires Java 5.
- Releases (1st line): The latest version v1.5, is Java5 compatible
And it is all about 1.5 instead of 1.6! See above.
- Add a "What's new in 1.6" section instead of burying the
information in the middle of the text: "As of Commons Compress 1.6
support for the dump and arj formats is read-only".
For me, I would do another RC but these are not hard core blockers.
Gary
On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bo...@apache.org> wrote:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
>
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 3254)
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>
> Details of changes since 1.5 are in the release notes:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> (svn revision 1531616)
>
> Site:
> http://commons.apache.org/compress/
>
> Clirr Report (compared to 1.5):
> http://commons.apache.org/compress/clirr-report.html
>
> RAT Report:
> http://commons.apache.org/compress/rat-report.html
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after 0530
> GMT 16-October 2013 - given that I'll be traveling the second half of
> this week I'd rather expect the release to happen next Saturday.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Emmanuel Bourg <eb...@apache.org>.
+1
Emmanuel Bourg
Le 13/10/2013 07:31, Stefan Bodewig a écrit :
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
>
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 3254)
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>
> Details of changes since 1.5 are in the release notes:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> (svn revision 1531616)
>
> Site:
> http://commons.apache.org/compress/
>
> Clirr Report (compared to 1.5):
> http://commons.apache.org/compress/clirr-report.html
>
> RAT Report:
> http://commons.apache.org/compress/rat-report.html
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after 0530
> GMT 16-October 2013 - given that I'll be traveling the second half of
> this week I'd rather expect the release to happen next Saturday.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [VOTE] Release Commons Compress 1.6
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Oct 13, 2013 at 7:38 PM, sebb <se...@gmail.com> wrote:
> On 13 October 2013 20:43, Phil Steitz <ph...@gmail.com> wrote:
>> On 10/13/13 12:39 PM, Phil Steitz wrote:
>>> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
>>>> Hi
>>>>
>>>> since Compress 1.5 we've fixed a few bugs but most notably added
>>>> read-only support for LZMA standalone, uncompressed ARJ and full support
>>>> for 7z.
>>>>
>>>> I have not created a RC website as the only difference to the current
>>>> website would be the download page and the version number - and I'd
>>>> immediately change the site after the release to include the release
>>>> date anyway.
>>>>
>>>> Foo 1.2 RC1 is available for review here:
>>>> https://dist.apache.org/repos/dist/dev/commons/compress/
>>>> (svn revision 3254)
>>>>
>>>> Maven artifacts are here:
>>>> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>>>>
>>>> Details of changes since 1.5 are in the release notes:
>>>> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>>>>
>>>> The tag is here:
>>>> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
>>>> (svn revision 1531616)
>>>>
>>>> Site:
>>>> http://commons.apache.org/compress/
>>>>
>>>> Clirr Report (compared to 1.5):
>>>> http://commons.apache.org/compress/clirr-report.html
>>>>
>>>> RAT Report:
>>>> http://commons.apache.org/compress/rat-report.html
>>>>
>>>> KEYS:
>>>> http://www.apache.org/dist/commons/KEYS
>>>>
>>>> Please review the release candidate and vote.
>>>> This vote will close no sooner that 72 hours from now, i.e. after 0530
>>>> GMT 16-October 2013 - given that I'll be traveling the second half of
>>>> this week I'd rather expect the release to happen next Saturday.
>>>>
>>>> [ ] +1 Release these artifacts
>>>> [ ] +0 OK, but...
>>>> [ ] -0 OK, but really should fix...
>>>> [ ] -1 I oppose this release because...
>>> +0
>>> Code builds fine for me on OSX 1.7.0_21-b12
>>> Jar, tarball contents, notice, license look fine.
>>> Sigs, hashes are good.
>>> +0 instead of +1 because the title on the release notes is incorrect
>>> - should be 1.6.
>>>
>>> One thing to verify: the manifest says the build was done using
>>> 1.6.0_27. Is that recent enough to include the fix for the javadoc
>>> XSS vulnerabilty?
>>
>> I am sorry. I forgot one other thing to verify. The clirr report
>> complains about dropping a field. Is this spurious / not really an
>> issue?
>
> Depends.
>
> It's certainly not strictly binary (or source) conpatible.
>
> But whether it is an issue depends on whether any 3rd party code is
> using it or not.
Which there is not way of knowing :( Are the dropped fields private?
Gary
>
>> Phil
>>>
>>> Phil
>>>
>>> Phil
>>>> Thanks!
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by sebb <se...@gmail.com>.
On 13 October 2013 20:43, Phil Steitz <ph...@gmail.com> wrote:
> On 10/13/13 12:39 PM, Phil Steitz wrote:
>> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
>>> Hi
>>>
>>> since Compress 1.5 we've fixed a few bugs but most notably added
>>> read-only support for LZMA standalone, uncompressed ARJ and full support
>>> for 7z.
>>>
>>> I have not created a RC website as the only difference to the current
>>> website would be the download page and the version number - and I'd
>>> immediately change the site after the release to include the release
>>> date anyway.
>>>
>>> Foo 1.2 RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/compress/
>>> (svn revision 3254)
>>>
>>> Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>>>
>>> Details of changes since 1.5 are in the release notes:
>>> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>>>
>>> The tag is here:
>>> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
>>> (svn revision 1531616)
>>>
>>> Site:
>>> http://commons.apache.org/compress/
>>>
>>> Clirr Report (compared to 1.5):
>>> http://commons.apache.org/compress/clirr-report.html
>>>
>>> RAT Report:
>>> http://commons.apache.org/compress/rat-report.html
>>>
>>> KEYS:
>>> http://www.apache.org/dist/commons/KEYS
>>>
>>> Please review the release candidate and vote.
>>> This vote will close no sooner that 72 hours from now, i.e. after 0530
>>> GMT 16-October 2013 - given that I'll be traveling the second half of
>>> this week I'd rather expect the release to happen next Saturday.
>>>
>>> [ ] +1 Release these artifacts
>>> [ ] +0 OK, but...
>>> [ ] -0 OK, but really should fix...
>>> [ ] -1 I oppose this release because...
>> +0
>> Code builds fine for me on OSX 1.7.0_21-b12
>> Jar, tarball contents, notice, license look fine.
>> Sigs, hashes are good.
>> +0 instead of +1 because the title on the release notes is incorrect
>> - should be 1.6.
>>
>> One thing to verify: the manifest says the build was done using
>> 1.6.0_27. Is that recent enough to include the fix for the javadoc
>> XSS vulnerabilty?
>
> I am sorry. I forgot one other thing to verify. The clirr report
> complains about dropping a field. Is this spurious / not really an
> issue?
Depends.
It's certainly not strictly binary (or source) conpatible.
But whether it is an issue depends on whether any 3rd party code is
using it or not.
> Phil
>>
>> Phil
>>
>> Phil
>>> Thanks!
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Phil Steitz <ph...@gmail.com>.
On 10/13/13 9:05 PM, Stefan Bodewig wrote:
> On 2013-10-13, Phil Steitz wrote:
>
>> I am sorry. I forgot one other thing to verify. The clirr report
>> complains about dropping a field. Is this spurious / not really an
>> issue?
> Ah yes, I should have talked about that.
>
> It is a protected field in the Tar*Stream classes which should have
> never been protected but was for hisorical reasons.
>
> When the change was made a few month ago we concluded it would be
> extremely unlikely that subclasses of said streams existed that used it,
> in particular since the type of the protected field was a package
> private class (TarBuffer).
>
> The implementation has been changed considerably and the TarBuffer class
> has even been removed - so if this change blocks the release the only
> mitigation will be to revert the changes completely. I'm fully prepared
> to do that, if necessary.
Thanks, Stefan. This is a good example of the "relaxing" of
backward compat requirements that I think we need to allow. I am +1
for allowing the break without major version bump / package-munging
in this case.
Phil
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-13, Phil Steitz wrote:
> I am sorry. I forgot one other thing to verify. The clirr report
> complains about dropping a field. Is this spurious / not really an
> issue?
Ah yes, I should have talked about that.
It is a protected field in the Tar*Stream classes which should have
never been protected but was for hisorical reasons.
When the change was made a few month ago we concluded it would be
extremely unlikely that subclasses of said streams existed that used it,
in particular since the type of the protected field was a package
private class (TarBuffer).
The implementation has been changed considerably and the TarBuffer class
has even been removed - so if this change blocks the release the only
mitigation will be to revert the changes completely. I'm fully prepared
to do that, if necessary.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Phil Steitz <ph...@gmail.com>.
On 10/13/13 12:39 PM, Phil Steitz wrote:
> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
>> Hi
>>
>> since Compress 1.5 we've fixed a few bugs but most notably added
>> read-only support for LZMA standalone, uncompressed ARJ and full support
>> for 7z.
>>
>> I have not created a RC website as the only difference to the current
>> website would be the download page and the version number - and I'd
>> immediately change the site after the release to include the release
>> date anyway.
>>
>> Foo 1.2 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/compress/
>> (svn revision 3254)
>>
>> Maven artifacts are here:
>> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>>
>> Details of changes since 1.5 are in the release notes:
>> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>>
>> The tag is here:
>> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
>> (svn revision 1531616)
>>
>> Site:
>> http://commons.apache.org/compress/
>>
>> Clirr Report (compared to 1.5):
>> http://commons.apache.org/compress/clirr-report.html
>>
>> RAT Report:
>> http://commons.apache.org/compress/rat-report.html
>>
>> KEYS:
>> http://www.apache.org/dist/commons/KEYS
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now, i.e. after 0530
>> GMT 16-October 2013 - given that I'll be traveling the second half of
>> this week I'd rather expect the release to happen next Saturday.
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
> +0
> Code builds fine for me on OSX 1.7.0_21-b12
> Jar, tarball contents, notice, license look fine.
> Sigs, hashes are good.
> +0 instead of +1 because the title on the release notes is incorrect
> - should be 1.6.
>
> One thing to verify: the manifest says the build was done using
> 1.6.0_27. Is that recent enough to include the fix for the javadoc
> XSS vulnerabilty?
I am sorry. I forgot one other thing to verify. The clirr report
complains about dropping a field. Is this spurious / not really an
issue?
Phil
>
> Phil
>
> Phil
>> Thanks!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Olivier Lamy <ol...@apache.org>.
--
Olivier
On Oct 14, 2013 6:39 AM, "Phil Steitz" <ph...@gmail.com> wrote:
>
> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
> > Hi
> >
> > since Compress 1.5 we've fixed a few bugs but most notably added
> > read-only support for LZMA standalone, uncompressed ARJ and full support
> > for 7z.
> >
> > I have not created a RC website as the only difference to the current
> > website would be the download page and the version number - and I'd
> > immediately change the site after the release to include the release
> > date anyway.
> >
> > Foo 1.2 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/compress/
> > (svn revision 3254)
> >
> > Maven artifacts are here:
> >
https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
> >
> > Details of changes since 1.5 are in the release notes:
> >
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
> >
> > The tag is here:
> >
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> > (svn revision 1531616)
> >
> > Site:
> > http://commons.apache.org/compress/
> >
> > Clirr Report (compared to 1.5):
> > http://commons.apache.org/compress/clirr-report.html
> >
> > RAT Report:
> > http://commons.apache.org/compress/rat-report.html
> >
> > KEYS:
> > http://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner that 72 hours from now, i.e. after 0530
> > GMT 16-October 2013 - given that I'll be traveling the second half of
> > this week I'd rather expect the release to happen next Saturday.
> >
> > [ ] +1 Release these artifacts
> > [ ] +0 OK, but...
> > [ ] -0 OK, but really should fix...
> > [ ] -1 I oppose this release because...
>
> +0
> Code builds fine for me on OSX 1.7.0_21-b12
> Jar, tarball contents, notice, license look fine.
> Sigs, hashes are good.
> +0 instead of +1 because the title on the release notes is incorrect
> - should be 1.6.
>
> One thing to verify: the manifest says the build was done using
> 1.6.0_27. Is that recent enough to include the fix for the javadoc
> XSS vulnerabilty?
Last maven javadoc plugin fix that without jdk requirement
>
> Phil
>
> Phil
> >
> > Thanks!
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [VOTE] Release Commons Compress 1.6
Posted by Phil Steitz <ph...@gmail.com>.
On 10/12/13 10:31 PM, Stefan Bodewig wrote:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
>
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 3254)
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>
> Details of changes since 1.5 are in the release notes:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> (svn revision 1531616)
>
> Site:
> http://commons.apache.org/compress/
>
> Clirr Report (compared to 1.5):
> http://commons.apache.org/compress/clirr-report.html
>
> RAT Report:
> http://commons.apache.org/compress/rat-report.html
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after 0530
> GMT 16-October 2013 - given that I'll be traveling the second half of
> this week I'd rather expect the release to happen next Saturday.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
+0
Code builds fine for me on OSX 1.7.0_21-b12
Jar, tarball contents, notice, license look fine.
Sigs, hashes are good.
+0 instead of +1 because the title on the release notes is incorrect
- should be 1.6.
One thing to verify: the manifest says the build was done using
1.6.0_27. Is that recent enough to include the fix for the javadoc
XSS vulnerabilty?
Phil
Phil
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Compress 1.6
Posted by Olivier Lamy <ol...@apache.org>.
+1
--
Olivier
On Oct 13, 2013 4:32 PM, "Stefan Bodewig" <bo...@apache.org> wrote:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
>
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 3254)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
>
> Details of changes since 1.5 are in the release notes:
>
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
>
> The tag is here:
>
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> (svn revision 1531616)
>
> Site:
> http://commons.apache.org/compress/
>
> Clirr Report (compared to 1.5):
> http://commons.apache.org/compress/clirr-report.html
>
> RAT Report:
> http://commons.apache.org/compress/rat-report.html
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after 0530
> GMT 16-October 2013 - given that I'll be traveling the second half of
> this week I'd rather expect the release to happen next Saturday.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [compress] Dave's Code Review (was Re: [CANCELLED][VOTE] Release Commons Compress 1.6)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-15, Stefan Bodewig wrote:
> But we probably should store the password as a char[] anyway
s/char/byte/
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[compress] Dave's Code Review (was Re: [CANCELLED][VOTE] Release Commons Compress 1.6)
Posted by Stefan Bodewig <bo...@apache.org>.
Hi
I'm going to address Dave's three mails in a single response
dam6923 . wrote:
> In SevenZFile.java
>
> Constructor...
> 1) Close file on exception instead of the current technique of keeping
> a "succeeded" flag.
This means I have to catch and rethrow the exception. I don't think I
like this better than the flag.
> 2) Move setting the password to the last line of the constructor so
> that it isn't stored if an exception is thrown at any point.
As the code stands this won't work as readHeaders needs the password
field. But we probably should store the password as a char[] anyway and
clear it when done - I'll change that before cutting the next release.
> General...
> 1) I see a few instances of
> if (file != null) {
> try {
> file.close();
> } catch (IOException ignored) { // NOPMD
> }
> file = null;
> }
> Can we snag the the IoUtils close methods in this project?
yep, but after the 1.6 release.
> 2) The class JavaDoc comments are wrapped after about 50 characters..
> extend to 80?
It may look wierd, but does it hurt?
> 3) There's a 'leaked resource' warning on line 190. A
> ByteArrayInputStream is not being closed, which makes sense as closing
> it does nothing, but for completeness sake perhaps or to protect
> against a time that the input-source could change and then it really
> is leaking.
> 4) Non-standard logging. There are many logging statements in the
> code... perhaps delegate that to a known logging framework or remove
> it all entirely?
> 5) Line 870 - magic number
will fix before the release (and remove the logging).
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream#read()
>
> Current: count(ret == -1 ? -1 : 1);
> Change: count(ret == -1 ? 0 : 1);
doesn't make a difference if you look at count's implementation. Will
change it anyway.
> org.apache.commons.compress.archivers.ar.ArArchiveInputStream#getNextArEntry()
>
> The code to "skip to the next available entry" looks a bit inefficient
> because it reads one byte at a time in a loop. Consider using
> org.apache.commons.compress.utils.IOUtils.skip(InputStream, long)
>
> Consider using org.apache.commons.compress.utils.IOUtils.readFully(InputStream,
> byte[], int, int) on line 98 or else there may be an unnecessary
> exception thrown.
>
> In fact, everywhere there is a read for header information, consider
> using "readFully". Right now, lines 118-124 are not doing readFully
> and the return value is not being checked.
I agree we could improve this, but I'd prefer to keep the changes before
cutting the next RC down to a minimum. So "yes, but for 1.7".
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCELLED][VOTE] Release Commons Compress 1.6
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Oct 14, 2013 at 12:03 PM, dam6923 . <da...@gmail.com> wrote:
> Just a couple of immediate thoughts (just starting to look things over...)
>
> In SevenZFile.java
>
> Constructor...
> 1) Close file on exception instead of the current technique of keeping
> a "succeeded" flag.
> 2) Move setting the password to the last line of the constructor so
> that it isn't stored if an exception is thrown at any point.
>
> General...
> 1) I see a few instances of
> if (file != null) {
> try {
> file.close();
> } catch (IOException ignored) { // NOPMD
> }
> file = null;
> }
> Can we snag the the IoUtils close methods in this project?
>
> 2) The class JavaDoc comments are wrapped after about 50 characters..
> extend to 80?
120 is common in active [commons] projects these days.
Gary
> 3) There's a 'leaked resource' warning on line 190. A
> ByteArrayInputStream is not being closed, which makes sense as closing
> it does nothing, but for completeness sake perhaps or to protect
> against a time that the input-source could change and then it really
> is leaking.
> 4) Non-standard logging. There are many logging statements in the
> code... perhaps delegate that to a known logging framework or remove
> it all entirely?
> 5) Line 870 - magic number
>
> Thanks,
> David
>
> On Mon, Oct 14, 2013 at 12:17 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> I think enough issues have been identified to warrant a second RC.
>>
>> I'll take care of the bad version number in the release notes as well as
>> the PMD warnings in the ARJ-Package. ArjArchiveEntry's test coverage
>> has already been increased in trunk.
>>
>> We should talk about the Clirr report further and come to a conclusion
>> what to do about the changes - if anything at all.
>>
>> For the site's contents I don't see myself working on it before a second
>> RC. Help is more than welcome (not only with the site, of course).
>>
>> Thanks to all who took the time to review the RC
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCELLED][VOTE] Release Commons Compress 1.6
Posted by "dam6923 ." <da...@gmail.com>.
Just a couple of immediate thoughts (just starting to look things over...)
In SevenZFile.java
Constructor...
1) Close file on exception instead of the current technique of keeping
a "succeeded" flag.
2) Move setting the password to the last line of the constructor so
that it isn't stored if an exception is thrown at any point.
General...
1) I see a few instances of
if (file != null) {
try {
file.close();
} catch (IOException ignored) { // NOPMD
}
file = null;
}
Can we snag the the IoUtils close methods in this project?
2) The class JavaDoc comments are wrapped after about 50 characters..
extend to 80?
3) There's a 'leaked resource' warning on line 190. A
ByteArrayInputStream is not being closed, which makes sense as closing
it does nothing, but for completeness sake perhaps or to protect
against a time that the input-source could change and then it really
is leaking.
4) Non-standard logging. There are many logging statements in the
code... perhaps delegate that to a known logging framework or remove
it all entirely?
5) Line 870 - magic number
Thanks,
David
On Mon, Oct 14, 2013 at 12:17 AM, Stefan Bodewig <bo...@apache.org> wrote:
> I think enough issues have been identified to warrant a second RC.
>
> I'll take care of the bad version number in the release notes as well as
> the PMD warnings in the ARJ-Package. ArjArchiveEntry's test coverage
> has already been increased in trunk.
>
> We should talk about the Clirr report further and come to a conclusion
> what to do about the changes - if anything at all.
>
> For the site's contents I don't see myself working on it before a second
> RC. Help is more than welcome (not only with the site, of course).
>
> Thanks to all who took the time to review the RC
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCELLED][VOTE] Release Commons Compress 1.6
Posted by "dam6923 ." <da...@gmail.com>.
org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream#read()
Current: count(ret == -1 ? -1 : 1);
Change: count(ret == -1 ? 0 : 1);
On Mon, Oct 14, 2013 at 12:17 AM, Stefan Bodewig <bo...@apache.org> wrote:
> I think enough issues have been identified to warrant a second RC.
>
> I'll take care of the bad version number in the release notes as well as
> the PMD warnings in the ARJ-Package. ArjArchiveEntry's test coverage
> has already been increased in trunk.
>
> We should talk about the Clirr report further and come to a conclusion
> what to do about the changes - if anything at all.
>
> For the site's contents I don't see myself working on it before a second
> RC. Help is more than welcome (not only with the site, of course).
>
> Thanks to all who took the time to review the RC
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCELLED][VOTE] Release Commons Compress 1.6
Posted by "dam6923 ." <da...@gmail.com>.
org.apache.commons.compress.archivers.ar.ArArchiveInputStream#getNextArEntry()
The code to "skip to the next available entry" looks a bit inefficient
because it reads one byte at a time in a loop. Consider using
org.apache.commons.compress.utils.IOUtils.skip(InputStream, long)
Consider using org.apache.commons.compress.utils.IOUtils.readFully(InputStream,
byte[], int, int) on line 98 or else there may be an unnecessary
exception thrown.
In fact, everywhere there is a read for header information, consider
using "readFully". Right now, lines 118-124 are not doing readFully
and the return value is not being checked.
On Mon, Oct 14, 2013 at 12:17 AM, Stefan Bodewig <bo...@apache.org> wrote:
> I think enough issues have been identified to warrant a second RC.
>
> I'll take care of the bad version number in the release notes as well as
> the PMD warnings in the ARJ-Package. ArjArchiveEntry's test coverage
> has already been increased in trunk.
>
> We should talk about the Clirr report further and come to a conclusion
> what to do about the changes - if anything at all.
>
> For the site's contents I don't see myself working on it before a second
> RC. Help is more than welcome (not only with the site, of course).
>
> Thanks to all who took the time to review the RC
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[CANCELLED][VOTE] Release Commons Compress 1.6
Posted by Stefan Bodewig <bo...@apache.org>.
I think enough issues have been identified to warrant a second RC.
I'll take care of the bad version number in the release notes as well as
the PMD warnings in the ARJ-Package. ArjArchiveEntry's test coverage
has already been increased in trunk.
We should talk about the Clirr report further and come to a conclusion
what to do about the changes - if anything at all.
For the site's contents I don't see myself working on it before a second
RC. Help is more than welcome (not only with the site, of course).
Thanks to all who took the time to review the RC
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org