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. http://creadur.apache.org/rat/apache-rat-plugin/dependencies.html is listing the -SNAPSHOT dependencies and is not the site of the latest *release* (we'll ignore that they have now switched their skin to not show the version because they won't follow the "correct" release process) If that PMC wants to release software some "crazy" way, I am not going to stop them... but it is bad form the way they are publishing their site and not updating it with the released artifact site. > So, it is a bit short > sighted to declare him as troll, simply because you (the Maven PMC) decided > to ignore the problem. > He knows our position. If he wants to discuss with us, can take it up with us on private@maven and if he still has issues he can raise it with the board. Instead of following that approach, we get the same noise on our votes... which only seems like a "I'm going to win this argument through exhaustion" tactic. I am genuinely interested in ensuring that this PMC releases software correctly, but as of yet, other than restating an immovable thought position, I have not seen a compelling argument from Sebb that addresses this PMC's justification of our position. I will not pre-judge Sebb as a troll, but his current actions are contributing to making him appear as such -Stephen > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
