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

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 (try 2)

[Chris Graham]

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.

Re: Release process updates (try 2)

[sebb]

On 30 June 2013 23:32, Benson Margulies  wrote:
> On the one hand, I think that, in many Apache communities, comparing the
> source release to the VCS is the exception and not the rule, and may never
> have happened, even once. (I think that there is at least an even chance
> that some crusty veteran of httpd will arrive in this thread and call me
> out on this, insisting that Sebb's view is and has always been the only
> right way, and some neuron in the back of my mind thinks it has seen some
> reference to a tool for comparing source release packages to svn.)
>
> However, I don't see anything _bad_ about supplying an unambiguous,
> immutable, reference to the VCS, and so it would be a good thing if Maven
> helped Apache projects achieve this, rather than make it harder.
>
> 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?

My point is that the only practical way to establish provenance of the
files in a source release is via the VCS/SCM.

The reason the VCS coords need to be in the vote mail message is to
allow a reviewer the opportunity to establish provenence.
This applies for the current vote, and any potential review that might
need to take place in the future.

>
>
>
> On Sun, Jun 30, 2013 at 4:56 PM, Fred Cooke  wrote:
>
>> >
>> > OK, so what is the Git command to download a copy of the sources that
>> >
>> are part of the hash?
>> >
>>
>> git checkout 
>>
>> Then observe the tree. You can also export an archive, though I don't
>> recall the exact command off the top of my hand.
>>
>>
>> > Don't I need to know something about the Git repo it comes from?
>> >
>>
>> Yes, the URL which would be pre-agreed. Providing it would be a nice
>> convenience, but nothing more.
>>
>>
>> > Or are Git hashes guaranteed to be universally unique?
>> >
>>
>> Nothing is, however within the realms of SHA1 collisions, sure. The chances
>> of finding a second repo for *any* other piece of software that contains
>> the identical hash is pretty low. The chances of finding the same hash in a
>> single Git repo is impractically low. I can't see how that is handled, but
>> the obvious way would be to just respin the commit so the date meta data
>> changed and the hash changed. In any case, if that's a flaw, it's a flaw of
>> Git, and can't be avoided. In practice, it's not a flaw at all.
>>
>> > It's just sloppy not to do this; if a quality release process is
>> required,
>> > > so is the SVN rev number. If "good enough" is OK, then it can be
>> omitted
>> > > because you can, most of the time, just guess. Guessing = mistakes,
>> > though.
>> >
>> > Sorry, I have to disagree there; the source reference cannot be
>> > omitted under any circumstances because it's not possible to review
>> > the source release without a reference to the files in SCM. There's no
>> > way to determine provenance otherwise.
>> >
>>
>> I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
>> unacceptable to me, however it seems like some people here think it's OK. I
>> can see their point of view, however it's too easy to do it right to
>> justify not doing it right. I agree with you, completely.
>>
>> Fred.
>>

-
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 19:20, sebb  wrote:
> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
>
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Effectively the SCM can be viewed as a database of pre-approved files.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> a unique reference to the source files that were used to create the release.
>
> In the case of SVN, since tags are not guaranteed immutable, the vote
> e-mail also
> needs the revision. The revision alone is not sufficient, because the
> ASF SVN is shared.
>
> Now whether every reviewer actually checks the source archive against SCM
> is another matter.
>
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a proper review to take place. In which case the vote cannot be
> considered valid.
>
> The vote thread needs to provide all the information that is needed to
> properly review the release candidate, otherwise IMO it is not a valid
> vote.
> This is needed both at the time of the vote, and for historic reasons
> so the context of the vote is properly recorded.
>
> Please do not obscure this thread with discussions of the release
> plugin or tags or merits of Git/SVN.
> Such technical aspects belong in separate threads.
> They obviously important to the process, but not the vote, which is
> about the result.
>
> 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

> or whatever the equivalent is for Git (or any other SCM that may be in
> use at the time).

-
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]

On the one hand, I think that, in many Apache communities, comparing the
source release to the VCS is the exception and not the rule, and may never
have happened, even once. (I think that there is at least an even chance
that some crusty veteran of httpd will arrive in this thread and call me
out on this, insisting that Sebb's view is and has always been the only
right way, and some neuron in the back of my mind thinks it has seen some
reference to a tool for comparing source release packages to svn.)

However, I don't see anything _bad_ about supplying an unambiguous,
immutable, reference to the VCS, and so it would be a good thing if Maven
helped Apache projects achieve this, rather than make it harder.

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.




On Sun, Jun 30, 2013 at 4:56 PM, Fred Cooke  wrote:

> >
> > OK, so what is the Git command to download a copy of the sources that
> >
> are part of the hash?
> >
>
> git checkout 
>
> Then observe the tree. You can also export an archive, though I don't
> recall the exact command off the top of my hand.
>
>
> > Don't I need to know something about the Git repo it comes from?
> >
>
> Yes, the URL which would be pre-agreed. Providing it would be a nice
> convenience, but nothing more.
>
>
> > Or are Git hashes guaranteed to be universally unique?
> >
>
> Nothing is, however within the realms of SHA1 collisions, sure. The chances
> of finding a second repo for *any* other piece of software that contains
> the identical hash is pretty low. The chances of finding the same hash in a
> single Git repo is impractically low. I can't see how that is handled, but
> the obvious way would be to just respin the commit so the date meta data
> changed and the hash changed. In any case, if that's a flaw, it's a flaw of
> Git, and can't be avoided. In practice, it's not a flaw at all.
>
> > It's just sloppy not to do this; if a quality release process is
> required,
> > > so is the SVN rev number. If "good enough" is OK, then it can be
> omitted
> > > because you can, most of the time, just guess. Guessing = mistakes,
> > though.
> >
> > Sorry, I have to disagree there; the source reference cannot be
> > omitted under any circumstances because it's not possible to review
> > the source release without a reference to the files in SCM. There's no
> > way to determine provenance otherwise.
> >
>
> I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
> unacceptable to me, however it seems like some people here think it's OK. I
> can see their point of view, however it's too easy to do it right to
> justify not doing it right. I agree with you, completely.
>
> Fred.
>

Re: Unique Git coordinates (was: Release process updates (try 2))

[sebb]

On 30 June 2013 23:28, Stephen Connolly  wrote:
> On Sunday, 30 June 2013, sebb wrote:
>
>> On 30 June 2013 21:56, Fred Cooke >
>> wrote:
>> >>
>> >> OK, so what is the Git command to download a copy of the sources that
>> >>
>> > are part of the hash?
>> >>
>> >
>> > git checkout 
>>
>> Does not work for me.
>
>
> Until I hear otherwise, the reviewers for whom this is critical (ie the
> PMC) have enough context to figure out which repo the vote refers to. (Or
> they just look it up from the Pom in the source bundle)

This seems to be replying to the wrong thread.

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

Re: Unique Git coordinates (was: Release process updates (try 2))

[Stephen Connolly]

On Sunday, 30 June 2013, sebb wrote:

> On 30 June 2013 21:56, Fred Cooke >
> wrote:
> >>
> >> OK, so what is the Git command to download a copy of the sources that
> >>
> > are part of the hash?
> >>
> >
> > git checkout 
>
> Does not work for me.


Until I hear otherwise, the reviewers for whom this is critical (ie the
PMC) have enough context to figure out which repo the vote refers to. (Or
they just look it up from the Pom in the source bundle)

Now I am not saying that it is ideal, and given how easy it is to provide
the details, I don't think it shoud be avoided, but when reviewing policy
and procedure it is necessary to get to the root requirements so that the
changed procedure (if it gets changed) is not doing things fr the sake of
doing them...

The fable of the fve chimpanzees and the ladder and the bunch of bananas is
always relevant when reviewing procedures (every time a chip tries to climb
the ladder, power-hose them all until it stops... Eventually no chimp will
try to climb... Then start swapping out chimps one at a time Then stop
hosing and end up with a room full of chimps who will beat the crap out f
any chimp that tries to climb the ladder but they don't know *why*)



> I get the following error message:
>
> fatal: Not a git repository (or any of the parent directories): .git
>
> This suggests that Git does not know where to download the hash from.
>
> > Then observe the tree. You can also export an archive, though I don't
> > recall the exact command off the top of my hand.
> >
> >
> >> Don't I need to know something about the Git repo it comes from?
> >>
> >
> > Yes, the URL which would be pre-agreed. Providing it would be a nice
> > convenience, but nothing more.
>
> Again I disagree; the reviewer should have the specific information
> they need without having to look elsewhere.
> And likewise it should be in the e-mail thread for historical purposes.
>
> >
> >> Or are Git hashes guaranteed to be universally unique?
> >>
> >
> > Nothing is, however within the realms of SHA1 collisions, sure. The
> chances
> > of finding a second repo for *any* other piece of software that contains
> > the identical hash is pretty low. The chances of finding the same hash
> in a
> > single Git repo is impractically low. I can't see how that is handled,
> but
> > the obvious way would be to just respin the commit so the date meta data
> > changed and the hash changed. In any case, if that's a flaw, it's a flaw
> of
> > Git, and can't be avoided. In practice, it's not a flaw at all.
> >
> >> It's just sloppy not to do this; if a quality release process is
> required,
> >> > so is the SVN rev number. If "good enough" is OK, then it can be
> omitted
> >> > because you can, most of the time, just guess. Guessing = mistakes,
> >> though.
> >>
> >> Sorry, I have to disagree there; the source reference cannot be
> >> omitted under any circumstances because it's not possible to review
> >> the source release without a reference to the files in SCM. There's no
> >> way to determine provenance otherwise.
> >>
> >
> > I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
> > unacceptable to me, however it seems like some people here think it's
> OK. I
> > can see their point of view, however it's too easy to do it right to
> > justify not doing it right. I agree with you, completely.
> >
> > Fred.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> For additional commands, e-mail: dev-h...@maven.apache.org 
>
>

-- 
Sent from my phone

Unique Git coordinates (was: Release process updates (try 2))

[sebb]

On 30 June 2013 21:56, Fred Cooke  wrote:
>>
>> OK, so what is the Git command to download a copy of the sources that
>>
> are part of the hash?
>>
>
> git checkout 

Does not work for me.

I get the following error message:

fatal: Not a git repository (or any of the parent directories): .git

This suggests that Git does not know where to download the hash from.

> Then observe the tree. You can also export an archive, though I don't
> recall the exact command off the top of my hand.
>
>
>> Don't I need to know something about the Git repo it comes from?
>>
>
> Yes, the URL which would be pre-agreed. Providing it would be a nice
> convenience, but nothing more.

Again I disagree; the reviewer should have the specific information
they need without having to look elsewhere.
And likewise it should be in the e-mail thread for historical purposes.

>
>> Or are Git hashes guaranteed to be universally unique?
>>
>
> Nothing is, however within the realms of SHA1 collisions, sure. The chances
> of finding a second repo for *any* other piece of software that contains
> the identical hash is pretty low. The chances of finding the same hash in a
> single Git repo is impractically low. I can't see how that is handled, but
> the obvious way would be to just respin the commit so the date meta data
> changed and the hash changed. In any case, if that's a flaw, it's a flaw of
> Git, and can't be avoided. In practice, it's not a flaw at all.
>
>> It's just sloppy not to do this; if a quality release process is required,
>> > so is the SVN rev number. If "good enough" is OK, then it can be omitted
>> > because you can, most of the time, just guess. Guessing = mistakes,
>> though.
>>
>> Sorry, I have to disagree there; the source reference cannot be
>> omitted under any circumstances because it's not possible to review
>> the source release without a reference to the files in SCM. There's no
>> way to determine provenance otherwise.
>>
>
> I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
> unacceptable to me, however it seems like some people here think it's OK. I
> can see their point of view, however it's too easy to do it right to
> justify not doing it right. I agree with you, completely.
>
> Fred.

-
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)

[Fred Cooke]

>
> OK, so what is the Git command to download a copy of the sources that
>
are part of the hash?
>

git checkout 

Then observe the tree. You can also export an archive, though I don't
recall the exact command off the top of my hand.


> Don't I need to know something about the Git repo it comes from?
>

Yes, the URL which would be pre-agreed. Providing it would be a nice
convenience, but nothing more.


> Or are Git hashes guaranteed to be universally unique?
>

Nothing is, however within the realms of SHA1 collisions, sure. The chances
of finding a second repo for *any* other piece of software that contains
the identical hash is pretty low. The chances of finding the same hash in a
single Git repo is impractically low. I can't see how that is handled, but
the obvious way would be to just respin the commit so the date meta data
changed and the hash changed. In any case, if that's a flaw, it's a flaw of
Git, and can't be avoided. In practice, it's not a flaw at all.

> It's just sloppy not to do this; if a quality release process is required,
> > so is the SVN rev number. If "good enough" is OK, then it can be omitted
> > because you can, most of the time, just guess. Guessing = mistakes,
> though.
>
> Sorry, I have to disagree there; the source reference cannot be
> omitted under any circumstances because it's not possible to review
> the source release without a reference to the files in SCM. There's no
> way to determine provenance otherwise.
>

I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
unacceptable to me, however it seems like some people here think it's OK. I
can see their point of view, however it's too easy to do it right to
justify not doing it right. I agree with you, completely.

Fred.

Re: Release process updates (try 2)

[sebb]

On 30 June 2013 19:48, Fred Cooke  wrote:
> For Git the only thing that is needed is the unique 40 character hash such
> as this:
>
> FreeAir:youtube-dl fred$ git rev-parse HEAD
> 48bfb5f2387ab47e1973d9db0782a9af66ffc4e6

OK, so what is the Git command to download a copy of the sources that
are part of the hash?
Don't I need to know something about the Git repo it comes from?
Or are Git hashes guaranteed to be universally unique?

> It's just sloppy not to do this; if a quality release process is required,
> so is the SVN rev number. If "good enough" is OK, then it can be omitted
> because you can, most of the time, just guess. Guessing = mistakes, though.

Sorry, I have to disagree there; the source reference cannot be
omitted under any circumstances because it's not possible to review
the source release without a reference to the files in SCM. There's no
way to determine provenance otherwise.

> Fred.
>
> On Sun, Jun 30, 2013 at 8:20 PM, sebb  wrote:
>
>> The mission of the ASF is to release software as source, and to ensure
>> that the released source is available under the Apache Licence.
>>
>> Before a release can be approved it must be voted on by the PMC.
>> The review process needs to establish that the proposed source release
>> meets those aims.
>>
>> It's all but impossible for reviewers to examine every single file in
>> a source archive to determine if it meets the criteria.
>>
>> However, PMCs are also required to check what is added to the SCM
>> (SVN/Git) to make sure it meets the required license criteria.
>> This is done on an ongoing basis as part of reviewing check-ins and
>> accepting new contributions.
>>
>> So provided that all the files in the source release are also present
>> in SCM, the PMC can be reasonably sure that the source release meets
>> the ASF criteria.
>>
>> Effectively the SCM can be viewed as a database of pre-approved files.
>>
>> Without having the SCM as a database of validated files, there are far
>> too many files in the average source archive to check individually.
>> And how would one check their provenance? The obvious way is to
>> compare them with the entries in SCM.
>>
>> Therefore, I contend that a release vote does not make sense without
>> a unique reference to the source files that were used to create the
>> release.
>>
>> In the case of SVN, since tags are not guaranteed immutable, the vote
>> e-mail also
>> needs the revision. The revision alone is not sufficient, because the
>> ASF SVN is shared.
>>
>> Now whether every reviewer actually checks the source archive against SCM
>> is another matter.
>>
>> But if the required SCM information is not present, it would be
>> difficult to argue that the RM had provided sufficient information for
>> a proper review to take place. In which case the vote cannot be
>> considered valid.
>>
>> The vote thread needs to provide all the information that is needed to
>> properly review the release candidate, otherwise IMO it is not a valid
>> vote.
>> This is needed both at the time of the vote, and for historic reasons
>> so the context of the vote is properly recorded.
>>
>> Please do not obscure this thread with discussions of the release
>> plugin or tags or merits of Git/SVN.
>> Such technical aspects belong in separate threads.
>> They obviously important to the process, but not the vote, which is
>> about the result.
>>
>> 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)
>>
>> or whatever the equivalent is for Git (or any other SCM that may be in
>> use at the time).
>>
>> -
>> 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 (try 2)

[Gary Gregory]

Fine with me. Thanks for the explanation sebb.

Gary

On Jun 30, 2013, at 14:20, sebb  wrote:

> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
>
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Effectively the SCM can be viewed as a database of pre-approved files.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> a unique reference to the source files that were used to create the release.
>
> In the case of SVN, since tags are not guaranteed immutable, the vote
> e-mail also
> needs the revision. The revision alone is not sufficient, because the
> ASF SVN is shared.
>
> Now whether every reviewer actually checks the source archive against SCM
> is another matter.
>
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a proper review to take place. In which case the vote cannot be
> considered valid.
>
> The vote thread needs to provide all the information that is needed to
> properly review the release candidate, otherwise IMO it is not a valid
> vote.
> This is needed both at the time of the vote, and for historic reasons
> so the context of the vote is properly recorded.
>
> Please do not obscure this thread with discussions of the release
> plugin or tags or merits of Git/SVN.
> Such technical aspects belong in separate threads.
> They obviously important to the process, but not the vote, which is
> about the result.
>
> 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)
>
> or whatever the equivalent is for Git (or any other SCM that may be in
> use at the time).
>
> -
> 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 (try 2)

[Fred Cooke]

For Git the only thing that is needed is the unique 40 character hash such
as this:

FreeAir:youtube-dl fred$ git rev-parse HEAD
48bfb5f2387ab47e1973d9db0782a9af66ffc4e6

It's just sloppy not to do this; if a quality release process is required,
so is the SVN rev number. If "good enough" is OK, then it can be omitted
because you can, most of the time, just guess. Guessing = mistakes, though.

Fred.

On Sun, Jun 30, 2013 at 8:20 PM, sebb  wrote:

> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
>
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Effectively the SCM can be viewed as a database of pre-approved files.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> a unique reference to the source files that were used to create the
> release.
>
> In the case of SVN, since tags are not guaranteed immutable, the vote
> e-mail also
> needs the revision. The revision alone is not sufficient, because the
> ASF SVN is shared.
>
> Now whether every reviewer actually checks the source archive against SCM
> is another matter.
>
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a proper review to take place. In which case the vote cannot be
> considered valid.
>
> The vote thread needs to provide all the information that is needed to
> properly review the release candidate, otherwise IMO it is not a valid
> vote.
> This is needed both at the time of the vote, and for historic reasons
> so the context of the vote is properly recorded.
>
> Please do not obscure this thread with discussions of the release
> plugin or tags or merits of Git/SVN.
> Such technical aspects belong in separate threads.
> They obviously important to the process, but not the vote, which is
> about the result.
>
> 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)
>
> or whatever the equivalent is for Git (or any other SCM that may be in
> use at the time).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Release process updates (try 2)

[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.

Before a release can be approved it must be voted on by the PMC.
The review process needs to establish that the proposed source release
meets those aims.

It's all but impossible for reviewers to examine every single file in
a source archive to determine if it meets the criteria.

However, PMCs are also required to check what is added to the SCM
(SVN/Git) to make sure it meets the required license criteria.
This is done on an ongoing basis as part of reviewing check-ins and
accepting new contributions.

So provided that all the files in the source release are also present
in SCM, the PMC can be reasonably sure that the source release meets
the ASF criteria.

Effectively the SCM can be viewed as a database of pre-approved files.

Without having the SCM as a database of validated files, there are far
too many files in the average source archive to check individually.
And how would one check their provenance? The obvious way is to
compare them with the entries in SCM.

Therefore, I contend that a release vote does not make sense without
a unique reference to the source files that were used to create the release.

In the case of SVN, since tags are not guaranteed immutable, the vote
e-mail also
needs the revision. The revision alone is not sufficient, because the
ASF SVN is shared.

Now whether every reviewer actually checks the source archive against SCM
is another matter.

But if the required SCM information is not present, it would be
difficult to argue that the RM had provided sufficient information for
a proper review to take place. In which case the vote cannot be
considered valid.

The vote thread needs to provide all the information that is needed to
properly review the release candidate, otherwise IMO it is not a valid
vote.
This is needed both at the time of the vote, and for historic reasons
so the context of the vote is properly recorded.

Please do not obscure this thread with discussions of the release
plugin or tags or merits of Git/SVN.
Such technical aspects belong in separate threads.
They obviously important to the process, but not the vote, which is
about the result.

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)

or whatever the equivalent is for Git (or any other SCM that may be in
use at the time).

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