commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <e...@zusammenkunft.net>
Subject Re: [VFS] Release Preparations 2.1 (again)
Date Thu, 09 Apr 2015 20:41:20 GMT
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
dlmarion@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" <ecki@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 <dlmarion@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-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