2013/3/9 Christian Grobmeier <grobme...@gmail.com> > 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. >
I have documented both, the use of SVN keywords and @author tags in the wiki: http://wiki.apache.org/commons/CodeStyle. Benedikt > > 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 > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
