On Sat, Mar 9, 2013 at 10:00 AM, sebb <seb...@gmail.com> wrote: > 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.
This is a discussion which seems to come up from time to time, like the @author tag thing and so on. Should we start a Wiki page with that kind of decisions? I think it would be useful, esp for new people. I think Benedikt has asked for such kind of docs recently. Cheers Christian >> 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 > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
