Bernd, Looking at the release state wiki page I noticed that some progress has been made since we last talked. Looking at the page, it appears that VFS-498 is the only issue called out for resolution before the release. In JIRA, there are several unresolved issues with a 2.1 fix version and VFS-498 does not have a fix version. Do you know if the other (not 498) unresolved issues are holding up the release? Is 498 really a blocker for 2.1? I'd be happy to fix the versions for these issues in JIRA, but I don't have the privs.
Dave ----- Original Message ----- From: "Bernd Eckenfels" <e...@zusammenkunft.net> To: "Commons Developers List" <dev@commons.apache.org> Sent: Wednesday, December 31, 2014 1:15:41 AM Subject: Re: [VFS] Release Preparations 2.1 (again) Hello, Thanks for looking into this. Let me reply inline (and prune the mail): Am Tue, 30 Dec 2014 12:03:20 -0500 schrieb <dlmar...@comcast.net>: > > a) check the src/changes/changes.xml: all action entries with bug > > numbers since the last release should be marked resolved (not > > closed - actually all bugs on the jira report should be "resolved") > > with fix version 2.1. Check which bugs are in the JIRA report with > > a resolution different from resolved (make it look clean and tidy). > > Check which bugs are resolved in jira, not mentioned in changes and > > should be announced as good/critical change. > > VFS-540 has commit comment from VFS-541. Hm, not sure VFS-540 is about commons logging, VFS-541 is about commons compress? At least in changes.xml and JIRA? > VFS-476 and VFS-540 are dupes, but both are listed in > changes.xml. I assume one should be marked as a dupe and removed from > changes.xml? Hm, 476 was pushing logging to 1.1.3 and 540 to 1.2. We could remove the older one (it will still be in the JIRA report) so the changes are reduced (however it is still a long list so I would keep the two steps and make a general "updated dependencies" summary line in the announcement. > VFS-457 is still open. Yes, I think I will keep it open for some more but we should have a TODO list for the release: https://wiki.apache.org/commons/VfsReleaseState > VFS-415 requires Java 1.6, > announcement.vm needs to be updated. I was unsure if this should be put into the .vm file (where some old specific text is placed currently) or actually be part of the release description in the changes.xml file. But I agree it needs to be made explicite (added to above wiki page) > VFS-371 to 391 fixVersion is > incorrect (is currently NightlyBuild) Thanks I added 2.1 and remove nighltyBuild for all (+401, 202 2.0:307,131) of them (in the future it might be a good idea to use nightly execlusively until the RC is cut. But for now I chose to harmonize all to 2.1 as this is the majority of resolved issues). > > b) check all open JIRA bugs if there are any with a trivial fix or > > a pending patch or a totally dangerous sounding description (i.e. > > blocker). > > I don't feel that I know enough about the other providers to know > what is trivial or dangerous. I did update VFS-530 for the HDFS > provider though. Yes, for the dependencies for providers there is a little conflict in staying current and in having too high (i.e. not widely used) minimum dependencies. Can you commont for hdfs, what is a widely used minimum dependency, what is the latest. Maybe we need to test and document what versions it actually runs with (different from the compile version). > > c) check out vfs2-project/trunk on various systems (with compiler > > zoo) and try to build it (including site goal). > > Linux x64: > 'mvn clean package' built successfully with jdk1.6.0_45, > jdk1.7.0_72, jdk1.8.0_25 ** > > ** includes VFS-530-4.patch changes Thanks. > > f) the hadoop equals fix should be tested against a real use > > (VFS-523) Can you comment on this? > > k) find out why "mvn -U -x clean site -P release,include-sandbox - > > DskipPGP=true" fails with a dist/checkstyle-supression.xml problem, > > report it as a bug and provide a patch (and provide a path) > > (something around ${vfs.parent} I guess. > > The instructions at > http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html > > might resolve the issue. It involves creating another module, want me > to take a crack at it? I have also seen thos, I feel a bit uneasy about increasing the complexity of this multi module build. So I would prefer if we can try to resolve it with a property (basedir/vfs.parent, similar). Could you maybe try this route first? Gruss Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
