Re: Release process updates (try 2)
On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com 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/ (r1496317https://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)
On 1 July 2013 07:18, Chris Graham chrisgw...@gmail.com wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com 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/ (r1496317https://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)
On 1 July 2013 07:18, Chris Graham chrisgw...@gmail.com wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com 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/ (r1496317https://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)
On 30 June 2013 23:33, sebb seb...@gmail.com wrote: On 30 June 2013 19:20, sebb seb...@gmail.com wrote: snip/ 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)
On Mon, Jul 1, 2013 at 7:14 PM, sebb seb...@gmail.com wrote: On 1 July 2013 07:18, Chris Graham chrisgw...@gmail.com wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com 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)
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)
+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 chrisgw...@gmail.com wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com 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/ (r1496317https://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)
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 dk...@apache.org 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 chrisgw...@gmail.com wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com 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)
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 fred.co...@gmail.com 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 dk...@apache.org 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 chrisgw...@gmail.com wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com 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 Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Release process updates (try 2)
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 fred.co...@gmail.com javascript:; 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 dk...@apache.orgjavascript:; 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 chrisgw...@gmail.comjavascript:; wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.comjavascript:; 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 javascript:; - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- Sent from my phone
Release process updates (try 2)
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
Re: Release process updates (try 2)
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 seb...@gmail.com 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
Re: Release process updates (try 2)
Fine with me. Thanks for the explanation sebb. Gary On Jun 30, 2013, at 14:20, sebb seb...@gmail.com 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)
On 30 June 2013 19:48, Fred Cooke fred.co...@gmail.com 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 seb...@gmail.com 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)
OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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.
Unique Git coordinates (was: Release process updates (try 2))
On 30 June 2013 21:56, Fred Cooke fred.co...@gmail.com wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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: Unique Git coordinates (was: Release process updates (try 2))
On Sunday, 30 June 2013, sebb wrote: On 30 June 2013 21:56, Fred Cooke fred.co...@gmail.com javascript:; wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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 javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Re: Unique Git coordinates (was: Release process updates (try 2))
On 30 June 2013 23:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Sunday, 30 June 2013, sebb wrote: On 30 June 2013 21:56, Fred Cooke fred.co...@gmail.com javascript:; wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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: Release process updates (try 2)
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 fred.co...@gmail.com wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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)
On 30 June 2013 19:20, sebb seb...@gmail.com 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)
On 30 June 2013 23:32, Benson Margulies bimargul...@gmail.com 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 fred.co...@gmail.com wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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
