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: >>> http://vmgump.apache.org/gump/public/apache-commons/index.html >>> 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 TarArchiveInputStream.in 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] http://wiki.apache.org/commons/CreatingReleases >>> >>> --------------------------------------------------------------------- >>> 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 >> >> > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
