commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [compress] Todos before release 1
Date Thu, 12 Mar 2009 10:00:19 GMT
On 12/03/2009, Christian Grobmeier <grobmeier@gmail.com> 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?

All committers have write access to Gump data files.

I can add it.

It can go into Compress JIRA issue if you want to track it, but AFAIK
Gump is not required.

>  * 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.

Do the ChangeSet changes impact on anything else?
Or are they purely add-ons that can be ignored?

>  * 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.

Agree we need JIRA issue.

But I think the sequence is
* decide/document thread-safety requirements.
* fix classes that violate them
* possibly relax requirements if some classes are difficult/expensive to fix.

>  * 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


Mime
View raw message