On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas <ma...@apache.org> wrote: > On 07/03/2013 23:39, Niall Pemberton wrote: >> On Sun, Mar 3, 2013 at 3:32 PM, sebb <seb...@gmail.com> wrote: >>> On 3 March 2013 13:25, <brit...@apache.org> wrote: >>>> Author: britter >>>> Date: Sun Mar 3 13:25:24 2013 >>>> New Revision: 1452037 >>>> >>>> URL: http://svn.apache.org/r1452037 >>>> Log: >>>> Add JavaDoc and SVN Keywords >>> >>> -1 >>> >>> Please don't use $Date$ - it is rendered using the client Locale, and >>> so causes problems matching SVN tags against source archives. > > <snip/> > >> It is also an >> invalid veto IMO because this is purely documentation AND it is only a >> question of style. > > I disagree. Sebb's point regarding the locale issues is a valid one. > Something that makes it significantly harder to verify that a source > tarball agrees with an SVN tag is a major issue when it comes to voting > on releases.
This IMO is not a technical justification, but a bureaucratic one and I still believe casting a veto on documentation style is not valid IMO. > 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 - otherwise we trust our release managers. 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. But back to the main point here, I don't object to anyone with the desire to do this making the change - but I do disagree with it being a veto. Niall > Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
