You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Bernd Eckenfels <ec...@zusammenkunft.net> on 2014/12/02 23:51:09 UTC
[VFS] Release Preparations 2.1 (again)
Hello,
ok, lets start another try to get VFS released. (and refresh my
memories who is volunteering for the RM? - I would do it but I think we
need a PMC at close hand).
Currently are 3 open blocker bugs, for one I have a patch pending, the
other two I am inclined to downgrade when nobody takes care of
them: They affect only a specific usecase, I am not sure if they are
regressions at all (I dont want to discourage anybody to solve them,
but I will not invest time before the release).
I am not so familiar with all of the Release Process, so I hope
somebody will help me, preferable from the PMC?
Ralph summarized, what he remebers is needed, I want to comment on
it:
Am Sat, 29 Nov 2014 19:54:42 -0700 schrieb Ralph Goers
<ra...@dslextreme.com>:
> I acted as release manager for 2.0. I did that because at the time I
> had a need for Commons VFS, I had a need to fix a bunch of stuff that
> didn’t work in 1.0, and I had the necessary privileges to do it.
> Since that time I have been focused on Log4j 2 almost completely with
> what little time I have. I have seen others commit fixes and
> enhancements and like you, I have been surprised that no one has
> bothered to perform a release. It should have happened a long time
> ago.
>
> One challenge to releasing VFS is that unlike most Commons projects,
> it is a multi-module project and it uses the Maven release plugin to
> perform a release. While this makes things a bit more complicated it
> still isn’t that hard to do.
Actually so much time has passed, that it does no longer look hard for
you. But when I look at the svn, I see no RC tags, a 2.0 tag which
does not fit the 1.0 naming conventions, I see 12 tries to actually
release the project (and quite a few rollbacks or tag copies). I would
not call this "not hard". But I do agree, your writeup helps, and it
should be possible (at least with PMC help). I tried to follow the
release tries in the archives, thats helpfull too.
> Unfortunately, I don’t believe I
> documented the release process but it should be similar to
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
> <http://wiki.apache.org/logging/Log4j2ReleaseGuide>, since I based
> the Log4j build and release process after VFS.
Before we do this, a couple of questions:
- how hard is it to delete tags from SVN and who can do that? I know
from experience with the release plugin that you typically need to
delete the tag multiple times to get things right. So it would be
good if somebody is available to do that on demand. And will we
actually tag each RC with the release version and modify this, or
will we have RC tags in the pom and
- do we maven-release RCs with the plugin? Is it ok if I cut the first
RC myself? Ralph used Nexus staging. Can I get access to one which
is set up for commons, or should a ask INFRA to prepare one?
- I haven't found requirements (besides commiter-owned) on the build
environment, do we use OpenJDK or OracleJDK. Is Windows acceptable?
(I think we are talking Java 6 here)
- is a 3kbit key fine for code signing?
- I would actually prefer to release before moving jcifs into core. If
somebody wants to see it released with 2.1, then please provide a
patch. I think the only solution would be a default-off profile with
an optional LPGL dinary nor source will pull in this dependency by
default.
- I would not care for Java 8 compile. Or actually: yes it compiles but
the site built might not completely work.
In parallel to that I will start a discussion on the Clirr report. I
did that in the past and I will make a spreadsheet so we can work
sharedly on marking things as reviewed or critical.
(the last time i tried to discuss it, I had uploaded:
http://people.apache.org/~ecki/commons-vfs/commons-vfs2/clirr-report.html
)
Greetings
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] Release Preparations 2.1 (again)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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" <ec...@zusammenkunft.net>
> To: "Commons Developers List" <de...@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 <dl...@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
Re: [VFS] Release Preparations 2.1 (again)
Posted by dl...@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" <ec...@zusammenkunft.net>
To: "Commons Developers List" <de...@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 <dl...@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
Re: [VFS] Release Preparations 2.1 (again)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
Thanks for looking into this. Let me reply inline (and prune the mail):
Am Tue, 30 Dec 2014 12:03:20 -0500
schrieb <dl...@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
RE: [VFS] Release Preparations 2.1 (again)
Posted by dl...@comcast.net.
> -----Original Message-----
> From: Bernd Eckenfels [mailto:ecki@zusammenkunft.net]
> Sent: Wednesday, December 03, 2014 6:28 PM
> To: Commons Developers List
> Cc: dlmarion@comcast.net
> Subject: Re: [VFS] Release Preparations 2.1 (again)
>
> Hello,
>
> Am Wed, 3 Dec 2014 13:42:51 +0000 (UTC)
> schrieb dlmarion@comcast.net:
>
> > I'm not sure I can help with tagging and deploying as I don't have the
> > permissions. However, I'm happy to help test the RC's, confirm MD5s,
> > and provide non-binding votes.
>
> There are a number of housekeeping stuff which needs or should be done.
> Anybody who likes to help, this would speed up the release. (make sure you
> post here the results, so we can confirm its done).
>
> 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.
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?
VFS-457 is still open.
VFS-415 requires Java 1.6, announcement.vm needs to be updated.
VFS-371 to 391 fixVersion is incorrect (is currently NightlyBuild)
>
> 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.
>
> 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
>
> d) run all test cases which have (Additional) external dependencies profiles
> (webdav, ftp, hdfs(?), ...) against different test servers.
>
> e) Try to use any existing VFS users or providers as binary or source together
> with the trunk.
>
> f) the hadoop equals fix should be tested against a real use (VFS-523)
>
> g) check the various site reports of trunk, if anything is critical (PMD,
> findbugs, Clirr)
>
> h) check if the 54 implicte excludes which are mentioned by RAT report
> (while building site) are actually aceptable.
>
> i) run "mvn clean verify" in a loop for a few hours and hunt-down
> (sporadic) test fails.
>
> j) try to build a working project/site for trunk and collect what things need to
> be done to get all links working* (this especially is a list of things like: "move
> core/target/site/*" to "target/site/commons-vfs2/*" (or if there is a way to
> get an aggregated site I dont know (and the current commited vfs2 site does
> neither:
> http://commons.apache.org/proper/commons-vfs/commons-
> vfs2/index.html).
>
> 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?
>
> l) not planning to work on vfs-xxxx before this release, but if
>
> m) find out if an easy fix exists to make the broken glassfish repository not
> show up in the effective pom (to avoid delay and warnings in site build, that
> annoyed me for quite some time).
>
> Gruss
> Bernd
>
>
>
> * Is this enough?
> mv core/target/site target/site/commons-vfs2 mv example/target/site
> target/site/commons-vfs2-example mv sandbox/target/site
> target/site/commons-vfs2-sandbox
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
> > ----- Original Message -----
> >
> > From: "Bernd Eckenfels" <ec...@zusammenkunft.net>
> > To: "Commons Developers List" <de...@commons.apache.org>
> > Sent: Wednesday, December 3, 2014 3:29:45 AM
> > Subject: Re: [VFS] Release Preparations 2.1 (again)
> >
> > Hello,
> >
> > I checked the release-plugin documentation and I cannot find a way to
> > specify different tags for the usage inside the prepared POM and the
> > Tag which should be used for actually tagging.
> >
> > I also think this is pretty uncommon, and I would go with using the
> > final release version tag (commons-vfs2-project-2.1 or
> > commons-vfs-2.1 or vfs-2.1 depending on the outcome of the
> > discusssion).
> >
> > As mentioned before, I am fine with having at least one non-final RC
> > produced using a RC tag and the commons.rc.version=RC1 specified. But
> > as soon as we think we can produce a result I woul run the release
> > plugin with the final tag.
> >
> > BTW: -P apache-release does not work with VFS as it fails the
> > source:single execution (missing assembly descriptor which is in dist/
> > for VFS). It seems to work with -Prelease, do we want to use this?
> >
> > Gruss
> > Bernd
> >
> > Am Tue, 2 Dec 2014 22:50:03 -0700
> > schrieb Ralph Goers <ra...@dslextreme.com>:
> >
> > > >
> > > > > Unfortunately, I don’t believe I documented the release process
> > > > > but it should be similar to
> > > > > http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>
> > > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I
> > > > > based the Log4j build and release process after VFS.
> > > >
> > > >
> > > > Before we do this, a couple of questions:
> > > >
> > > > - how hard is it to delete tags from SVN and who can do that?
> > > >
> > > > You should not delete tags from SVN. If you can commit, you can
> > > > manage tags and branches AFAIK. IMO, the process should be that we
> > > > VOTE on an RC tag, if the vote passes the RC tag is copied to a
> > > > release tag. If it fails, you try again with a new RC tag. The
> > > > tags live in SVN as a record of what we VOTEd on.
> > > >
> > >
> > > I recall that at the time of the 2.0 release the release plugin used
> > > the same version as the artifact for tagging, but I could be wrong.
> > > I seem to recall that now the tag does not have to match, so what
> > > Gary is suggesting should be doable.
> > >
> > > Ralph
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] Release Preparations 2.1 (again)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
Am Wed, 3 Dec 2014 13:42:51 +0000 (UTC)
schrieb dlmarion@comcast.net:
> I'm not sure I can help with tagging and deploying as I don't have
> the permissions. However, I'm happy to help test the RC's, confirm
> MD5s, and provide non-binding votes.
There are a number of housekeeping stuff which needs or should be done.
Anybody who likes to help, this would speed up the release. (make sure
you post here the results, so we can confirm its done).
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.
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).
c) check out vfs2-project/trunk on various systems (with compiler
zoo) and try to build it (including site goal).
d) run all test cases which have (Additional) external dependencies
profiles (webdav, ftp, hdfs(?), ...) against different test servers.
e) Try to use any existing VFS users or providers as binary or source
together with the trunk.
f) the hadoop equals fix should be tested against a real use (VFS-523)
g) check the various site reports of trunk, if anything is critical
(PMD, findbugs, Clirr)
h) check if the 54 implicte excludes which are mentioned by RAT
report (while building site) are actually aceptable.
i) run "mvn clean verify" in a loop for a few hours and hunt-down
(sporadic) test fails.
j) try to build a working project/site for trunk and collect what
things need to be done to get all links working* (this especially is a
list of things like: "move core/target/site/*" to
"target/site/commons-vfs2/*" (or if there is a way to get an
aggregated site I dont know (and the current commited vfs2 site does
neither:
http://commons.apache.org/proper/commons-vfs/commons-vfs2/index.html).
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.
l) not planning to work on vfs-xxxx before this release, but if
m) find out if an easy fix exists to make the broken glassfish
repository not show up in the effective pom (to avoid delay and
warnings in site build, that annoyed me for quite some time).
Gruss
Bernd
* Is this enough?
mv core/target/site target/site/commons-vfs2
mv example/target/site target/site/commons-vfs2-example
mv sandbox/target/site target/site/commons-vfs2-sandbox
>
> ----- Original Message -----
>
> From: "Bernd Eckenfels" <ec...@zusammenkunft.net>
> To: "Commons Developers List" <de...@commons.apache.org>
> Sent: Wednesday, December 3, 2014 3:29:45 AM
> Subject: Re: [VFS] Release Preparations 2.1 (again)
>
> Hello,
>
> I checked the release-plugin documentation and I cannot find a way to
> specify different tags for the usage inside the prepared POM and the
> Tag which should be used for actually tagging.
>
> I also think this is pretty uncommon, and I would go with using the
> final release version tag (commons-vfs2-project-2.1 or
> commons-vfs-2.1 or vfs-2.1 depending on the outcome of the
> discusssion).
>
> As mentioned before, I am fine with having at least one non-final RC
> produced using a RC tag and the commons.rc.version=RC1 specified. But
> as soon as we think we can produce a result I woul run the release
> plugin with the final tag.
>
> BTW: -P apache-release does not work with VFS as it fails the
> source:single execution (missing assembly descriptor which is in
> dist/ for VFS). It seems to work with -Prelease, do we want to use
> this?
>
> Gruss
> Bernd
>
> Am Tue, 2 Dec 2014 22:50:03 -0700
> schrieb Ralph Goers <ra...@dslextreme.com>:
>
> > >
> > > > Unfortunately, I don’t believe I
> > > > documented the release process but it should be similar to
> > > > http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>
> > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I
> > > > based the Log4j build and release process after VFS.
> > >
> > >
> > > Before we do this, a couple of questions:
> > >
> > > - how hard is it to delete tags from SVN and who can do that?
> > >
> > > You should not delete tags from SVN. If you can commit, you can
> > > manage tags and branches AFAIK. IMO, the process should be that
> > > we VOTE on an RC tag, if the vote passes the RC tag is copied to
> > > a release tag. If it fails, you try again with a new RC tag. The
> > > tags live in SVN as a record of what we VOTEd on.
> > >
> >
> > I recall that at the time of the 2.0 release the release plugin
> > used the same version as the artifact for tagging, but I could be
> > wrong. I seem to recall that now the tag does not have to match, so
> > what Gary is suggesting should be doable.
> >
> > Ralph
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [VFS] Release Preparations 2.1 (again)
Posted by dl...@comcast.net.
I'm not sure I can help with tagging and deploying as I don't have the permissions. However, I'm happy to help test the RC's, confirm MD5s, and provide non-binding votes.
----- Original Message -----
From: "Bernd Eckenfels" <ec...@zusammenkunft.net>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Wednesday, December 3, 2014 3:29:45 AM
Subject: Re: [VFS] Release Preparations 2.1 (again)
Hello,
I checked the release-plugin documentation and I cannot find a way to
specify different tags for the usage inside the prepared POM and the
Tag which should be used for actually tagging.
I also think this is pretty uncommon, and I would go with using the
final release version tag (commons-vfs2-project-2.1 or
commons-vfs-2.1 or vfs-2.1 depending on the outcome of the discusssion).
As mentioned before, I am fine with having at least one non-final RC
produced using a RC tag and the commons.rc.version=RC1 specified. But
as soon as we think we can produce a result I woul run the release
plugin with the final tag.
BTW: -P apache-release does not work with VFS as it fails the
source:single execution (missing assembly descriptor which is in dist/
for VFS). It seems to work with -Prelease, do we want to use this?
Gruss
Bernd
Am Tue, 2 Dec 2014 22:50:03 -0700
schrieb Ralph Goers <ra...@dslextreme.com>:
> >
> > > Unfortunately, I don’t believe I
> > > documented the release process but it should be similar to
> > > http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>
> > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I
> > > based the Log4j build and release process after VFS.
> >
> >
> > Before we do this, a couple of questions:
> >
> > - how hard is it to delete tags from SVN and who can do that?
> >
> > You should not delete tags from SVN. If you can commit, you can
> > manage tags and branches AFAIK. IMO, the process should be that we
> > VOTE on an RC tag, if the vote passes the RC tag is copied to a
> > release tag. If it fails, you try again with a new RC tag. The tags
> > live in SVN as a record of what we VOTEd on.
> >
>
> I recall that at the time of the 2.0 release the release plugin used
> the same version as the artifact for tagging, but I could be wrong.
> I seem to recall that now the tag does not have to match, so what
> Gary is suggesting should be doable.
>
> Ralph
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] Release Preparations 2.1 (again)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
I checked the release-plugin documentation and I cannot find a way to
specify different tags for the usage inside the prepared POM and the
Tag which should be used for actually tagging.
I also think this is pretty uncommon, and I would go with using the
final release version tag (commons-vfs2-project-2.1 or
commons-vfs-2.1 or vfs-2.1 depending on the outcome of the discusssion).
As mentioned before, I am fine with having at least one non-final RC
produced using a RC tag and the commons.rc.version=RC1 specified. But
as soon as we think we can produce a result I woul run the release
plugin with the final tag.
BTW: -P apache-release does not work with VFS as it fails the
source:single execution (missing assembly descriptor which is in dist/
for VFS). It seems to work with -Prelease, do we want to use this?
Gruss
Bernd
Am Tue, 2 Dec 2014 22:50:03 -0700
schrieb Ralph Goers <ra...@dslextreme.com>:
> >
> > > Unfortunately, I don’t believe I
> > > documented the release process but it should be similar to
> > > http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>
> > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I
> > > based the Log4j build and release process after VFS.
> >
> >
> > Before we do this, a couple of questions:
> >
> > - how hard is it to delete tags from SVN and who can do that?
> >
> > You should not delete tags from SVN. If you can commit, you can
> > manage tags and branches AFAIK. IMO, the process should be that we
> > VOTE on an RC tag, if the vote passes the RC tag is copied to a
> > release tag. If it fails, you try again with a new RC tag. The tags
> > live in SVN as a record of what we VOTEd on.
> >
>
> I recall that at the time of the 2.0 release the release plugin used
> the same version as the artifact for tagging, but I could be wrong.
> I seem to recall that now the tag does not have to match, so what
> Gary is suggesting should be doable.
>
> Ralph
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] Release Preparations 2.1 (again)
Posted by Ralph Goers <ra...@dslextreme.com>.
When VFS went from 1.0 to 2.0 the API was not compatible. This meant the package names had to change and the groupId/artifactId in the pom had to be different. If the new release is compatible with the prior release I would keep the naming conventions the same. Otherwise you run the risk of people mistakenly including both jars thinking they are different.
Ralph
> On Dec 2, 2014, at 11:36 PM, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
>
> Hello,
>
> I think the Problem is the tag the m-release-p uses to puts into the SCM URL for the released POM. I will try if this can be a non-existing Tag/Branch (however I do not agree that this is a good thing). I actually like the procedure in your log4j2 description where you would rename the failed tries to -rcN tags.
>
> However, for a first RC where it is expected to not be final (including a RC qualifier in the POM) I would release with an -rc1 tag. (should we use the new format if the 2.0 tag commons-vfs2-2.1-rc1 or go back to VFS2.1-rc1?
>
> Gruss
> Bernd
>
> --
> http://bernd.eckenfels.net
>
> ----- Ursprüngliche Nachricht -----
> Von: "Ralph Goers" <ra...@dslextreme.com>
> Gesendet: 03.12.2014 06:52
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: [VFS] Release Preparations 2.1 (again)
>
>>
>>> Unfortunately, I don’t believe I
>>> documented the release process but it should be similar to
>>> http://wiki.apache.org/logging/Log4j2ReleaseGuide <http://wiki.apache.org/logging/Log4j2ReleaseGuide>
>>> <http://wiki.apache.org/logging/Log4j2ReleaseGuide <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I based
>>> the Log4j build and release process after VFS.
>>
>>
>> Before we do this, a couple of questions:
>>
>> - how hard is it to delete tags from SVN and who can do that?
>>
>> You should not delete tags from SVN. If you can commit, you can manage tags and branches AFAIK. IMO, the process should be that we VOTE on an RC tag, if the vote passes the RC tag is copied to a release tag. If it fails, you try again with a new RC tag. The tags live in SVN as a record of what we VOTEd on.
>>
>
> I recall that at the time of the 2.0 release the release plugin used the same version as the artifact for tagging, but I could be wrong. I seem to recall that now the tag does not have to match, so what Gary is suggesting should be doable.
>
> Ralph
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
AW: [VFS] Release Preparations 2.1 (again)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
I think the Problem is the tag the m-release-p uses to puts into the SCM URL for the released POM. I will try if this can be a non-existing Tag/Branch (however I do not agree that this is a good thing). I actually like the procedure in your log4j2 description where you would rename the failed tries to -rcN tags.
However, for a first RC where it is expected to not be final (including a RC qualifier in the POM) I would release with an -rc1 tag. (should we use the new format if the 2.0 tag commons-vfs2-2.1-rc1 or go back to VFS2.1-rc1?
Gruss
Bernd
--
http://bernd.eckenfels.net
----- Ursprüngliche Nachricht -----
Von: "Ralph Goers" <ra...@dslextreme.com>
Gesendet: 03.12.2014 06:52
An: "Commons Developers List" <de...@commons.apache.org>
Betreff: Re: [VFS] Release Preparations 2.1 (again)
>
> > Unfortunately, I don’t believe I
> > documented the release process but it should be similar to
> > http://wiki.apache.org/logging/Log4j2ReleaseGuide <http://wiki.apache.org/logging/Log4j2ReleaseGuide>
> > <http://wiki.apache.org/logging/Log4j2ReleaseGuide <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I based
> > the Log4j build and release process after VFS.
>
>
> Before we do this, a couple of questions:
>
> - how hard is it to delete tags from SVN and who can do that?
>
> You should not delete tags from SVN. If you can commit, you can manage tags and branches AFAIK. IMO, the process should be that we VOTE on an RC tag, if the vote passes the RC tag is copied to a release tag. If it fails, you try again with a new RC tag. The tags live in SVN as a record of what we VOTEd on.
>
I recall that at the time of the 2.0 release the release plugin used the same version as the artifact for tagging, but I could be wrong. I seem to recall that now the tag does not have to match, so what Gary is suggesting should be doable.
Ralph
Re: [VFS] Release Preparations 2.1 (again)
Posted by Ralph Goers <ra...@dslextreme.com>.
>
> > Unfortunately, I don’t believe I
> > documented the release process but it should be similar to
> > http://wiki.apache.org/logging/Log4j2ReleaseGuide <http://wiki.apache.org/logging/Log4j2ReleaseGuide>
> > <http://wiki.apache.org/logging/Log4j2ReleaseGuide <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I based
> > the Log4j build and release process after VFS.
>
>
> Before we do this, a couple of questions:
>
> - how hard is it to delete tags from SVN and who can do that?
>
> You should not delete tags from SVN. If you can commit, you can manage tags and branches AFAIK. IMO, the process should be that we VOTE on an RC tag, if the vote passes the RC tag is copied to a release tag. If it fails, you try again with a new RC tag. The tags live in SVN as a record of what we VOTEd on.
>
I recall that at the time of the 2.0 release the release plugin used the same version as the artifact for tagging, but I could be wrong. I seem to recall that now the tag does not have to match, so what Gary is suggesting should be doable.
Ralph
Re: [VFS] Release Preparations 2.1 (again)
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Dec 2, 2014 at 5:51 PM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:
> Hello,
>
> ok, lets start another try to get VFS released. (and refresh my
> memories who is volunteering for the RM? - I would do it but I think we
> need a PMC at close hand).
>
> Currently are 3 open blocker bugs, for one I have a patch pending, the
> other two I am inclined to downgrade when nobody takes care of
> them: They affect only a specific usecase, I am not sure if they are
> regressions at all (I dont want to discourage anybody to solve them,
> but I will not invest time before the release).
>
> I am not so familiar with all of the Release Process, so I hope
> somebody will help me, preferable from the PMC?
>
>
> Ralph summarized, what he remebers is needed, I want to comment on
> it:
>
>
> Am Sat, 29 Nov 2014 19:54:42 -0700 schrieb Ralph Goers
> <ra...@dslextreme.com>:
>
> > I acted as release manager for 2.0. I did that because at the time I
> > had a need for Commons VFS, I had a need to fix a bunch of stuff that
> > didn’t work in 1.0, and I had the necessary privileges to do it.
> > Since that time I have been focused on Log4j 2 almost completely with
> > what little time I have. I have seen others commit fixes and
> > enhancements and like you, I have been surprised that no one has
> > bothered to perform a release. It should have happened a long time
> > ago.
> >
> > One challenge to releasing VFS is that unlike most Commons projects,
> > it is a multi-module project and it uses the Maven release plugin to
> > perform a release. While this makes things a bit more complicated it
> > still isn’t that hard to do.
>
> Actually so much time has passed, that it does no longer look hard for
> you. But when I look at the svn, I see no RC tags, a 2.0 tag which
> does not fit the 1.0 naming conventions, I see 12 tries to actually
> release the project (and quite a few rollbacks or tag copies). I would
> not call this "not hard". But I do agree, your writeup helps, and it
> should be possible (at least with PMC help). I tried to follow the
> release tries in the archives, thats helpfull too.
>
> > Unfortunately, I don’t believe I
> > documented the release process but it should be similar to
> > http://wiki.apache.org/logging/Log4j2ReleaseGuide
> > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>, since I based
> > the Log4j build and release process after VFS.
>
>
> Before we do this, a couple of questions:
>
> - how hard is it to delete tags from SVN and who can do that?
You should not delete tags from SVN. If you can commit, you can manage tags
and branches AFAIK. IMO, the process should be that we VOTE on an RC tag,
if the vote passes the RC tag is copied to a release tag. If it fails, you
try again with a new RC tag. The tags live in SVN as a record of what we
VOTEd on.
Gary
> I know
> from experience with the release plugin that you typically need to
> delete the tag multiple times to get things right. So it would be
> good if somebody is available to do that on demand. And will we
> actually tag each RC with the release version and modify this, or
> will we have RC tags in the pom and
>
> - do we maven-release RCs with the plugin? Is it ok if I cut the first
> RC myself? Ralph used Nexus staging. Can I get access to one which
> is set up for commons, or should a ask INFRA to prepare one?
>
> - I haven't found requirements (besides commiter-owned) on the build
> environment, do we use OpenJDK or OracleJDK. Is Windows acceptable?
> (I think we are talking Java 6 here)
>
> - is a 3kbit key fine for code signing?
>
> - I would actually prefer to release before moving jcifs into core. If
> somebody wants to see it released with 2.1, then please provide a
> patch. I think the only solution would be a default-off profile with
> an optional LPGL dinary nor source will pull in this dependency by
> default.
>
> - I would not care for Java 8 compile. Or actually: yes it compiles but
> the site built might not completely work.
>
>
> In parallel to that I will start a discussion on the Clirr report. I
> did that in the past and I will make a spreadsheet so we can work
> sharedly on marking things as reviewed or critical.
>
> (the last time i tried to discuss it, I had uploaded:
> http://people.apache.org/~ecki/commons-vfs/commons-vfs2/clirr-report.html
> )
>
>
> Greetings
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
[VFS-180] merging? (was: [VFS] Release Preparations 2.1 (again))
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am Wed, 03 Dec 2014 01:55:40 +0300
schrieb Alex <al...@zoho.com>:
> Is there a chance to get VFS-180 in 2.1?
Yes, of course. Looking through the patches I don't think it is
particular complicated (but also I see some things I would do
differently from 2012/04/24 14:04.)
Instead of
`name.getScheme().equals("webdav") ? "http" : "https"` I would more
factor in the provider type. Maybe forcefully use http or https based
on the provider only (or allow a auto detection somehow?).
The main thing open is I guess, it should really set up a WebDavS test
server and run built-in provider tests automatically.
Please review, is this actually doing certificate checking and
especially host name checking?
And I am not sure if 2 filename parsers are needed. Can we just use the
base Http(s)NameParsers?
Generally speaking: I guess there are many things wanting to be merged
and I would rather have soon a 2.2 (once we know how to do it) than
spending more time on the bugs.
Gruss
Bernd
>
> On 03/12/14 01:51, Bernd Eckenfels wrote:
> > Hello,
> >
> > ok, lets start another try to get VFS released. (and refresh my
> > memories who is volunteering for the RM? - I would do it but I
> > think we need a PMC at close hand).
> >
> > Currently are 3 open blocker bugs, for one I have a patch pending,
> > the other two I am inclined to downgrade when nobody takes care of
> > them: They affect only a specific usecase, I am not sure if they are
> > regressions at all (I dont want to discourage anybody to solve them,
> > but I will not invest time before the release).
> >
> > I am not so familiar with all of the Release Process, so I hope
> > somebody will help me, preferable from the PMC?
> >
> >
> > Ralph summarized, what he remebers is needed, I want to comment on
> > it:
> >
> >
> > Am Sat, 29 Nov 2014 19:54:42 -0700 schrieb Ralph Goers
> > <ra...@dslextreme.com>:
> >
> >> I acted as release manager for 2.0. I did that because at the
> >> time I had a need for Commons VFS, I had a need to fix a bunch of
> >> stuff that didn’t work in 1.0, and I had the necessary privileges
> >> to do it. Since that time I have been focused on Log4j 2 almost
> >> completely with what little time I have. I have seen others
> >> commit fixes and enhancements and like you, I have been surprised
> >> that no one has bothered to perform a release. It should have
> >> happened a long time ago.
> >>
> >> One challenge to releasing VFS is that unlike most Commons
> >> projects, it is a multi-module project and it uses the Maven
> >> release plugin to perform a release. While this makes things a bit
> >> more complicated it still isn’t that hard to do.
> > Actually so much time has passed, that it does no longer look hard
> > for you. But when I look at the svn, I see no RC tags, a 2.0 tag
> > which does not fit the 1.0 naming conventions, I see 12 tries to
> > actually release the project (and quite a few rollbacks or tag
> > copies). I would not call this "not hard". But I do agree, your
> > writeup helps, and it should be possible (at least with PMC help).
> > I tried to follow the release tries in the archives, thats helpfull
> > too.
> >
> >> Unfortunately, I don’t believe I
> >> documented the release process but it should be similar to
> >> http://wiki.apache.org/logging/Log4j2ReleaseGuide
> >> <http://wiki.apache.org/logging/Log4j2ReleaseGuide>, since I based
> >> the Log4j build and release process after VFS.
> >
> > Before we do this, a couple of questions:
> >
> > - how hard is it to delete tags from SVN and who can do that? I know
> > from experience with the release plugin that you typically need
> > to delete the tag multiple times to get things right. So it would be
> > good if somebody is available to do that on demand. And will we
> > actually tag each RC with the release version and modify this, or
> > will we have RC tags in the pom and
> >
> > - do we maven-release RCs with the plugin? Is it ok if I cut the
> > first RC myself? Ralph used Nexus staging. Can I get access to one
> > which is set up for commons, or should a ask INFRA to prepare one?
> >
> > - I haven't found requirements (besides commiter-owned) on the build
> > environment, do we use OpenJDK or OracleJDK. Is Windows
> > acceptable? (I think we are talking Java 6 here)
> >
> > - is a 3kbit key fine for code signing?
> >
> > - I would actually prefer to release before moving jcifs into core.
> > If somebody wants to see it released with 2.1, then please provide a
> > patch. I think the only solution would be a default-off profile
> > with an optional LPGL dinary nor source will pull in this
> > dependency by default.
> >
> > - I would not care for Java 8 compile. Or actually: yes it compiles
> > but the site built might not completely work.
> >
> >
> > In parallel to that I will start a discussion on the Clirr report. I
> > did that in the past and I will make a spreadsheet so we can work
> > sharedly on marking things as reviewed or critical.
> >
> > (the last time i tried to discuss it, I had uploaded:
> > http://people.apache.org/~ecki/commons-vfs/commons-vfs2/clirr-report.html
> > )
> >
> >
> > Greetings
> > 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
Re: [VFS] Release Preparations 2.1 (again)
Posted by Alex <al...@zoho.com>.
Is there a chance to get VFS-180 in 2.1?
On 03/12/14 01:51, Bernd Eckenfels wrote:
> Hello,
>
> ok, lets start another try to get VFS released. (and refresh my
> memories who is volunteering for the RM? - I would do it but I think we
> need a PMC at close hand).
>
> Currently are 3 open blocker bugs, for one I have a patch pending, the
> other two I am inclined to downgrade when nobody takes care of
> them: They affect only a specific usecase, I am not sure if they are
> regressions at all (I dont want to discourage anybody to solve them,
> but I will not invest time before the release).
>
> I am not so familiar with all of the Release Process, so I hope
> somebody will help me, preferable from the PMC?
>
>
> Ralph summarized, what he remebers is needed, I want to comment on
> it:
>
>
> Am Sat, 29 Nov 2014 19:54:42 -0700 schrieb Ralph Goers
> <ra...@dslextreme.com>:
>
>> I acted as release manager for 2.0. I did that because at the time I
>> had a need for Commons VFS, I had a need to fix a bunch of stuff that
>> didn’t work in 1.0, and I had the necessary privileges to do it.
>> Since that time I have been focused on Log4j 2 almost completely with
>> what little time I have. I have seen others commit fixes and
>> enhancements and like you, I have been surprised that no one has
>> bothered to perform a release. It should have happened a long time
>> ago.
>>
>> One challenge to releasing VFS is that unlike most Commons projects,
>> it is a multi-module project and it uses the Maven release plugin to
>> perform a release. While this makes things a bit more complicated it
>> still isn’t that hard to do.
> Actually so much time has passed, that it does no longer look hard for
> you. But when I look at the svn, I see no RC tags, a 2.0 tag which
> does not fit the 1.0 naming conventions, I see 12 tries to actually
> release the project (and quite a few rollbacks or tag copies). I would
> not call this "not hard". But I do agree, your writeup helps, and it
> should be possible (at least with PMC help). I tried to follow the
> release tries in the archives, thats helpfull too.
>
>> Unfortunately, I don’t believe I
>> documented the release process but it should be similar to
>> http://wiki.apache.org/logging/Log4j2ReleaseGuide
>> <http://wiki.apache.org/logging/Log4j2ReleaseGuide>, since I based
>> the Log4j build and release process after VFS.
>
> Before we do this, a couple of questions:
>
> - how hard is it to delete tags from SVN and who can do that? I know
> from experience with the release plugin that you typically need to
> delete the tag multiple times to get things right. So it would be
> good if somebody is available to do that on demand. And will we
> actually tag each RC with the release version and modify this, or
> will we have RC tags in the pom and
>
> - do we maven-release RCs with the plugin? Is it ok if I cut the first
> RC myself? Ralph used Nexus staging. Can I get access to one which
> is set up for commons, or should a ask INFRA to prepare one?
>
> - I haven't found requirements (besides commiter-owned) on the build
> environment, do we use OpenJDK or OracleJDK. Is Windows acceptable?
> (I think we are talking Java 6 here)
>
> - is a 3kbit key fine for code signing?
>
> - I would actually prefer to release before moving jcifs into core. If
> somebody wants to see it released with 2.1, then please provide a
> patch. I think the only solution would be a default-off profile with
> an optional LPGL dinary nor source will pull in this dependency by
> default.
>
> - I would not care for Java 8 compile. Or actually: yes it compiles but
> the site built might not completely work.
>
>
> In parallel to that I will start a discussion on the Clirr report. I
> did that in the past and I will make a spreadsheet so we can work
> sharedly on marking things as reviewed or critical.
>
> (the last time i tried to discuss it, I had uploaded:
> http://people.apache.org/~ecki/commons-vfs/commons-vfs2/clirr-report.html
> )
>
>
> Greetings
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
/--Regards, Alex/