maven-wagon pull request: Fix for SFTP on windows machine

[nill14]

Github user nill14 closed the pull request at:

https://github.com/apache/maven-wagon/pull/2


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: git commit: Some updates to start working on a proper LICENCE/NOTICE

[sebb]

On 1 July 2013 21:29,   wrote:
> Updated Branches:
>   refs/heads/master 1a6bc6276 -> b4dc8931f
>
>
> Some updates to start working on a proper LICENCE/NOTICE
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/b4dc8931
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/b4dc8931
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/b4dc8931
>
> Branch: refs/heads/master
> Commit: b4dc8931f2cc7b56302df78c03a7db57211cd3a7
> Parents: 1a6bc62
> Author: Daniel Kulp 
> Authored: Mon Jul 1 16:28:28 2013 -0400
> Committer: Daniel Kulp 
> Committed: Mon Jul 1 16:28:28 2013 -0400
>
> --
>  apache-maven/LICENSE.txt| 202 ---
>  apache-maven/NOTICE.txt |  27 ---
>  apache-maven/pom.xml|   2 +-
>  .../main/appended-resources/META-INF/LICENSE.vm |  38 
>  apache-maven/src/main/assembly/bin.xml  |  10 +-
>  5 files changed, 47 insertions(+), 232 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/b4dc8931/apache-maven/LICENSE.txt
> --
> diff --git a/apache-maven/LICENSE.txt b/apache-maven/LICENSE.txt
> deleted file mode 100644
> index d645695..000
> --- a/apache-maven/LICENSE.txt
> +++ /dev/null
> @@ -1,202 +0,0 @@
> -
> - Apache License
> -   Version 2.0, January 2004
> -http://www.apache.org/licenses/
> -
> -   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
> -
> -   1. Definitions.
> -
> -  "License" shall mean the terms and conditions for use, reproduction,
> -  and distribution as defined by Sections 1 through 9 of this document.
> -
> -  "Licensor" shall mean the copyright owner or entity authorized by
> -  the copyright owner that is granting the License.
> -
> -  "Legal Entity" shall mean the union of the acting entity and all
> -  other entities that control, are controlled by, or are under common
> -  control with that entity. For the purposes of this definition,
> -  "control" means (i) the power, direct or indirect, to cause the
> -  direction or management of such entity, whether by contract or
> -  otherwise, or (ii) ownership of fifty percent (50%) or more of the
> -  outstanding shares, or (iii) beneficial ownership of such entity.
> -
> -  "You" (or "Your") shall mean an individual or Legal Entity
> -  exercising permissions granted by this License.
> -
> -  "Source" form shall mean the preferred form for making modifications,
> -  including but not limited to software source code, documentation
> -  source, and configuration files.
> -
> -  "Object" form shall mean any form resulting from mechanical
> -  transformation or translation of a Source form, including but
> -  not limited to compiled object code, generated documentation,
> -  and conversions to other media types.
> -
> -  "Work" shall mean the work of authorship, whether in Source or
> -  Object form, made available under the License, as indicated by a
> -  copyright notice that is included in or attached to the work
> -  (an example is provided in the Appendix below).
> -
> -  "Derivative Works" shall mean any work, whether in Source or Object
> -  form, that is based on (or derived from) the Work and for which the
> -  editorial revisions, annotations, elaborations, or other modifications
> -  represent, as a whole, an original work of authorship. For the purposes
> -  of this License, Derivative Works shall not include works that remain
> -  separable from, or merely link (or bind by name) to the interfaces of,
> -  the Work and Derivative Works thereof.
> -
> -  "Contribution" shall mean any work of authorship, including
> -  the original version of the Work and any modifications or additions
> -  to that Work or Derivative Works thereof, that is intentionally
> -  submitted to Licensor for inclusion in the Work by the copyright owner
> -  or by an individual or Legal Entity authorized to submit on behalf of
> -  the copyright owner. For the purposes of this definition, "submitted"
> -  means any form of electronic, verbal, or written communication sent
> -  to the Licensor or its representatives, including but not limited to
> -  communication on electronic mailing lists, source code control systems,
> -  and issue tracking systems that are managed by, or on behalf of, the
> -  Licensor for the purpose of discussing and improving the Work, but
> -  excluding communication that is conspicuously marked or otherwise
> -  designated in writing by the copyright owner 

maven-surefire pull request: Parallel Computer

[Tibor17]

GitHub user Tibor17 opened a pull request:

https://github.com/apache/maven-surefire/pull/26

Parallel Computer

This is an implementation of PC moved from my private repo to surefire 
project.  It will fix and improve the PC.
This impl can distinguish between JUnit classes (tests) and suites, so it 
will introduce more options in the element `parallel`:
+ classes
+ suites
+ methods
+ classesAndSuites
+ suitesAndMethods
+ classesAndMethods
+ all (same behavior as old both)
 
Additionally, we can have new params in plugin's config for the specified 
number of Threads imposed on:
+ suites
+ classes
+ methods
 
among of the existing configuration param for the total number of Threads.

Additionally the Threads can be shared or not shared between these 
categories. We should think about the names for the new configuration 
parameters.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Tibor17/maven-surefire master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/26.patch






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-surefire pull request: Parallel Computer

[Tibor17]

Github user Tibor17 closed the pull request at:

https://github.com/apache/maven-surefire/pull/25


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-surefire pull request: Proposed use of New JUnit ParallelComputer in ...

[Tibor17]

Github user Tibor17 closed the pull request at:

https://github.com/apache/maven-surefire/pull/17


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-plugins pull request: [MPMD-168] Add parameter to skip report generat...

[adangel]

Github user adangel closed the pull request at:

https://github.com/apache/maven-plugins/pull/11


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release process updates (try 2)

[Stephen Connolly]

On Monday, 1 July 2013, Baptiste MATHUS wrote:

> Guys, even if not convinced this is really useful,
> I suppose voting template could just be adjusted so that the sha1
> or svn revision be added in the VOTE thread, and then get back to code as
> usual?

+1

>
> As it is just a 5 seconds additional operation to be done by the RM, I
> think this is acceptable if this helps close this thread isn't it?
>
> My 2 cents.
>
> Cheers
>
>
> 2013/7/1 Fred Cooke >
>
> > Deleting and recreating a Git tag once published is an *extremely* stupid
> > thing to do, at least an order of magnitude more so than the same action
> in
> > SVN.  I sincerely hope that developers in this community would not engage
> > in such activities.
> >
> > Nevertheless, this thread isn't about that, it's about providing a
> specific
> > and reliable way to know what we're supposed to be looking at. It's
> about a
> > line or two in an email, nothing more. If that is too much to ask, then
> > something is seriously wrong here.
> >
> > On Mon, Jul 1, 2013 at 3:46 PM, Daniel Kulp >
> wrote:
> >
> > >
> > > +1  -  I agree with Chris.
> > >
> > > Besides, if something DOES change in the svn/git tag, we  get an email
> > > notification so we can immediately figure out what's going on.   In
> > > addition, if you compare what you are voting on to whatever is the
> latest
> > > version of the the tag, if there is any difference whatsoever in the
> > code,
> > > the reviewer should immediately figure out why.I really don't care
> > > about the exact revision number at all.   Whatever is the latest "tag"
> > > (head/whatever) is what's important as that's what will be held there
> > > forever once the vote passes.
> > >
> > > Dan
> > >
> > >
> > > On Jul 1, 2013, at 2:18 AM, Chris Graham 
> > > >
> wrote:
> > > > On Mon, Jul 1, 2013 at 4:20 AM, sebb >
> wrote:
> > > > Reminder: all this thread is just about is adding the following lines
> > > >> to vote e-mails:
> > > >>
> > > >> SVN Tag:
> > > >>
> > > >>
> > >
> >
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> > > >> (r1496317<
> > >
> >
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/(r1496317
> > > >
> > > >> )
> > > >>
> > > >>
> > > > I still find this redundant. Given that the tag will not change for
> the
> > > > time window of the vote, and that the tag has it's own revision no,
> and
> > > you
> > > > can derive the revision from the tag, so I see no need to quote the
> > > > revision no.
> > > >
> > > > In the event of a failed vote, the version/tag will be reused and it
> > will
> > > > have a new revision, which also will be derivable.
> > > >
> > > > In the event of a successful vote, the tag will remain permanently.
> > > >
> > > > Should anyone ever wish to trawl through the (svn) history, then you
> > will
> > > > still be able to see the intermediate/failed votes and history. And
> > you'd
> > > > also need the archives of this list to address why the vote failed
> etc.
> > > >
> > > > or whatever the equivalent is for Git (or any other SCM that may be
> in
> > > >> use at the time).
> > > >>
> > > >> Yes, others wil have their own requirements.
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org  - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>


-- 
Sent from my phone

Re: Release process updates (try 2)

[Baptiste MATHUS]

Guys, even if not convinced this is really useful,
I suppose voting template could just be adjusted so that the sha1
or svn revision be added in the VOTE thread, and then get back to code as
usual?

As it is just a 5 seconds additional operation to be done by the RM, I
think this is acceptable if this helps close this thread isn't it?

My 2 cents.

Cheers


2013/7/1 Fred Cooke 

> Deleting and recreating a Git tag once published is an *extremely* stupid
> thing to do, at least an order of magnitude more so than the same action in
> SVN.  I sincerely hope that developers in this community would not engage
> in such activities.
>
> Nevertheless, this thread isn't about that, it's about providing a specific
> and reliable way to know what we're supposed to be looking at. It's about a
> line or two in an email, nothing more. If that is too much to ask, then
> something is seriously wrong here.
>
> On Mon, Jul 1, 2013 at 3:46 PM, Daniel Kulp  wrote:
>
> >
> > +1  -  I agree with Chris.
> >
> > Besides, if something DOES change in the svn/git tag, we  get an email
> > notification so we can immediately figure out what's going on.   In
> > addition, if you compare what you are voting on to whatever is the latest
> > version of the the tag, if there is any difference whatsoever in the
> code,
> > the reviewer should immediately figure out why.I really don't care
> > about the exact revision number at all.   Whatever is the latest "tag"
> > (head/whatever) is what's important as that's what will be held there
> > forever once the vote passes.
> >
> > Dan
> >
> >
> > On Jul 1, 2013, at 2:18 AM, Chris Graham  wrote:
> > > On Mon, Jul 1, 2013 at 4:20 AM, sebb  wrote:
> > > Reminder: all this thread is just about is adding the following lines
> > >> to vote e-mails:
> > >>
> > >> SVN Tag:
> > >>
> > >>
> >
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> > >> (r1496317<
> >
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/(r1496317
> > >
> > >> )
> > >>
> > >>
> > > I still find this redundant. Given that the tag will not change for the
> > > time window of the vote, and that the tag has it's own revision no, and
> > you
> > > can derive the revision from the tag, so I see no need to quote the
> > > revision no.
> > >
> > > In the event of a failed vote, the version/tag will be reused and it
> will
> > > have a new revision, which also will be derivable.
> > >
> > > In the event of a successful vote, the tag will remain permanently.
> > >
> > > Should anyone ever wish to trawl through the (svn) history, then you
> will
> > > still be able to see the intermediate/failed votes and history. And
> you'd
> > > also need the archives of this list to address why the vote failed etc.
> > >
> > > or whatever the equivalent is for Git (or any other SCM that may be in
> > >> use at the time).
> > >>
> > >> Yes, others wil have their own requirements.
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Release process updates (try 2)

[Fred Cooke]

Deleting and recreating a Git tag once published is an *extremely* stupid
thing to do, at least an order of magnitude more so than the same action in
SVN.  I sincerely hope that developers in this community would not engage
in such activities.

Nevertheless, this thread isn't about that, it's about providing a specific
and reliable way to know what we're supposed to be looking at. It's about a
line or two in an email, nothing more. If that is too much to ask, then
something is seriously wrong here.

On Mon, Jul 1, 2013 at 3:46 PM, Daniel Kulp  wrote:

>
> +1  -  I agree with Chris.
>
> Besides, if something DOES change in the svn/git tag, we  get an email
> notification so we can immediately figure out what's going on.   In
> addition, if you compare what you are voting on to whatever is the latest
> version of the the tag, if there is any difference whatsoever in the code,
> the reviewer should immediately figure out why.I really don't care
> about the exact revision number at all.   Whatever is the latest "tag"
> (head/whatever) is what's important as that's what will be held there
> forever once the vote passes.
>
> Dan
>
>
> On Jul 1, 2013, at 2:18 AM, Chris Graham  wrote:
> > On Mon, Jul 1, 2013 at 4:20 AM, sebb  wrote:
> > Reminder: all this thread is just about is adding the following lines
> >> to vote e-mails:
> >>
> >> SVN Tag:
> >>
> >>
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> >> (r1496317<
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/(r1496317
> >
> >> )
> >>
> >>
> > I still find this redundant. Given that the tag will not change for the
> > time window of the vote, and that the tag has it's own revision no, and
> you
> > can derive the revision from the tag, so I see no need to quote the
> > revision no.
> >
> > In the event of a failed vote, the version/tag will be reused and it will
> > have a new revision, which also will be derivable.
> >
> > In the event of a successful vote, the tag will remain permanently.
> >
> > Should anyone ever wish to trawl through the (svn) history, then you will
> > still be able to see the intermediate/failed votes and history. And you'd
> > also need the archives of this list to address why the vote failed etc.
> >
> > or whatever the equivalent is for Git (or any other SCM that may be in
> >> use at the time).
> >>
> >> Yes, others wil have their own requirements.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Release process updates (try 2)

[Daniel Kulp]

+1  -  I agree with Chris.   

Besides, if something DOES change in the svn/git tag, we  get an email 
notification so we can immediately figure out what's going on.   In addition, 
if you compare what you are voting on to whatever is the latest version of the 
the tag, if there is any difference whatsoever in the code, the reviewer should 
immediately figure out why.I really don't care about the exact revision 
number at all.   Whatever is the latest "tag" (head/whatever) is what's 
important as that's what will be held there forever once the vote passes.

Dan


On Jul 1, 2013, at 2:18 AM, Chris Graham  wrote:
> On Mon, Jul 1, 2013 at 4:20 AM, sebb  wrote:
> Reminder: all this thread is just about is adding the following lines
>> to vote e-mails:
>> 
>> SVN Tag:
>> 
>> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
>> (r1496317
>> )
>> 
>> 
> I still find this redundant. Given that the tag will not change for the
> time window of the vote, and that the tag has it's own revision no, and you
> can derive the revision from the tag, so I see no need to quote the
> revision no.
> 
> In the event of a failed vote, the version/tag will be reused and it will
> have a new revision, which also will be derivable.
> 
> In the event of a successful vote, the tag will remain permanently.
> 
> Should anyone ever wish to trawl through the (svn) history, then you will
> still be able to see the intermediate/failed votes and history. And you'd
> also need the archives of this list to address why the vote failed etc.
> 
> or whatever the equivalent is for Git (or any other SCM that may be in
>> use at the time).
>> 
>> Yes, others wil have their own requirements.

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release process updates (try 2)

[Benson Margulies]

> >
> > So, if everyone here likes this idea, by all means let's do that. On the
> > other hand, if there is no consensus here, I wish that the Foundation
> had a
> > clearer venue for discussing global policies like this.
>
> I hope I don't have to argue that it is ASF policy to only release
> source files whose provenance is known?
>
>
Not with me.

Re: Release process updates (try 2)

[Chris Graham]

On Mon, Jul 1, 2013 at 7:14 PM, sebb  wrote:

> On 1 July 2013 07:18, Chris Graham  wrote:
> > On Mon, Jul 1, 2013 at 4:20 AM, sebb  wrote:
> >
> >> Reminder: all this thread is just about is adding the following lines
> >> to vote e-mails:
> >>
> >> SVN Tag:
> >>
> >>
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> >> (r1496317<
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/(r1496317
> >
> >> )
> >>
> >>
> > I still find this redundant. Given that the tag will not change for the
> > time window of the vote, and that the tag has it's own revision no, and
> you
> > can derive the revision from the tag, so I see no need to quote the
> > revision no.
>
> This is a lot of extra work for the reviewer, and very little for the RM.
>
> How do you figure that?

svn info gives you all that you need.



> Also as I have already written, it's vital for the vote e-mail to be
> open and provide all the necessary information to review the release
> properly.
> Otherwise the vote process is not transparent; it's not open to
> independent scrutiny.
>
> I'm pretty sure that anyone who is capable of performing an audit to the
level that you are proposing, will have the necessary skills to work out
where the tag is, given the artifactId and version.



> At the moment, most Maven VOTE e-mails do not even have the tag URL as
> standard, let alone the revision.
>
> It is probably not the intention, but the effect is that it is harder
> to perform a proper review.
> And the lack of the unique reference in the e-mail thread means that
> the required information is not recor
>
> > In the event of a failed vote, the version/tag will be reused and it will
> > have a new revision, which also will be derivable.
> >
> > In the event of a successful vote, the tag will remain permanently.
>
> This is not guaranteed by SVN.
> (Though IIRC it was true of CVS tags)
>
> The process around it and the svn history pretty much does.


> > Should anyone ever wish to trawl through the (svn) history, then you will
> > still be able to see the intermediate/failed votes and history. And you'd
> > also need the archives of this list to address why the vote failed etc.
>
> I was thinking more of a successful vote which was later challenged
> because of some source code that was found in the release.
>

Has this ever occurred?

And, even if it does, then the response would be to cut a release that
addresses any issues found.


> > or whatever the equivalent is for Git (or any other SCM that may be in
> >> use at the time).
> >>
> >> Yes, others wil have their own requirements.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Release process updates (try 2)

[sebb]

On 30 June 2013 23:33, sebb  wrote:
> On 30 June 2013 19:20, sebb  wrote:



>> Reminder: all this thread is just about is adding the following lines
>> to vote e-mails:
>>
>> SVN Tag:
>> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
>> (r1496317)
>
> An alternative is to use the URL from the commit message:
>
> URL: http://svn.apache.org/r1496317

In retrospect, I don't think that's a good idea.
It's shorter, but not actually any easier for the reviewer to use.
Also it relies on an external server to generate the required information.
This is not as future-proof as the tag+revision.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-scm pull request: SCM-681 : support whitespace for git operation

[jmecosta]

GitHub user jmecosta opened a pull request:

https://github.com/apache/maven-scm/pull/4

SCM-681 : support whitespace for git operation

Hi,

Can you please consider this patch to support whitespace operation in git

Thanks in advance
Br,
Jorge Costa

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jmecosta/maven-scm master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-scm/pull/4.patch






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release process updates (try 2)

[sebb]

On 1 July 2013 07:18, Chris Graham  wrote:
> On Mon, Jul 1, 2013 at 4:20 AM, sebb  wrote:
>
>> Reminder: all this thread is just about is adding the following lines
>> to vote e-mails:
>>
>> SVN Tag:
>>
>> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
>> (r1496317
>> )
>>
>>
> I still find this redundant. Given that the tag will not change for the
> time window of the vote, and that the tag has it's own revision no, and you
> can derive the revision from the tag, so I see no need to quote the
> revision no.

This is a lot of extra work for the reviewer, and very little for the RM.

Also as I have already written, it's vital for the vote e-mail to be
open and provide all the necessary information to review the release
properly.
Otherwise the vote process is not transparent; it's not open to
independent scrutiny.

At the moment, most Maven VOTE e-mails do not even have the tag URL as
standard, let alone the revision.

It is probably not the intention, but the effect is that it is harder
to perform a proper review.
And the lack of the unique reference in the e-mail thread means that
some required information is not properly recorded for posterity.

> In the event of a failed vote, the version/tag will be reused and it will
> have a new revision, which also will be derivable.
>
> In the event of a successful vote, the tag will remain permanently.

This is not guaranteed by SVN.
(Though IIRC it was true of CVS tags)

> Should anyone ever wish to trawl through the (svn) history, then you will
> still be able to see the intermediate/failed votes and history. And you'd
> also need the archives of this list to address why the vote failed etc.

I was thinking more of a successful vote which was later challenged
because of some source code that was found in the release.

> or whatever the equivalent is for Git (or any other SCM that may be in
>> use at the time).
>>
>> Yes, others wil have their own requirements.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release process updates (try 2)

[sebb]

On 1 July 2013 07:18, Chris Graham  wrote:
> On Mon, Jul 1, 2013 at 4:20 AM, sebb  wrote:
>
>> Reminder: all this thread is just about is adding the following lines
>> to vote e-mails:
>>
>> SVN Tag:
>>
>> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
>> (r1496317
>> )
>>
>>
> I still find this redundant. Given that the tag will not change for the
> time window of the vote, and that the tag has it's own revision no, and you
> can derive the revision from the tag, so I see no need to quote the
> revision no.

This is a lot of extra work for the reviewer, and very little for the RM.

Also as I have already written, it's vital for the vote e-mail to be
open and provide all the necessary information to review the release
properly.
Otherwise the vote process is not transparent; it's not open to
independent scrutiny.

At the moment, most Maven VOTE e-mails do not even have the tag URL as
standard, let alone the revision.

It is probably not the intention, but the effect is that it is harder
to perform a proper review.
And the lack of the unique reference in the e-mail thread means that
the required information is not recor

> In the event of a failed vote, the version/tag will be reused and it will
> have a new revision, which also will be derivable.
>
> In the event of a successful vote, the tag will remain permanently.

This is not guaranteed by SVN.
(Though IIRC it was true of CVS tags)

> Should anyone ever wish to trawl through the (svn) history, then you will
> still be able to see the intermediate/failed votes and history. And you'd
> also need the archives of this list to address why the vote failed etc.

I was thinking more of a successful vote which was later challenged
because of some source code that was found in the release.

> or whatever the equivalent is for Git (or any other SCM that may be in
>> use at the time).
>>
>> Yes, others wil have their own requirements.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release process updates

[sebb]

On 1 July 2013 08:17, Andreas Gudian  wrote:
>> 2013/6/26 sebb >:
>> > The mission of the ASF is to release software as source, and to ensure
>> > that the released source is available under the Apache Licence.
>>
>> Excuse me but I have always understand the ASF mission as building
>> communities around softwares.
>> Community over Code and not Process over Code.
>>
>> I believe (my personal opinion) we are here to make two communities
>> happy: dev community with easing their task to build and release good
>> software for the users community.

The software is not good if it is found to contain source code that
should not be there.

>>
>> With all of those emails, it's just a way to discourage people who
>> want to release software for their users.

I had no intention (or idea) that my simple request to add the URL and
revision to e-mails would create such a storm of resistance.

>> Yes too much (non useful) process tend/will discourage volunteers to
>> release something.

The change in process is minimal; a lot less work than even a single
reply to this thread.

>> My 0,02AUD
>> --
>> Olivier
>>
>
> +1, Oliver.
>
> Sure we need some kind of a legal basis and yes, we want to deliver as high
> a quality it is feasible for us. But in the end we're here to have fun
> coding stuff that makes a difference for the users.
> That means: keep the processes lean, as well as the discussion on
> improvements to the processes.
>
> Those were my 0,02€.
>
> Andreas

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Apache 3.1.0

[sebb]

On 1 July 2013 03:56, Barrie Treloar  wrote:
> On 1 July 2013 06:52, sebb  wrote:
>> Another problem: the NOTICE file contains the following spurious text:
>>
>>=
>>==  NOTICE file corresponding to the section 4 d of==
>>==  the Apache License, Version 2.0,   ==
>>==  in this case for the Apache Maven distribution.==
>>=
>>
>> This must not be present in NOTICE files, which are required to be as
>> short as possible (but no shorter).
>>
>> ASF NOTICE files must start as per the following example:
>>
>> 
>> Apache Maven
>> Copyright 2001-2013 The Apache Software Foundation
>>
>> This product includes software developed at
>> The Apache Software Foundation (http://www.apache.org/).
>> ==
>>
>> Note also that the phrase should be "developed at" not "developed by"
>> - the distinction is important.
>>
>> Furthermore, the NOTICE file refers to additonal 3rd party software,
>> but there don't appear to be any LICENSE files for the software.
>> The licenses should either be in LICENSE.txt or linked therefrom.
>
> From what I can tell we have been failing this since August 2010.
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=apache-maven/NOTICE.txt;hb=bfaf11090a212f8445f2ad929af8acce5a984bf0
>
> I can't find change history for
> http://www.apache.org/legal/src-headers.html so I don't know if we
> have been failing all the time, or since it was changed.

The leading text enclosed in == was never part of the NOTICE file;
AIUI it was added by Maven devs when producing the license plugin.

Until fairly recently there was one ASF page which incorrectly said
"developed by" instead of "developed at"; AFAIK there are now no
incorrect references.

> And I can see you've raised http://jira.codehaus.org/browse/MNG-5487
> to track this.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release process updates

[Andreas Gudian]

> 2013/6/26 sebb >:
> > The mission of the ASF is to release software as source, and to ensure
> > that the released source is available under the Apache Licence.
>
> Excuse me but I have always understand the ASF mission as building
> communities around softwares.
> Community over Code and not Process over Code.
>
> I believe (my personal opinion) we are here to make two communities
> happy: dev community with easing their task to build and release good
> software for the users community.
>
> With all of those emails, it's just a way to discourage people who
> want to release software for their users.
> Yes too much (non useful) process tend/will discourage volunteers to
> release something.
>
> My 0,02AUD
> --
> Olivier
>

+1, Oliver.

Sure we need some kind of a legal basis and yes, we want to deliver as high
a quality it is feasible for us. But in the end we're here to have fun
coding stuff that makes a difference for the users.
That means: keep the processes lean, as well as the discussion on
improvements to the processes.

Those were my 0,02€.

Andreas