Re: [VOTE] Release Apache Maven Model Converter version 2.3
Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. So, it is a bit short sighted to declare him as troll, simply because you (the Maven PMC) decided to ignore the problem. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
What sebb does not appear to have understood or accepted, as Stephen has endlessly pointed out, is that we vote on the source bundle, not a scm revision, and that, strictly speaking a SCM is not even required (however sensible it is to use one). He wants a tree and a revision so that we can compare between releases, where what he should be doing, strictly speaking, is comparing source tar balls, as that is what we really are voting on. The greater maven community also does not appear to have a problem with this approach. -Chris On Thu, Aug 15, 2013 at 6:50 PM, Jörg Schaible joerg.schai...@scalaris.comwrote: Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. So, it is a bit short sighted to declare him as troll, simply because you (the Maven PMC) decided to ignore the problem. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 15 August 2013 09:50, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to Correction, if pedantic, we know about Sebb's issues... Sebb has not demonstrated that they are a problem. If Sebb can convince the PMC that his issue is an actual problem (as distinct from his current approach which is giving the impression that it is Sebb who is the problem ;-) ) then there is something to act upon. The point being that this PMC - i.e. the people who's vote matter - do not perceive that we have any problem identifying the SCM tag and revision that we are voting on based on the information provided in the current vote template. If Sebb can show us how we have a problem - rather than repeating noise - then we are more than happy to fix such issues. A case in point being the source release bundles historically containing files that are missing the license headers - a problem which I had started to identify - which the PMC has put a plan in place to remediate and we are reporting to the board on our progress in that regard. We do not choose to put value on procedure for procedure's sake. Thus we prefer that our templates contain the exact minimum that is required. A pegable SVN revision can be determined from the time stamp of the vote email sent to the Apache Maven Developer's mailing list. That will not be the revision when the tag was created, but the tag should not have been modified between its creation and the timestamp (that is something that I personally check when I follow my own private check-list... I have yet to find a counter-example and thus you will not have seen a -1 vote from me for such) With respect to GIT based releases, in the past have requested the GIT hash that the bundle was created from. My personal view is that we should be pushing to master after a release, but hold off pushing the tags until the release vote is approved. Thus the GIT emails should contain the GIT hash of the tag but not the tag name. I view our GIT based processes as a bit of a work in progress as we figure out the best ways of matching the GIT SCM with our ways of working. ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. If Sebb wants to put extra process on other projects, that is not my problem. You don't see me complaining on the creadur lists that the RAT plugin is not being released properly, e.g.
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Le 15 août 2013 10:51, Jörg Schaible joerg.schai...@scalaris.com a écrit : Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. So, it is a bit short sighted to declare him as troll, simply because you (the Maven PMC) decided to ignore the problem. Having followed all the debates, I think it's certainly wrong to state the problem has been ignored. There were actually *many* answers, and it has merely been disagreed on. I've personally already expressed my take on it: * I basically don't really mind * adding this information would be nothing (a few seconds of work) compared to the weight of re-reading always the same mails here :) Cheers
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote: What sebb does not appear to have understood or accepted, as Stephen has endlessly pointed out, is that we vote on the source bundle, not a scm revision, and that, strictly speaking a SCM is not even required (however sensible it is to use one). He wants a tree and a revision so that we can compare between releases, where what he should be doing, strictly speaking, is comparing source tar balls, as that is what we really are voting on. I agree that what is released (and voted on) are the source tarballs. And any such tarballs should be identical (barring possibly different EOL settings for text files). However, that is only one of the checks that need to be made. The PMC also needs to ensure that the files are being released under the correct license. I contend that the only practical way to check the licences is to compare the source tarball(s) with the files in SCM. [The files should only be added to SCM if the license is OK, so the SCM tag acts as a database of validated source files.] The SVN revision / Git hash are needed to ensure uniqueness. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Sent from my iPhone On 15/08/2013, at 10:05 PM, sebb seb...@gmail.com wrote: On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote: What sebb does not appear to have understood or accepted, as Stephen has endlessly pointed out, is that we vote on the source bundle, not a scm revision, and that, strictly speaking a SCM is not even required (however sensible it is to use one). He wants a tree and a revision so that we can compare between releases, where what he should be doing, strictly speaking, is comparing source tar balls, as that is what we really are voting on. I agree that what is released (and voted on) are the source tarballs. And any such tarballs should be identical (barring possibly different EOL settings for text files). However, that is only one of the checks that need to be made. The PMC also needs to ensure that the files are being released under the correct license. Are not the licenses in the source that is in the source tarball? If so, can not the rat plugin or similar be used to check the compliance? I contend that the only practical way to check the licences is to compare the source tarball(s) with the files in SCM. [The files should only be added to SCM if the license is OK, so the SCM tag acts as a database of validated source files.] The SVN revision / Git hash are needed to ensure uniqueness. - 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: [VOTE] Release Apache Maven Model Converter version 2.3
What Sebb is doing is perfectly reasonable. He's trying to assert that everything in the source ball actually comes from source control and that no errant files have made their way into the distribution. Right now we cannot assert that the assembly plugin has not wandered outside the checkout and pulled something else in, or that someone didn't accidentally put something else in the distribution. I think this unlikely but we can't assert otherwise right now which I believe is Sebb's point. If we can embed the revision from which the assembly was made in the assembly itself (and maybe the build number plugin is doing this already), then a tool can be made to unpack the assembly, checkout the revision and assert that everything in the source distribution comes from source control. If we can also assert that as part of each build all the license files are intact and headers are in place then I believe we're done with provenance. Licenses are present, all files have valid license headers, all files present in the source distribution come from source control, all contributions to source control are from bonafide CLA carrying Apache committers because you don't get access to commit until the CLA is on file. Sebb, reasonably accurate? On Aug 15, 2013, at 9:01 AM, Chris Graham chrisgw...@gmail.com wrote: Sent from my iPhone On 15/08/2013, at 10:05 PM, sebb seb...@gmail.com wrote: On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote: What sebb does not appear to have understood or accepted, as Stephen has endlessly pointed out, is that we vote on the source bundle, not a scm revision, and that, strictly speaking a SCM is not even required (however sensible it is to use one). He wants a tree and a revision so that we can compare between releases, where what he should be doing, strictly speaking, is comparing source tar balls, as that is what we really are voting on. I agree that what is released (and voted on) are the source tarballs. And any such tarballs should be identical (barring possibly different EOL settings for text files). However, that is only one of the checks that need to be made. The PMC also needs to ensure that the files are being released under the correct license. Are not the licenses in the source that is in the source tarball? If so, can not the rat plugin or similar be used to check the compliance? I contend that the only practical way to check the licences is to compare the source tarball(s) with the files in SCM. [The files should only be added to SCM if the license is OK, so the SCM tag acts as a database of validated source files.] The SVN revision / Git hash are needed to ensure uniqueness. - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: bug MNG-5459 (failure to resolve pom artifact from snapshotVersion in maven-metadata.xml)
Hi Robert, At Thu, 02 May 2013 19:34:07 +0200, Robert Scholte wrote: Hi Claudio, I've had a look at it, because it looks like a simple fix. But first I had to write a unit-test to confirm the issue, but I haven't succeeded (yet). Any progress on this? I'd like to get this off my bug list. Maybe I can give you a hand? So that part is still required before we can apply this patch. Or, is it possible to relax the rules a bit this time, as writing a unit test seems to be far more involved than reasoning about the (simple) fix? Claudio -- AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany Phone: +49 341 265 310 19 Web:http://www.av-test.org Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076) Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-plugins pull request: Use Eclipse-SourceBundle to handle sources
GitHub user nill14 opened a pull request: https://github.com/apache/maven-plugins/pull/12 Use Eclipse-SourceBundle to handle sources Added part for correctly handling source bundles. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nill14/maven-plugins trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/12.patch - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote: What Sebb is doing is perfectly reasonable. Thank you! He's trying to assert that everything in the source ball actually comes from source control and that no errant files have made their way into the distribution. Right now we cannot assert that the assembly plugin has not wandered outside the checkout and pulled something else in, or that someone didn't accidentally put something else in the distribution. I think this unlikely but we can't assert otherwise right now which I believe is Sebb's point. It *has* already happened several times that I am aware of. The last few releases of the War plugin (various RMs voters) included at least one spurious file. So it was not just a one-off packaging - and review - failure. [See separate thread(s) for all the details; they are not germane here.] The message is that mistakes happen even in automated processes. Which is why independent comparison of input and output is valuable. If we can embed the revision from which the assembly was made in the assembly itself (and maybe the build number plugin is doing this already), then a tool can be made to unpack the assembly, checkout the revision and assert that everything in the source distribution comes from source control. If we can also assert that as part of each build all the license files are intact and headers are in place then I believe we're done with provenance. Licenses are present, all files have valid license headers, all files present in the source distribution come from source control, all contributions to source control are from bonafide CLA carrying Apache committers because you don't get access to commit until the CLA is on file. Sebb, reasonably accurate? Yes. One other point I made already is that I think the vote e-mail needs to be transparent to all, not just those on the PMC. Links to the output from the release process are obviously already in the mail; what is missing is the input to the process, e.g.. SCM coords. Yes, it may be possible to dig out the details from the archive, but that's not trivial. Publishing the SCM coordinates in the mail is trivial to do, and shows that the input is an important part of the review process. Having the information in the mail thread is also useful for the archives. On Aug 15, 2013, at 9:01 AM, Chris Graham chrisgw...@gmail.com wrote: Sent from my iPhone On 15/08/2013, at 10:05 PM, sebb seb...@gmail.com wrote: On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote: What sebb does not appear to have understood or accepted, as Stephen has endlessly pointed out, is that we vote on the source bundle, not a scm revision, and that, strictly speaking a SCM is not even required (however sensible it is to use one). He wants a tree and a revision so that we can compare between releases, where what he should be doing, strictly speaking, is comparing source tar balls, as that is what we really are voting on. I agree that what is released (and voted on) are the source tarballs. And any such tarballs should be identical (barring possibly different EOL settings for text files). However, that is only one of the checks that need to be made. The PMC also needs to ensure that the files are being released under the correct license. Are not the licenses in the source that is in the source tarball? If so, can not the rat plugin or similar be used to check the compliance? I contend that the only practical way to check the licences is to compare the source tarball(s) with the files in SCM. [The files should only be added to SCM if the license is OK, so the SCM tag acts as a database of validated source files.] The SVN revision / Git hash are needed to ensure uniqueness. - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
On Wed, Aug 14, 2013 at 3:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 14 August 2013 14:14, sebb seb...@gmail.com wrote: On 14 August 2013 14:08, Jason van Zyl ja...@tesla.io wrote: Here you go: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ Thanks again, however that was last updated: Last Changed Author: jvanzyl Last Changed Rev: 1513840 Last Changed Date: 2013-08-14 13:25:11 +0100 (Wed, 14 Aug 2013) which unfortunately does not agree with the originally stated revision: However https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ @1508060 is a perfectly valid immutable coordinate for the source code upon which this was created... No, this release was respun due to an incompatibility that was discovered prior to the vote email was sent. The correct revision is 1513840. Subversion Revision: r1508060 I'll put it in the template for next time. Thanks, that would save a lot of hassle for everyone. On Aug 14, 2013, at 9:00 AM, sebb seb...@gmail.com wrote: On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote: Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Thanks. However the SVN revision is not sufficient to identify the source, especially since the ASF uses multiple shared SVN repos. An appropriate base directory is also needed to identify which part of the tree was used. Since the tag is what is used in the POM scm entry, please specify the SVN tag name along with its revision. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On Thu, Aug 15, 2013 at 10:50 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. So, it is a bit short sighted to declare him as troll, simply because you (the Maven PMC) decided to ignore the problem. Hi Jörg, Personally I'm not ignoring the problem, and I don't think anyone else is either. I am trying to understand what the problem is, because I cannot see it. Therefor I ask questions to try to find out what the problem is and then, and only then, decide if/how to solve it. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:
On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
What Sebb is doing is perfectly reasonable.
I agree. Checking that the source bundle is correct is good release review
practice.
Thank you!
He's trying to assert that everything in the source ball actually comes
from source control and that no errant files have made their way into the
distribution. Right now we cannot assert that the assembly plugin has not
wandered outside the checkout and pulled something else in, or that someone
didn't accidentally put something else in the distribution. I think this
unlikely but we can't assert otherwise right now which I believe is Sebb's
point.
It *has* already happened several times that I am aware of.
The last few releases of the War plugin (various RMs voters)
included at least one spurious file.
So it was not just a one-off packaging - and review - failure.
[See separate thread(s) for all the details; they are not germane here.]
The message is that mistakes happen even in automated processes.
Which is why independent comparison of input and output is valuable.
If we can embed the revision from which the assembly was made in the
assembly itself (and maybe the build number plugin is doing this already),
then a tool can be made to unpack the assembly, checkout the revision and
assert that everything in the source distribution comes from source control.
If we can also assert that as part of each build all the license files
are intact and headers are in place then I believe we're done with
provenance.
Licenses are present, all files have valid license headers, all files
present in the source distribution come from source control, all
contributions to source control are from bonafide CLA carrying Apache
committers because you don't get access to commit until the CLA is on file.
Sebb, reasonably accurate?
Yes.
One other point I made already is that I think the vote e-mail needs
to be transparent to all, not just those on the PMC.
Links to the output from the release process are obviously already in
the mail; what is missing is the input to the process, e.g.. SCM
coords.
Yes, it may be possible to dig out the details from the archive, but
that's not trivial.
I disagree.
If we focus first on a normal release, one that succeeds on the first
attempt, without a respin or deleting of tags.
To check provenance you would do this:
1. download the source bundle
2. unpack the source bundle
3. checkout the corresponding source code from the SCM
4. compare the two trees
Right so far?
What you want, if I understand you correctly, is to have the SCM URL in the
vote email. So that you can give that to your SCM client in step 3.
With the process we use here at the Maven project, the SCM URL is in the
pom.xml file that sits in the root directory of the unpacked source bundle.
All you need to do is open the file and copy the URL from there. I still
fail to see how that is so much harder than to copy the URL from an email.
That is if you don't know the conventions that we use, by way of the
Release Plugin. The tag will always be in the format
${project.artifactId}-${project.version}
Now, for a respun release thing are trickier. Here it might be a good idea
to include the revision number or hash, or whatever is unique in the SCM
being used. Even though the code under review will always be under the
latest tag in the above format (at least for Subversion).
Publishing the SCM coordinates in the mail is trivial to do, and shows
that the input is an important part of the review process.
Having the information in the mail thread is also useful for the archives.
As others have said before, we aim to automate the release process as much
as possible. Therefor even a seemingly minor addition will be questioned,
as you have noticed, before it is included in our process.
Can you explain why the information is useful for the archives? I've seen
you mentioned that before. Isn't that moot once the release is approved?
The tag will be in Subversion for the forseable future and noone will touch
it. What am I missing?
On Aug 15, 2013, at 9:01 AM, Chris Graham chrisgw...@gmail.com wrote:
Sent from my iPhone
On 15/08/2013, at 10:05 PM, sebb seb...@gmail.com wrote:
On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote:
What sebb does not appear to have understood or accepted, as Stephen
has
endlessly pointed out, is that we vote on the source bundle, not a scm
revision, and that, strictly speaking a SCM is not even required
(however
sensible it is to use one).
He wants a tree and a revision so that we can compare between
releases,
where what he should be doing, strictly speaking, is comparing source
tar
balls, as that is what we really are voting on.
I agree that what is released (and voted on) are the source tarballs.
And any such tarballs should be
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Dennis, effectively what is required is a statement like this: I believe that I've released XYZ binaries from ABC sources (tarball + N patches, SCM, whatever) with enough info to exactly identify what XYZ and ABC are (checksums, URLs, revisions, etc) without guessing and duplicated research/looking up of by everyone who wants to check. If you just say here's the binaries then you have to put a LOT more work in to figure out the source to compare with, and thus trace history, and thus know that they're legit, or not. That's the problem. No statement is being made about what the release manager thinks they've released. Thus that release could be from a wrong Git branch by accident, for example or any number of other things. EG POM edited to not be snapshots and manual build done with changes made, etc. PS, it's ing GREAT that Jason stepped up and said what he said. Amen to that! More fine leadership. Regards, Fred. On Thu, Aug 15, 2013 at 9:37 PM, Dennis Lundberg denn...@apache.org wrote: On Thu, Aug 15, 2013 at 10:50 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. So, it is a bit short sighted to declare him as troll, simply because you (the Maven PMC) decided to ignore the problem. Hi Jörg, Personally I'm not ignoring the problem, and I don't think anyone else is either. I am trying to understand what the problem is, because I cannot see it. Therefor I ask questions to try to find out what the problem is and then, and only then, decide if/how to solve it. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
+1 (Yeah, the vote) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Use modello 1.8.1, not 1.8
There was a compatibility break with generated code for maven 2.2.1. Fixed in 1.8.1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Right so far?
No, you're not. Step three, in SVN, requires reviewing history to confirm
no changes were made to that URL *ever*. In Git, step 3 involves knowing
the hash, as spurious tags have already been known to circulate.
Even if all of the details were in the POM, the question still remains, is
this the revision you *intended* to release? Or not? ONLY you can answer
this.
Fred.
On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg denn...@apache.org wrote:
On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:
On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
What Sebb is doing is perfectly reasonable.
I agree. Checking that the source bundle is correct is good release review
practice.
Thank you!
He's trying to assert that everything in the source ball actually comes
from source control and that no errant files have made their way into the
distribution. Right now we cannot assert that the assembly plugin has not
wandered outside the checkout and pulled something else in, or that
someone
didn't accidentally put something else in the distribution. I think this
unlikely but we can't assert otherwise right now which I believe is
Sebb's
point.
It *has* already happened several times that I am aware of.
The last few releases of the War plugin (various RMs voters)
included at least one spurious file.
So it was not just a one-off packaging - and review - failure.
[See separate thread(s) for all the details; they are not germane here.]
The message is that mistakes happen even in automated processes.
Which is why independent comparison of input and output is valuable.
If we can embed the revision from which the assembly was made in the
assembly itself (and maybe the build number plugin is doing this
already),
then a tool can be made to unpack the assembly, checkout the revision and
assert that everything in the source distribution comes from source
control.
If we can also assert that as part of each build all the license files
are intact and headers are in place then I believe we're done with
provenance.
Licenses are present, all files have valid license headers, all files
present in the source distribution come from source control, all
contributions to source control are from bonafide CLA carrying Apache
committers because you don't get access to commit until the CLA is on
file.
Sebb, reasonably accurate?
Yes.
One other point I made already is that I think the vote e-mail needs
to be transparent to all, not just those on the PMC.
Links to the output from the release process are obviously already in
the mail; what is missing is the input to the process, e.g.. SCM
coords.
Yes, it may be possible to dig out the details from the archive, but
that's not trivial.
I disagree.
If we focus first on a normal release, one that succeeds on the first
attempt, without a respin or deleting of tags.
To check provenance you would do this:
1. download the source bundle
2. unpack the source bundle
3. checkout the corresponding source code from the SCM
4. compare the two trees
Right so far?
What you want, if I understand you correctly, is to have the SCM URL in the
vote email. So that you can give that to your SCM client in step 3.
With the process we use here at the Maven project, the SCM URL is in the
pom.xml file that sits in the root directory of the unpacked source bundle.
All you need to do is open the file and copy the URL from there. I still
fail to see how that is so much harder than to copy the URL from an email.
That is if you don't know the conventions that we use, by way of the
Release Plugin. The tag will always be in the format
${project.artifactId}-${project.version}
Now, for a respun release thing are trickier. Here it might be a good idea
to include the revision number or hash, or whatever is unique in the SCM
being used. Even though the code under review will always be under the
latest tag in the above format (at least for Subversion).
Publishing the SCM coordinates in the mail is trivial to do, and shows
that the input is an important part of the review process.
Having the information in the mail thread is also useful for the
archives.
As others have said before, we aim to automate the release process as much
as possible. Therefor even a seemingly minor addition will be questioned,
as you have noticed, before it is included in our process.
Can you explain why the information is useful for the archives? I've seen
you mentioned that before. Isn't that moot once the release is approved?
The tag will be in Subversion for the forseable future and noone will touch
it. What am I missing?
On Aug 15, 2013, at 9:01 AM, Chris Graham chrisgw...@gmail.com
wrote:
Sent from my iPhone
On 15/08/2013, at 10:05 PM, sebb seb...@gmail.com wrote:
On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote:
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke fred.co...@gmail.com wrote:
Right so far?
No, you're not. Step three, in SVN, requires reviewing history to confirm
no changes were made to that URL *ever*. In Git, step 3 involves knowing
the hash, as spurious tags have already been known to circulate.
I don't know Git that well yet, so I won't go into a discussion about that.
As for Subversion, you missed a few bits of what I wrote. I was talking
about a release that is *not* respun. With our process that means that
there has never been such a tag before and, if the vote passes, there will
never be another one again *ever*. If someone doesn't follow our process
that will become apparent during the review.
Even if all of the details were in the POM, the question still remains, is
this the revision you *intended* to release? Or not? ONLY you can answer
this.
With our process - yes it is. *always*
Fred.
On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg denn...@apache.org
wrote:
On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:
On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
What Sebb is doing is perfectly reasonable.
I agree. Checking that the source bundle is correct is good release
review
practice.
Thank you!
He's trying to assert that everything in the source ball actually
comes
from source control and that no errant files have made their way into
the
distribution. Right now we cannot assert that the assembly plugin has
not
wandered outside the checkout and pulled something else in, or that
someone
didn't accidentally put something else in the distribution. I think
this
unlikely but we can't assert otherwise right now which I believe is
Sebb's
point.
It *has* already happened several times that I am aware of.
The last few releases of the War plugin (various RMs voters)
included at least one spurious file.
So it was not just a one-off packaging - and review - failure.
[See separate thread(s) for all the details; they are not germane
here.]
The message is that mistakes happen even in automated processes.
Which is why independent comparison of input and output is valuable.
If we can embed the revision from which the assembly was made in the
assembly itself (and maybe the build number plugin is doing this
already),
then a tool can be made to unpack the assembly, checkout the revision
and
assert that everything in the source distribution comes from source
control.
If we can also assert that as part of each build all the license
files
are intact and headers are in place then I believe we're done with
provenance.
Licenses are present, all files have valid license headers, all files
present in the source distribution come from source control, all
contributions to source control are from bonafide CLA carrying Apache
committers because you don't get access to commit until the CLA is on
file.
Sebb, reasonably accurate?
Yes.
One other point I made already is that I think the vote e-mail needs
to be transparent to all, not just those on the PMC.
Links to the output from the release process are obviously already in
the mail; what is missing is the input to the process, e.g.. SCM
coords.
Yes, it may be possible to dig out the details from the archive, but
that's not trivial.
I disagree.
If we focus first on a normal release, one that succeeds on the first
attempt, without a respin or deleting of tags.
To check provenance you would do this:
1. download the source bundle
2. unpack the source bundle
3. checkout the corresponding source code from the SCM
4. compare the two trees
Right so far?
What you want, if I understand you correctly, is to have the SCM URL in
the
vote email. So that you can give that to your SCM client in step 3.
With the process we use here at the Maven project, the SCM URL is in the
pom.xml file that sits in the root directory of the unpacked source
bundle.
All you need to do is open the file and copy the URL from there. I still
fail to see how that is so much harder than to copy the URL from an
email.
That is if you don't know the conventions that we use, by way of the
Release Plugin. The tag will always be in the format
${project.artifactId}-${project.version}
Now, for a respun release thing are trickier. Here it might be a good
idea
to include the revision number or hash, or whatever is unique in the SCM
being used. Even though the code under review will always be under the
latest tag in the above format (at least for Subversion).
Publishing the SCM coordinates in the mail is trivial to do, and shows
that the input is an important part of the review process.
Having the information in the mail thread is also useful for the
archives.
As others have said before, we aim to automate the
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Actually, I missed exactly nothing!!! Your process could be flawed. Human errors do happen. The entire point of any review is to not trust process or people, and to check everything. You're effectively advocating not doing that, and this *IS* unhealthy. I know that with your process on a primary vote the tag should exist once, and only once. Someone could screw up. It happens. Your promise of we never make mistakes holds no water with me. The most disturbing part of all is Sebb being persecuted and attacked and labeled a *troll* of all things for advocating due diligence. :-/ Fred. On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg denn...@apache.orgwrote: On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke fred.co...@gmail.com wrote: Right so far? No, you're not. Step three, in SVN, requires reviewing history to confirm no changes were made to that URL *ever*. In Git, step 3 involves knowing the hash, as spurious tags have already been known to circulate. I don't know Git that well yet, so I won't go into a discussion about that. As for Subversion, you missed a few bits of what I wrote. I was talking about a release that is *not* respun. With our process that means that there has never been such a tag before and, if the vote passes, there will never be another one again *ever*. If someone doesn't follow our process that will become apparent during the review. Even if all of the details were in the POM, the question still remains, is this the revision you *intended* to release? Or not? ONLY you can answer this. With our process - yes it is. *always* Fred. On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg denn...@apache.org wrote: On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote: On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote: What Sebb is doing is perfectly reasonable. I agree. Checking that the source bundle is correct is good release review practice. Thank you! He's trying to assert that everything in the source ball actually comes from source control and that no errant files have made their way into the distribution. Right now we cannot assert that the assembly plugin has not wandered outside the checkout and pulled something else in, or that someone didn't accidentally put something else in the distribution. I think this unlikely but we can't assert otherwise right now which I believe is Sebb's point. It *has* already happened several times that I am aware of. The last few releases of the War plugin (various RMs voters) included at least one spurious file. So it was not just a one-off packaging - and review - failure. [See separate thread(s) for all the details; they are not germane here.] The message is that mistakes happen even in automated processes. Which is why independent comparison of input and output is valuable. If we can embed the revision from which the assembly was made in the assembly itself (and maybe the build number plugin is doing this already), then a tool can be made to unpack the assembly, checkout the revision and assert that everything in the source distribution comes from source control. If we can also assert that as part of each build all the license files are intact and headers are in place then I believe we're done with provenance. Licenses are present, all files have valid license headers, all files present in the source distribution come from source control, all contributions to source control are from bonafide CLA carrying Apache committers because you don't get access to commit until the CLA is on file. Sebb, reasonably accurate? Yes. One other point I made already is that I think the vote e-mail needs to be transparent to all, not just those on the PMC. Links to the output from the release process are obviously already in the mail; what is missing is the input to the process, e.g.. SCM coords. Yes, it may be possible to dig out the details from the archive, but that's not trivial. I disagree. If we focus first on a normal release, one that succeeds on the first attempt, without a respin or deleting of tags. To check provenance you would do this: 1. download the source bundle 2. unpack the source bundle 3. checkout the corresponding source code from the SCM 4. compare the two trees Right so far? What you want, if I understand you correctly, is to have the SCM URL in the vote email. So that you can give that to your SCM client in step 3. With the process we use here at the Maven project, the SCM URL is in the pom.xml file that sits in the root directory of the unpacked source bundle. All you need to do is open the file and copy the URL from there. I still fail to see how that is so
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
+1 from me On Wed, Aug 14, 2013 at 2:45 PM, Jason van Zyl ja...@tesla.io wrote: Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required) -- Dennis Lundberg
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Hi Fred, On Thu, Aug 15, 2013 at 10:48 PM, Fred Cooke fred.co...@gmail.com wrote: Actually, I missed exactly nothing!!! Your process could be flawed. Human errors do happen. The process is not flawed, but people make mistakes. The entire point of any review is to not trust process or people, and to check everything. You're effectively advocating not doing that, and this *IS* unhealthy. Why on earth would you think that I advocate not checking everything? I have just agreed that Sebb has a point in that we *should* check the source bundle against the SCM. Nobody is disputing that. That is not what this disussion is about. I know that with your process on a primary vote the tag should exist once, and only once. Someone could screw up. It happens. Your promise of we never make mistakes holds no water with me. I have never promised such a thing. People make mistakes. That is why we have review. To catch those errors. The most disturbing part of all is Sebb being persecuted and attacked and labeled a *troll* of all things for advocating due diligence. :-/ I am not attacking anyone and have not called anyone a troll. Just trying to understand the problem at hand. May I suggest that you cool down a bit. Fred. On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg denn...@apache.org wrote: On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke fred.co...@gmail.com wrote: Right so far? No, you're not. Step three, in SVN, requires reviewing history to confirm no changes were made to that URL *ever*. In Git, step 3 involves knowing the hash, as spurious tags have already been known to circulate. I don't know Git that well yet, so I won't go into a discussion about that. As for Subversion, you missed a few bits of what I wrote. I was talking about a release that is *not* respun. With our process that means that there has never been such a tag before and, if the vote passes, there will never be another one again *ever*. If someone doesn't follow our process that will become apparent during the review. Even if all of the details were in the POM, the question still remains, is this the revision you *intended* to release? Or not? ONLY you can answer this. With our process - yes it is. *always* Fred. On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg denn...@apache.org wrote: On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote: On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote: What Sebb is doing is perfectly reasonable. I agree. Checking that the source bundle is correct is good release review practice. Thank you! He's trying to assert that everything in the source ball actually comes from source control and that no errant files have made their way into the distribution. Right now we cannot assert that the assembly plugin has not wandered outside the checkout and pulled something else in, or that someone didn't accidentally put something else in the distribution. I think this unlikely but we can't assert otherwise right now which I believe is Sebb's point. It *has* already happened several times that I am aware of. The last few releases of the War plugin (various RMs voters) included at least one spurious file. So it was not just a one-off packaging - and review - failure. [See separate thread(s) for all the details; they are not germane here.] The message is that mistakes happen even in automated processes. Which is why independent comparison of input and output is valuable. If we can embed the revision from which the assembly was made in the assembly itself (and maybe the build number plugin is doing this already), then a tool can be made to unpack the assembly, checkout the revision and assert that everything in the source distribution comes from source control. If we can also assert that as part of each build all the license files are intact and headers are in place then I believe we're done with provenance. Licenses are present, all files have valid license headers, all files present in the source distribution come from source control, all contributions to source control are from bonafide CLA carrying Apache committers because you don't get access to commit until the CLA is on file. Sebb, reasonably accurate? Yes. One other point I made already is that I think the vote e-mail needs to be transparent to all, not just those on the PMC. Links to the output from the release process are obviously already in the mail; what is missing is the input to the process, e.g.. SCM coords. Yes, it may be possible to dig out the details from the archive, but that's not trivial.
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Firstly, I'm not heated up, so I can not cool down, without going into hypothermia. Secondly, I never said that *you* were doing that, just that it was being done. Thirdly, I'm super glad that you agree SCM and bundles should be compared. Fourthly, let's get on with the discussion about what it takes to do that. No, wait. Sebb and Jason already have that nailed the down. Good men, those two. Fred. On Thu, Aug 15, 2013 at 11:21 PM, Dennis Lundberg denn...@apache.orgwrote: Hi Fred, On Thu, Aug 15, 2013 at 10:48 PM, Fred Cooke fred.co...@gmail.com wrote: Actually, I missed exactly nothing!!! Your process could be flawed. Human errors do happen. The process is not flawed, but people make mistakes. The entire point of any review is to not trust process or people, and to check everything. You're effectively advocating not doing that, and this *IS* unhealthy. Why on earth would you think that I advocate not checking everything? I have just agreed that Sebb has a point in that we *should* check the source bundle against the SCM. Nobody is disputing that. That is not what this disussion is about. I know that with your process on a primary vote the tag should exist once, and only once. Someone could screw up. It happens. Your promise of we never make mistakes holds no water with me. I have never promised such a thing. People make mistakes. That is why we have review. To catch those errors. The most disturbing part of all is Sebb being persecuted and attacked and labeled a *troll* of all things for advocating due diligence. :-/ I am not attacking anyone and have not called anyone a troll. Just trying to understand the problem at hand. May I suggest that you cool down a bit. Fred. On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg denn...@apache.org wrote: On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke fred.co...@gmail.com wrote: Right so far? No, you're not. Step three, in SVN, requires reviewing history to confirm no changes were made to that URL *ever*. In Git, step 3 involves knowing the hash, as spurious tags have already been known to circulate. I don't know Git that well yet, so I won't go into a discussion about that. As for Subversion, you missed a few bits of what I wrote. I was talking about a release that is *not* respun. With our process that means that there has never been such a tag before and, if the vote passes, there will never be another one again *ever*. If someone doesn't follow our process that will become apparent during the review. Even if all of the details were in the POM, the question still remains, is this the revision you *intended* to release? Or not? ONLY you can answer this. With our process - yes it is. *always* Fred. On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg denn...@apache.org wrote: On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote: On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote: What Sebb is doing is perfectly reasonable. I agree. Checking that the source bundle is correct is good release review practice. Thank you! He's trying to assert that everything in the source ball actually comes from source control and that no errant files have made their way into the distribution. Right now we cannot assert that the assembly plugin has not wandered outside the checkout and pulled something else in, or that someone didn't accidentally put something else in the distribution. I think this unlikely but we can't assert otherwise right now which I believe is Sebb's point. It *has* already happened several times that I am aware of. The last few releases of the War plugin (various RMs voters) included at least one spurious file. So it was not just a one-off packaging - and review - failure. [See separate thread(s) for all the details; they are not germane here.] The message is that mistakes happen even in automated processes. Which is why independent comparison of input and output is valuable. If we can embed the revision from which the assembly was made in the assembly itself (and maybe the build number plugin is doing this already), then a tool can be made to unpack the assembly, checkout the revision and assert that everything in the source distribution comes from source control. If we can also assert that as part of each build all the license files are intact and headers are in place then I believe we're done with provenance. Licenses are present, all files have valid license headers, all files present in the source distribution come from
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 15 August 2013 18:50, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. So, it is a bit short sighted to declare him as troll, simply because you (the Maven PMC) decided to ignore the problem. I declared the thread as a troll not someone and BTW I'm not english native speaker so the troll word is not so rude for me :-) If it was read as something rude and a sort of personal attack so I apologize. I'm just tired by all of those threads. As described by Stephen we provide what ASF rules need. Perso I'm a volunteer here and I spend my spare time on writing code here to help our users. So my time here is limited and I prefer coding rather than waste my time on non needed procedure steps. So if someone want to add extra/over prodecure steps why not but in these case tools must be provided to ease our life. I'm a developer and yes maybe I tend to be lazy so I prefer using/writing tools to avoid manual tasks :-). That won't be too complicated as the src tarball contains the pom with scm information. But perso no time for that so I prefer to not feed troll when I don't have time to REALLY do the job. But tired of that and why? Because I heard/read so many people complaining about ASF too much bureaucratic and not a place for innovations.. Those threads are the perfect examples of that!! I just don't want to go in a too many procedures model as I can see in some projects (again especially when it's not needed) At the end the only result is: folks are just scared about releasing because it's too complicated and on vote thread they only receive comments on missing comma in a text file and/or non needed blank/spurious line in an other line but usually nothing saying: hey the new feature you added is very cool. So at the end no one release something and the project is dead (as users go somewhere else whey they got fixes for their issues or new features). And I certainly don't want to see our Maven project go in that way. My 0.02AUD /me go back to write code - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org wrote:
On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:
On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
What Sebb is doing is perfectly reasonable.
I agree. Checking that the source bundle is correct is good release review
practice.
Thank you!
He's trying to assert that everything in the source ball actually comes
from source control and that no errant files have made their way into the
distribution. Right now we cannot assert that the assembly plugin has not
wandered outside the checkout and pulled something else in, or that someone
didn't accidentally put something else in the distribution. I think this
unlikely but we can't assert otherwise right now which I believe is Sebb's
point.
It *has* already happened several times that I am aware of.
The last few releases of the War plugin (various RMs voters)
included at least one spurious file.
So it was not just a one-off packaging - and review - failure.
[See separate thread(s) for all the details; they are not germane here.]
The message is that mistakes happen even in automated processes.
Which is why independent comparison of input and output is valuable.
If we can embed the revision from which the assembly was made in the
assembly itself (and maybe the build number plugin is doing this already),
then a tool can be made to unpack the assembly, checkout the revision and
assert that everything in the source distribution comes from source control.
If we can also assert that as part of each build all the license files
are intact and headers are in place then I believe we're done with
provenance.
Licenses are present, all files have valid license headers, all files
present in the source distribution come from source control, all
contributions to source control are from bonafide CLA carrying Apache
committers because you don't get access to commit until the CLA is on file.
Sebb, reasonably accurate?
Yes.
One other point I made already is that I think the vote e-mail needs
to be transparent to all, not just those on the PMC.
Links to the output from the release process are obviously already in
the mail; what is missing is the input to the process, e.g.. SCM
coords.
Yes, it may be possible to dig out the details from the archive, but
that's not trivial.
I disagree.
If we focus first on a normal release, one that succeeds on the first
attempt, without a respin or deleting of tags.
To check provenance you would do this:
1. download the source bundle
2. unpack the source bundle
3. checkout the corresponding source code from the SCM
4. compare the two trees
Right so far?
What you want, if I understand you correctly, is to have the SCM URL in the
vote email. So that you can give that to your SCM client in step 3.
Yes.
With the process we use here at the Maven project, the SCM URL is in the
pom.xml file that sits in the root directory of the unpacked source bundle.
All you need to do is open the file and copy the URL from there. I still
fail to see how that is so much harder than to copy the URL from an email.
That is if you don't know the conventions that we use, by way of the
Release Plugin. The tag will always be in the format
${project.artifactId}-${project.version}
My point is that it should be completely transparent, even to outside reviewers.
Now, for a respun release thing are trickier. Here it might be a good idea
to include the revision number or hash, or whatever is unique in the SCM
being used.
And how do you know from a vote e-mail that it is respun?
Even though the code under review will always be under the
latest tag in the above format (at least for Subversion).
Until the next respin.
If there is a respin, and reviewers are not following the e-mails very
carefully, it would be quite easy to overlook an updated tag.
This is all about making sure that it is really obvious what the vote is about.
Publishing the SCM coordinates in the mail is trivial to do, and shows
that the input is an important part of the review process.
Having the information in the mail thread is also useful for the archives.
As others have said before, we aim to automate the release process as much
as possible. Therefor even a seemingly minor addition will be questioned,
as you have noticed, before it is included in our process.
Can you explain why the information is useful for the archives? I've seen
you mentioned that before. Isn't that moot once the release is approved?
The tag will be in Subversion for the forseable future and noone will touch
it. What am I missing?
Why would a release need to be revisited?
Perhaps someone is complaining that one of our releases contains code
it should not.
If that is the case, it helps to have the evidence of the release vote
in plain sight.
On Aug 15, 2013, at 9:01 AM, Chris Graham chrisgw...@gmail.com wrote:
Sent from my iPhone
Re: [VOTE] Release Apache Maven Model Converter version 2.3
It's funny that you cite no time and use the equivalent of 299.5 6 digit revision numbers to send us an email on your lack of time. You could have done 299 releases to Sebb's quite reasonable standards with that much keyboard activity. Point made? :-p On Fri, Aug 16, 2013 at 1:14 AM, Olivier Lamy ol...@apache.org wrote: On 15 August 2013 18:50, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Oliver, Olivier Lamy wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! The Maven PMC has made clear, that it knows about the problems and want to ignore it. However, please understand that Sebb is playing devil's advocate here, because the same release process is used for other Apache projects where the PMCs will *not* ignore this flaws. Sebb is more or less pestering you, because he is tired of having the same discussions in projects where he *is* PMC and is therefore responsible for the release. So, it is a bit short sighted to declare him as troll, simply because you (the Maven PMC) decided to ignore the problem. I declared the thread as a troll not someone and BTW I'm not english native speaker so the troll word is not so rude for me :-) If it was read as something rude and a sort of personal attack so I apologize. I'm just tired by all of those threads. As described by Stephen we provide what ASF rules need. Perso I'm a volunteer here and I spend my spare time on writing code here to help our users. So my time here is limited and I prefer coding rather than waste my time on non needed procedure steps. So if someone want to add extra/over prodecure steps why not but in these case tools must be provided to ease our life. I'm a developer and yes maybe I tend to be lazy so I prefer using/writing tools to avoid manual tasks :-). That won't be too complicated as the src tarball contains the pom with scm information. But perso no time for that so I prefer to not feed troll when I don't have time to REALLY do the job. But tired of that and why? Because I heard/read so many people complaining about ASF too much bureaucratic and not a place for innovations.. Those threads are the perfect examples of that!! I just don't want to go in a too many procedures model as I can see in some projects (again especially when it's not needed) At the end the only result is: folks are just scared about releasing because it's too complicated and on vote thread they only receive comments on missing comma in a text file and/or non needed blank/spurious line in an other line but usually nothing saying: hey the new feature you added is very cool. So at the end no one release something and the project is dead (as users go somewhere else whey they got fixes for their issues or new features). And I certainly don't want
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
+1 On 16 August 2013 06:14, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: +1 (Yeah, the vote) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 16 August 2013 08:54, Fred Cooke fred.co...@gmail.com wrote: It's funny that you cite no time and use the equivalent of 299.5 6 digit revision numbers to send us an email on your lack of time. You could have done 299 releases to Sebb's quite reasonable standards with that much keyboard activity. Point made? :-p I don't understand your behaviour Fred. You want people to change but then you attack them personally (even if you add a smiley face) As Olivier points out, this is open source volunteer work. Perhaps you could actually help out and cut some code/releases? You could even enhance the templates or release tooling to support what you are asking for. I think you would get better responses if you didn't throw stones. A worst case scenario is that those who are doing the work, don't bother. How is that helping anyone? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
Chances of understanding me: - Close friend: 50% - Other friend: 25% - Kiwi: 15% - Ozzy: 10% (that's you) - POHM: 8% - Yank: 5% - Spaniard: 1% So don't feel too bad, you had a 90% chance of failure stacked against you ;-) I'd dearly love to contribute, but I will not and can not until it's nailed down that things are being done properly, and I mean the MOJO list, not this list. Both are questionable, though. My point about the volume of text from Olivier was valid and remains valid, with or without the non-smile pokey tongue. Those 1797 characters could have quietly done a lot of good. I hope it in no way offended Olivier, and if it did, I apologise. Enhancing the template is a fruitless exercise without agreement that it should be done. Besides, I was just throwing some backup Sebb's way when he was under attack... Yours incomprehensibly, Fred On Fri, Aug 16, 2013 at 12:11 PM, Barrie Treloar baerr...@gmail.com wrote: On 16 August 2013 08:54, Fred Cooke fred.co...@gmail.com wrote: It's funny that you cite no time and use the equivalent of 299.5 6 digit revision numbers to send us an email on your lack of time. You could have done 299 releases to Sebb's quite reasonable standards with that much keyboard activity. Point made? :-p I don't understand your behaviour Fred. You want people to change but then you attack them personally (even if you add a smiley face) As Olivier points out, this is open source volunteer work. Perhaps you could actually help out and cut some code/releases? You could even enhance the templates or release tooling to support what you are asking for. I think you would get better responses if you didn't throw stones. A worst case scenario is that those who are doing the work, don't bother. How is that helping anyone? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire Plugin version 2.16
One more PMC vote would be great to get this over with... ;-) Am Donnerstag, 15. August 2013 schrieb Olivier Lamy : +1 On 12 August 2013 03:51, Andreas Gudian andreas.gud...@gmail.comjavascript:; wrote: Hi, We solved 13 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=19331 This release addresses some serious problems with character encodings in the test report XML files and adds a new Parallel Computer implementation to the JUnit 4.7+ provider, offering a bunch of new options and features around in-process parallel execution (submitted by Tibor17, thanks again!). There are still lots of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-085 https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-surefire-plugin/2.16/maven-surefire-plugin-2.16-sources.jar https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16-sources.jar Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag surefire-2.16_vote-1 Staging site: http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-failsafe-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-report-plugin/index.html Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
