On 9 March 2013 00:39, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I'm not sure I understand what the big deal is. Sebb vetoed a commit and > identified exactly what needed to be changed for him to remove the veto. If > the requested change is made then all should be fine with the world again. > Sure, he could have said all the same words without the -1 but then it > wouldn't be evident that he expected the change to be made.
Thanks. Yes, I agree that it was perhaps unnecessary for the -1, but we had already agreed some while ago not to use $Date$ and I did not want to see that creep back in again. > Ralph > > > On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote: > >> >> >> Niall Pemberton <niall.pember...@gmail.com> wrote: >> >>> On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas <ma...@apache.org> wrote: >> >> <snip/> >> >>>> One of the primary responsibilities of a PMC member when voting on a >>>> release is verifying what is being voted on against the tag. >>> Different >>>> client locales and $Date$ combine to make every single source file >>>> different from the tag requiring a manual check of the diff of every >>>> file to do the verification check properly. Even with good diff >>> tooling >>>> the verification process is a lot slower and can't be automated. >>> >>> Its not required for a release - although I would agree its a nice >>> thing to do.Spot check of the files is good enough to see if it has >>> been created from the tag >> >> I very strongly disagree. Any PMC member voting on a release should be >> verifying every single file in the src tarball with the tag. There are >> plenty of tools available that make this the work of a few seconds - >> providing the files agree. >> >>> - otherwise we trust our release managers. >> >> Not trusting the release managers is not the primary reason that PMC >> members should be verifying the tarball agrees with the tag (although if >> a release manager ever does do anything malicious it will catch that >> to). The primary reason is to catch errors in build process or mistakes >> made by the release manager. BeanUtils is likely simpler than Tomcat but >> the sorts of things a full verification has caught has included: >> - missing files (usually after some form of code re-org) >> - extra files (IDE files, intermediate files, .svn/.git files, >> build.properties etc) >> - wrong line endings (Tomcat tries to use CRLF for zip and LF for tar.gz) >> - local edits to the source files >> >> Some are minor but missing or edited files are clearly serious issues >> that should cause the release to fail. >> >>> BeanUtils has used the $Date$ keyword since 2005 and I cannot remember >>> it ever coming up in a release vote - so it hasn't stopped it being >>> released. >> >> If the release manager and the people checking the tarball all have the >> same locale you won't see the issue. >> >> Mark >> >> --------------------------------------------------------------------- >> 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
