commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: [compress] Todos before release 1
Date Sat, 14 Mar 2009 23:10:33 GMT
Thanks Siegfried!
Hopefully you met up, have some beer, and bring compress to fly with
that maven stuff :-)
Cheers

On Fri, Mar 13, 2009 at 11:33 PM, Siegfried Goeschl
<siegfried.goeschl@it20one.at> 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
>
> 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-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


Mime
View raw message