Re: [compress] Todos before release 1
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-
Re: [compress] Todos before release 1
On 2009-03-17, Christian Grobmeier wrote: > it looks like all the world is meeting at the conference except myself :-) A pity. > However, I think developing at the hackathon is a quick development, Since I won't attend the hackathon (no time for a full week off), I don't expect there will be much coding going on around compress at all - not that I wanted to stop anybody else from hacking on compress, I'd just be surprised if it happened. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
Hi, it looks like all the world is meeting at the conference except myself :-) However, I think developing at the hackathon is a quick development, and I would like to kindly ask you to take make some edits at the wiki and let me know which tasks has been done. It would be frustrating to think on things which has allready been fixed at the hackathon :-) Thanks! Christian On Mon, Mar 16, 2009 at 1:52 PM, Jukka Zitting wrote: > Hi, > > On Fri, Mar 13, 2009 at 11:33 PM, Siegfried Goeschl > wrote: >> if Dennis has no time I can help out during Hackathon > > I'd be happy to help with any compress-related stuff on Tuesday during > the Hackathon. > > BR, > > Jukka Zitting > > - > 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
Re: [compress] Todos before release 1
Hi Stefan, good idea - cu on Wednesday ... Siegfried Goeschl Stefan Bodewig wrote: > On 2009-03-13, Siegfried Goeschl wrote: > > >> if Dennis has no time I can help out during Hackathon - I owe him one or >> two favours already for maven-related help >> > > I won't be there for the hackathon but arrive Wednesday. If you stay > around during the conference and could spare half an hour to bring me > up to speed WRT to mvn site maintenance and how it applies to commons > that would be great. > > Stefan > > - > 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
Re: [compress] Todos before release 1
On 2009-03-13, Siegfried Goeschl wrote: > if Dennis has no time I can help out during Hackathon - I owe him one or > two favours already for maven-related help I won't be there for the hackathon but arrive Wednesday. If you stay around during the conference and could spare half an hour to bring me up to speed WRT to mvn site maintenance and how it applies to commons that would be great. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
Hi, On Fri, Mar 13, 2009 at 11:33 PM, Siegfried Goeschl wrote: > if Dennis has no time I can help out during Hackathon I'd be happy to help with any compress-related stuff on Tuesday during the Hackathon. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
>> Its SANDBOX-302 now: https://issues.apache.org/jira/browse/SANDBOX-302 >> Medium isnt in the system, I tagged it minor now. > > Major is the new Medium :) It's the default, so everyone treats it as medium. Aaaah ok :-) I updated the prio now. Thanks Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
On Sat, Mar 14, 2009 at 4:12 PM, Christian Grobmeier wrote: >>> * Gump: I don't see compress here: >>> http://vmgump.apache.org/gump/public/apache-commons/index.html >> >> Because you are looking at the wrong place 8-) >> http://vmgump.apache.org/gump/public/commons-sandbox/index.html > > thanks, that helped :-) > > > >>> * 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) >> I know I won't be able to work oon it in March, so it shuldn't be in >> the 1.0 time frame. > > Its SANDBOX-302 now: https://issues.apache.org/jira/browse/SANDBOX-302 > Medium isnt in the system, I tagged it minor now. Major is the new Medium :) It's the default, so everyone treats it as medium. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
>> * Gump: I don't see compress here: >> http://vmgump.apache.org/gump/public/apache-commons/index.html > > Because you are looking at the wrong place 8-) > http://vmgump.apache.org/gump/public/commons-sandbox/index.html thanks, that helped :-) >> * 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) > I know I won't be able to work oon it in March, so it shuldn't be in > the 1.0 time frame. Its SANDBOX-302 now: https://issues.apache.org/jira/browse/SANDBOX-302 Medium isnt in the system, I tagged it minor now. Cheers - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
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 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-284TarArchiveEntry(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 > >
Re: [compress] Todos before release 1
> Btw - I've had a success organizing this kind of thing on a wiki page. > That worked very well for me with both Quartz work and Taglibs. Thanks Hen, this is a good idea. I have added an wiki page too: http://wiki.apache.org/commons/CompressRoadmap Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
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 :-) > 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 ---
Re: [compress] Todos before release 1
Btw - I've had a success organizing this kind of thing on a wiki page. That worked very well for me with both Quartz work and Taglibs. Hen On Wed, Mar 11, 2009 at 11:30 PM, 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
Re: [compress] Todos before release 1
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-284TarArchiveEntry(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
Re: [compress] Todos before release 1
On 2009-03-12, Christian Grobmeier wrote:
> Hi all,
> since everybody seems to agree to promoting compress I collected
> several todos.
I'm a bit swamped at ${work} right now, but hope to prepare a PROPOSAL
and start a formal vote tomorrow at latest.
> * Gump: I don't see compress here:
> http://vmgump.apache.org/gump/public/apache-commons/index.html
Because you are looking at the wrong place 8-)
http://vmgump.apache.org/gump/public/commons-sandbox/index.html
> I guess compress should be included like the other components.
Will be there once it has moved in svn, no need for 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)
I know I won't be able to work oon it in March, so it shuldn't be in
the 1.0 time frame.
> * 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.
Need to have a deeper look before I can comment.
> * 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.
+1
> * CPIO implementation needs more testcases. I think this should go
> into Jira.
Not sure whether we need a JIRA ticket for "add tests", but OK.
> 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.
well, it depends on us to change the severity as needed. If we agree
that something really is an enhancement, it shouldn't block a release.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
Hi > 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. not necessary if you keep an eye on it :-) >> * ChangeSet Support (SANDBOX-183): testcases and such are running. Its >> .. >> tagged as experimental. > > Do the ChangeSet changes impact on anything else? > Or are they purely add-ons that can be ignored? The changes are pure add ons - if you don't want it, you may not use it. They provide modification functions, if you don't use it users can program this themself. >> * 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 created it as SANDBOX-300. https://issues.apache.org/jira/browse/SANDBOX-300 Thanks, Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
On 12/03/2009, 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? 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscr
[compress] Todos before release 1
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
