commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [compress] Todos before release 1
Date Sun, 22 Mar 2009 15:09:52 GMT
Dennis Lundberg wrote:
> Siegfried Goeschl wrote:
>> Hi Christian,
>> if Dennis has no time I can help out during Hackathon - I owe him one or
>> two favours already for maven-related help
> If I can persuade my employer to let me go to ApacheCon, we could do it
> together :-)

Unfortunately I will not make it to ApacheCon this time.

>> Cheers,
>> Siegfried Goeschl
>> Christian Grobmeier wrote:
>>> Hi all,
>>> since everybody seems to agree to promoting compress I collected several todos.
>>> I would like to discuss what is necessary for release 1 and what is not.
>>> * Of course administrative stuff: vote compress to proper etc. I don't
>>> have a clue of that currently. Who of you feels responsible for
>>> kicking that off? :-) I don't want to cause any hectic, but I don't
>>> want to see compress sleeping again, sorry for pushing :-)
>>> * Gump: I don't see compress here:
>>> I guess compress should be included like the other components. I think
>>> this should go into Jira?
>>> * Stefan wrote: "I'd love to work on Zip64 support (archiving files >
>>> 2GB), but this can wait until 1.1.". Well, prio has allready been
>>> said, but I guess this would fit fine in Jira issue (Medium)
>>> * ChangeSet Support (SANDBOX-183): testcases and such are running. Its
>>> possible to write to Zip files. I would think this could go into a
>>> release, maybe as experimental. Stefan said he would like to see
>>> really stable code. We need to decide if it should dropped in or not.
>>> I guess this would be a modification in the pom.xml, if we decide not
>>> to include this feature. If experimental (would be my choice right
>>> now): is it enough to point this out with javadoc? However in any
>>> case, ChangeSet does resolve now S-183. It could have a follow up (for
>>> example renaming files), but basically i think 183 can be closed, when
>>> tagged as experimental.
>>> * sebb said:"I'd like to see some statements in the Javadoc about the
>>> intended thread safety or otherwise of the classes.". I would think we
>>> should include this as an Jira issue, so it won't get lost. This are
>>> that tasks: check about thread safety, fix thread hostile classes,
>>> document it in javadoc.
>>> * I said:"Improve maven site stuff, which is a bit outdated now." and
>>> Dennis offered his help with maven stuff. I think this should go into
>>> Jira.
>>> * CPIO implementation needs more testcases. I think this should go into Jira.
>>> Then of coursse we have a lots of issues/bugs.
>>> Policy [1] says: "Make sure that there are no major bugs in JIRA".
>>> This would mean we have to fix at least 9 issues.
>>> Blocker Issues:
>>> SANDBOX-284   	 TarArchiveEntry(File) now crashes on file system roots   	
>>> Major Issues:
>>> SANDBOX-183 	Compress should allow for writing to Zip Files 	
>>> SANDBOX-298 	BZip2CompressorInputStream.reportCRCError() does not
>>> report problems to user
>>> SANDBOX-282 	TAR formaT unspecified 	
>>> SANDBOX-286 	BZip2CompressorInputStream doesn't work if wrapped into
>>> InputStreamReader
>>> SANDBOX-293 	Make ZiparchiveInputStream support as much of the zip
>>> package as possible
>>> SANDBOX-280 	unable to extract a TAR file that contains an entry which
>>> is 10 GB in size
>>> SANDBOX-176 	Enable creation of tool-readable ZIP archives with file
>>> names containing non-ASCII characters
>>> SANDBOX-296 	Ar doesn't delete correct
>>> Minor Issues: 	
>>> SANDBOX-124 	[compress] bzip2 - implement flush() 	
>>> SANDBOX-297 	AbstractTestCase.createArchive method appears to use
>>> incorrect file size - cut and paste error?
>>> SANDBOX-299 	ArchiveStreamFactory.createArchiveInputStream() &
>>> createArchiveOutputStream() should throw Exception if archiverName is
>>> not recognised
>>> SANDBOX-295 	JarArchiveEntry does not populate manifestAttributes or
>>> certificates
>>> SANDBOX-294 	The field is never read locally
>>> I can help with 183, 298, 296, 297, 299, 284. For the other I would
>>> have to look more deeper since I am not an expert in compression
>>> algorithms, but there is a chance that I can help here too.
>>> Maybe we can lower down some prios to medium. I would see SANDBOX-282
>>> as such an issue. Changing to POSIX specs would be good, but this will
>>> be lots of work i think. This can slow down the development of
>>> compress. Related to 282 is SANDBOX-280 (obviously). I would lower
>>> this down in prio too and put it into the next release.
>>> Best,
>>> Christian
>>> [1]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message