On Sat, Mar 9, 2013 at 12:32 PM, sebb <seb...@gmail.com> wrote: > On 9 March 2013 11:56, Niall Pemberton <niall.pember...@gmail.com> wrote: >> On Sat, Mar 9, 2013 at 9: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. >> >> No, you miss the point - not "unnecessary" - it was an invalid veto >> and you should be more circumspect about casting vetos. > > I think it's borderline.
No, not even close - it was an invalid veto - which have to be for valid *technical* reasons. > I would have voted -1 on the RC, because the tag would not agree with > the source archive. That IMO would have been unfortunate - but votes and vetos are two completely different things - since a veto *forces" a change - whereas a -1 vote is by majority and therefore doesn't mean the release would have been stopped. Niall >> Niall >> >> >>>> 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
