On Apr 26, 2016, at 3:27 PM, Bernd Eckenfels<e...@zusammenkunft.net> wrote:
Hello,
see inline.
Am Tue, 26 Apr 2016 18:05:01 -0400
schrieb Josh Elser<els...@apache.org<mailto:els...@apache.org>>:
Thanks for the great details, Bernd. Some questions/comments:
I hadn't even stumbled across VFS-570 due to its lack of
fixVersion=2.1. Are there more that need to be correctly tagged which
could potentially block the release of 2.1?
I did not waste much time in setting/unsetting the fixversion. I
modified some severities and closed some. But the blocker bugs (the
ones I considered) are all closed.
You could do a mass change on the existing bugs, but I am sure that
causes some discussion and especially people setting the fields back to
their preferences (at least that happend a few times in the past).
I'm not sure I follow you about the concern of using
maven-release-plugin with a multi-module maven project. This works
just fine (@see other Apache maven projects I'm involved in). If
there are demons laying in wait, I can knock them out as I find them.
Well yes, I use the release plugin aswell (in fact I did a company
internal release of VFS 2.1 with it already). I think it was also used
for the 2.0 release. But there are some things (especially the tagging
of the SVN and the tag in the POM) which is currently not very
preferable in apache commons I think. I would not use it for a release
(especially as rolling back and revovering would be painful). But I
agreee with you, it should work.
Are there instructions on running clirr? I'm not familiar with the
tool (and I don't see any configuration in the top-level pom.xml).
You can run the "mvn -Psandbox clean site" build (possibly follwoed by
a site tst deploy). The clirr report is part of it. I had a site build
from the snapshot on people.apache.org<http://people.apache.org/>, but I havent
checked if/how the
new server would look like. So currently you need to run it locally.
Do you have the karma to make a 2.2 version on JIRA? That'd be a nice
help to start moving stuff out of 2.1 (as well as make sure things
sitting in Patch Available don't get forgotten).
Yes, seems like I can do it. I created 2.2.
I would lean towards
the side of only putting bug-fixes into a 2.1.1 and preferring
towards any new features/changes into a 2.2 (to closer follow the
definition of semver). We presently have 3 major and 1 minor version
unresolved for fixVersion=2.1 -- these where the issues I previously
referred to that I felt OK bumping out as well.
Gary -- "BC breakage" == base-class breakage? As in: the common
base-class for all of the VFS Providers has changed (and would
require changes from anyone downstream that has built their own)?
It refers to (binary) backward compatibility. For a client a new method
in an interface is a compatible change which fits into a minor update.
However when you have to implement a interface as a VFS provider you
wont be binary and source compatible. For most classes it is not a
problem since the mehtod is provided by the AbstractBaseClass for an
interface (but not all Interfaces have that and it was never mandatory
for an provider to use them).
I can try to start pounding on an initial RC in the evenings this
week. I'll be sure to reach out as I need some more help/karma ;)
Anything more needed from me?
Gruss
Bernd
Gary Gregory wrote:
Yes, there is a BC breakage for providers, is that grounds for a
package and Maven coordinate rename to vfs3?
Gary
On Tue, Apr 26, 2016 at 12:31 PM, Bernd
Eckenfels<e...@zusammenkunft.net> wrote:
Hello Josh,
I think a VFS 2.1 release would be cool and it is good that you
volunteer, so I dont object. My latest todo list is here:
https://wiki.apache.org/commons/VfsReleaseState
As you can see, I did plan to do the release and did quite some
work to get VFS into a releaseable state. But I am quite happy
that you want to step in as I havent had the time to do the
procedure yet.
And this is not the actual release procedure (which should be
doable as long as you do not try to use the release-plugin and be
careful about the multi-module+sandbox nature of VFS (as opposed
to other commons projects)). Also be carefull about branch and tag
namings (the SVN is a bit messy in this regard).
My main concern I am afraid I would not have enough capacity is
because of the Clirr report and a lot of partially incompatible
changes. Most of them only affect providers if they do not
properly use abstract base classes, but still the list of Clirr
violations is long and developers here have not yet voiced if they
would accept a RC with this situation (or not).
Anyway, I do agree that the current critical and blocker bugs are
important but should not stop the 2.1 release (especially if a
2.1.1 release aferwards is much faster to do.) It would be cool to
have VFS-570 (write suport for VFS, but even that could be
delivered with 2.1.1 - it might annoy the HDFS folks a bit)
So I can help you in case you need me to sponsor some changes (I
hope I have enough karma now).
We could even make a joined RC1, I am just not sure it wont open a
big chunk of additional work.
Gruss
Bernd
Am Tue, 26 Apr 2016 09:40:01 -0400
schrieb Josh Elser<els...@apache.org>:
Thanks Matt and Gary.
I do recall seeing the asf-wide note that my commit-bit also
applies to commons-*. Thanks for bringing that up. Specifically
though, I am only interested in cutting a release -- if we can
get a new release cut that we can use downstream, that increases
the likelihood that I will have more things to contribute back :)
I'll pull up the thread in the archives and get back to ya'll with
any questions I have after that.
- Josh
Matt Sicker wrote:
It's from the thread called "Whatever happened to commons-io
2.5?" A few people stepped up to give the necessary permissions
and committed his GPG key.
On 25 April 2016 at 17:10, Gary Gregory<garydgreg...@gmail.com>
wrote:
Hi,
Agreed, VFS 2.1 has been too long in the making. We can release
ASAP without fixing more bugs IMO. RERO and all.
As an Apache committer, your are also an Apache Commons
committer, so feel free to create JIRAs, fix bugs and so on.
There might be some karma issues with a non-PMC member
performing a release, and I think we just went through this
(sorry, I'm in settling in a new house, not much time to dig in
the ML archives).
Does anyone recall?
Gary
On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org>
wrote:
Hi all,
There are presently 171 resolved issues sitting in commons-vfs2
2.1-SNAPSHOT, with 4 outstanding (none of which look like
blockers to
me).
The lack of any release of commons-vfs2 in years has been a big
problem downstream. This past weekend, I was again annoyed by
bugs that have been fixed (but not release) which is spurring
me to take some action. There have been emails reaching back
as far as 2014 asking when the next
release
might be, not to mention the fact that vfs-2.0 was released in
2011 (!).
History aside, I'm reaching out today to:
1) See if anyone on the PMC has the cycles to volunteer as RM.
1a) If not, how can you empower me (or others) to make the
release on your behalf.
2) Understand, specifically, what (if any) roadblocks exist to
release this version.
Thanks.
- Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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<mailto:dev-unsubscr...@commons.apache.org>
For additional commands, e-mail:
dev-h...@commons.apache.org<mailto:dev-h...@commons.apache.org>
