Hello Dave, the Wiki page reflects my current progress. I am not aware of any blocker bugs (besides VFS-498), but I havent scanned for new ones I must admit.
What really needs to be done is to craft a compatibility-announcement justifying the Clirr report differences and maybe cleanup the checkstyle and JIRA report mess on the site. VFS-498 might not be a blocker, but then again unless the other work is done there is some time to fix it, anyway :) I also think we should merge the patches which have been come up in some of the bugs in the last few weeks. I am just not very deep into the FTP part of the code. Gruss Bernd Am Wed, 8 Apr 2015 15:12:08 +0000 (UTC) schrieb dlmar...@comcast.net: > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
