On 07/09/2020 15:40, Rob Tompkins wrote: > Also, I would think we should be as accommodating as possible to Mark as he > is indeed the top maintainer on [daemon]. I doubt we’d be making progress > there with out him. > > I’ve found his [VOTE] threads to be entirely sufficient for validation > despite their differences in content. I’m. +1 for continuing here until I can > perform a [daemon] release myself using the [commons-release-plugin] as an > exercise. > > @Mark - do you have any opinions on my attempting a [daemon] release in the > future for said exercise?
You are welcome to try but the bulk of the work is building the Windows native binaries and doing so in a way that ensures you don't create unwanted dependencies on various Windows runtimes. I'm not sure the release plug-in would handle that. See the section on Windows (procrun)release builds here: https://github.com/apache/commons-daemon/blob/master/src/native/windows/README.txt Once you have a suitable VM (or other Windows build environment set up) it is fairly simple. The hard part was all the work Mladen did to define that build environment. The jsvc build is all scripted and documented in: https://github.com/apache/commons-daemon/blob/master/HOWTO-RELEASE.txt The Java side of things should be trivial. My (limited) understanding of Maven is that the accepted way to do non-standard things is to write a Maven plug-in. My sense is more time would be required to write and maintain the plug-in than is taken doing the builds with the current combination of scripts and manual steps. Mark > > Cheers, > -Rob > >> On Sep 7, 2020, at 10:27 AM, sebb <seb...@gmail.com> wrote: >> >> Suppose we take the following example: >> >> https://lists.apache.org/thread.html/c99519e1c8e0a4af5be02f40e8e44b408cbc3d4568a334f3a400b94f%40%3Cdev.commons.apache.org%3E >> >> This is Commons Daemon 1.2.0 based on RC2. >> >> Take for example: >> >> https://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.2.0-native-src.tar.gz >> with sha256: >> 13c8d9b27d38ae1ced1fb37743239035cd1add74a8ef20bfce38386fc0b4a243 >> *commons-daemon-1.2.0-native-src.tar.gz >> >> How does one show that it is the same source that was voted on? >> >> Also the Maven jar: >> >> commons-daemon-1.2.0.jar >> sha1: >> a3a42da759a94a0522fe4b867ac2f5d0d58cc0a9 >> >> Sebb. >> >>> On Mon, 7 Sep 2020 at 14:16, Gilles Sadowski <gillese...@gmail.com> wrote: >>> >>> Hello. >>> >>>>> [...] >>>>> see an explanation for why it is necessary >>>>> (or even helpful) to include artefact hashes in the vote mail. >>>>> >>>> I agree and understand all your points here. >>> >>> Well, I don't. >>> An explanation would be useful indeed. >>> >>>>> Validating the svn revision for the dist repo [ ... vs ...] >>>>> comparing the hashes of each file to a hash provided in >>>>> the vote email. [...] >>>> >>>> I was merely trying to offer the opposing perspective of the other folks. >>> >>> Aren't we talking about a *requirement*? >>> Referring to the "executive summary" above (as I understand it), >>> from Mark's edited text, which information is necessary and sufficient >>> for a vote? >>> >>> Also, isn't this discussion a rehash of my (recurrent) question >>> about whether the hash checks should be automated? >>> [I mean, isn't it sufficient that the RM would indicate in the vote >>> email that the hash values stored in the "dist" area are the same >>> as those generated by the build?] >>> >>> Regards, >>> Gilles >>> >>>>>> [...] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
