[ALL] Do we need help?

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Do we need help?

Mark Thomas
On 01/12/2014 00:42, Bruno P. Kinoshita wrote:
> Hello Benedikt!
> I guess I'm being too cautious to commit or work on issues in other components :)

Don't worry about it. Everything at Commons is CTR (commit-then-review).
The worse thing that can happen is that you have to revert a commit.

It is much better to commit 10 different fixes and have to revert a
couple of them than not fixing anything at all.

Mark



> I'll slowly start working on [jelly] to port the changes made in Jenkins. But first will spend more time on [text], [functor] and [lang].
> Thanks!Bruno
>  
>       From: Benedikt Ritter <[hidden email]>
>  To: Commons Developers List <[hidden email]>; Bruno P. Kinoshita <[hidden email]>
>  Sent: Sunday, November 30, 2014 4:15 PM
>  Subject: Re: [ALL] Do we need help?
>    
> Hello Bruno
>
> 2014-11-30 0:31 GMT+01:00 Bruno P. Kinoshita <[hidden email]>:
>
> Hi Thomas!
> I use Jelly almost every week in Jenkins plug-ins. Talked about the forked repo they have in the project, and even told them I could spend some hours every week to fix the necessary issues.
> Even though it is possible to use Groovy in Jenkins views too now, there are so many existing plug-ins (that are used as basis for new plug-ins) that I find it very hard to see jelly removed from Jenkins.
> Would anyone be interested and have time to push a new release ? I could check what needed to be done in [jelly] and either update or add new issues.
> Bruno
>
>
> You always seem to be forgetting, that you're commons committer :-) If you feel like working on any component, just drop a mail on the ML and start work ;-) Other people will eventually join you.
> Benedikt
>
>  
>
>       From: Thomas Neidhart <[hidden email]>
>  To: Commons Developers List <[hidden email]>
>  Sent: Saturday, November 29, 2014 2:31 PM
>  Subject: Re: [ALL] Do we need help?
>
> On 11/29/2014 11:53 AM, Benedikt Ritter wrote:
>> Hi all,
>>
>> currently I feel really overwhelmed by the stuff I'd like to do at commons
>> and the little time I can spend for it. Here is an (incomplete) list of the
>> things I'd like to work on:
>
> Hi Benedikt,
>
>> - get a new release of the build plugin out of the door for auto creating
>> README.md and CONTRIBUTING.md
>> - Work on [VALIDATOR] and get a new release out of the door
>> - Work on [DBUTILS] and get a new release out of the door
>> - Push [lang] 3.4 out of the door
>> - Have a look at [compress] 2.0
>> - Backport important fixes from [collections] 4.0 to 3.x and create a last
>> service update
>> - work on [text]
>> - help releasing [imaging] 1.0
>> - Improve docs on how to get involved at commons
>> - Organize a logo contest for commons
>> - ... many more
>
> this sounds like you set your goals too high and are frustrated that you
> don't get all the things done. I guess this is a common scheme for
> ambitious/passionate people. Try to set more realistic goals and finish
> them before doing other / more things. Then you will get the positive
> feedback of achieving something and everything will be better.
>
>
>
>> I wonder how you feel about this. I have the feeling that a lot of people
>> ask us to fix stuff and release components but we don't really catch up
>> with this. This will give people the feeling that we are slow or we simply
>> don't care.
>> Whenever I see someone posting on JIRA "can you please fix this, we need
>> this in out application" and nobody is reacting, I feel tempted to jump
>> right in, even if I don't know the component (which adds another entry to
>> the list above).
>> I don't see a way how we can improve this. My feeling is, that we need more
>> committers. But then I have the comments of people I've talked to in my
>> ear: "to old school", "to difficult to get involved", "to slow development
>> process", "to unwelcoming community". So what do we do? Do we need help?
>>
>> I'm excited to hear your thoughts :-)
>
> yeah, this is a general problem of commons imho. There are too many
> components for a too small community as most of the original committers
> have long left.
>
> The only way out is to do what we tried a couple of months ago: move not
> maintained components to dormant, and keep the others alive with the
> existing people.
>
> Just one example: jelly is a nice thing and actually used within jenkins
> as the backbone html generator. But it is re-packaged within jenkins
> custom bugfixes as the last jelly release (1.0) was in 2005.
>
> Similar things apply for el or primitives.
>
> These components are long dead and there are very good alternatives
> available, so they should be abandoned. Cut off the dead branches to
> keep the tree alive.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[VFS] Release Preparations 2.1 (again)

Bernd Eckenfels
In reply to this post by Ralph Goers
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
<[hidden email]>:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

Alex
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
> <[hidden email]>:
>
>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
/--Regards, Alex/
Reply | Threaded
Open this post in threaded view
|

[VFS-180] merging? (was: [VFS] Release Preparations 2.1 (again))

Bernd Eckenfels
Am Wed, 03 Dec 2014 01:55:40 +0300
schrieb Alex <[hidden email]>:

> 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
> > <[hidden email]>:
> >
> >> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

garydgregory
In reply to this post by Bernd Eckenfels
On Tue, Dec 2, 2014 at 5:51 PM, Bernd Eckenfels <[hidden email]>
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
> <[hidden email]>:
>
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

Ralph Goers
>
> > 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

Reply | Threaded
Open this post in threaded view
|

AW: [VFS] Release Preparations 2.1 (again)

Bernd Eckenfels
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" <[hidden email]>
Gesendet: ‎03.‎12.‎2014 06:52
An: "Commons Developers List" <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

Bernd Eckenfels
In reply to this post by Ralph Goers
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 <[hidden email]>:

> >
> > > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

dlmarion
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" <[hidden email]>
To: "Commons Developers List" <[hidden email]>
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 <[hidden email]>:

> >
> > > 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: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

Ralph Goers
In reply to this post by Bernd Eckenfels
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 <[hidden email]> 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" <[hidden email]>
> Gesendet: ‎03.‎12.‎2014 06:52
> An: "Commons Developers List" <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

Bernd Eckenfels
In reply to this post by dlmarion
Hello,

Am Wed, 3 Dec 2014 13:42:51 +0000 (UTC)
schrieb [hidden email]:

> 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" <[hidden email]>
> To: "Commons Developers List" <[hidden email]>
> 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 <[hidden email]>:
>
> > >
> > > > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [VFS] Release Preparations 2.1 (again)

dlmarion


> -----Original Message-----
> From: Bernd Eckenfels [mailto:[hidden email]]
> Sent: Wednesday, December 03, 2014 6:28 PM
> To: Commons Developers List
> Cc: [hidden email]
> Subject: Re: [VFS] Release Preparations 2.1 (again)
>
> Hello,
>
> Am Wed, 3 Dec 2014 13:42:51 +0000 (UTC)
> schrieb [hidden email]:
>
> > 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" <[hidden email]>
> > To: "Commons Developers List" <[hidden email]>
> > 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 <[hidden email]>:
> >
> > > >
> > > > > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

Bernd Eckenfels
Hello,

Thanks for looking into this. Let me reply inline (and prune the mail):


Am Tue, 30 Dec 2014 12:03:20 -0500
schrieb <[hidden email]>:
> > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

dlmarion
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" <[hidden email]>
To: "Commons Developers List" <[hidden email]>
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 <[hidden email]>:
> > 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: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Release Preparations 2.1 (again)

Bernd Eckenfels
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
[hidden email]:

> 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" <[hidden email]>
> To: "Commons Developers List" <[hidden email]>
> 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 <[hidden email]>:
> > > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12