You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Thomas <ma...@apache.org> on 2013/03/08 11:15:55 UTC
[OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Niall Pemberton <ni...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by Benedikt Ritter <br...@apache.org>.
2013/3/9 Christian Grobmeier <gr...@gmail.com>
> On Sat, Mar 9, 2013 at 10:00 AM, sebb <se...@gmail.com> wrote:
> > On 9 March 2013 00:39, Ralph Goers <ra...@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 <ni...@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by Christian Grobmeier <gr...@gmail.com>.
On Sat, Mar 9, 2013 at 10:00 AM, sebb <se...@gmail.com> wrote:
> On 9 March 2013 00:39, Ralph Goers <ra...@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 <ni...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 9, 2013 at 12:32 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2013 11:56, Niall Pemberton <ni...@gmail.com> wrote:
>> On Sat, Mar 9, 2013 at 9:00 AM, sebb <se...@gmail.com> wrote:
>>> On 9 March 2013 00:39, Ralph Goers <ra...@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 <ni...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by James Carman <ja...@carmanconsulting.com>.
A -1 on a code modification proposal (in this case the code was already
changed, but i think it still applies) is called a veto by the ASF. If
accompanied by a valid technical justification, it stands (unless the
person can be talked out of it).
http://www.apache.org/foundation/voting.html
On Wednesday, March 13, 2013, Gary Gregory wrote:
> Hi All:
>
> It seems to me that we are misusing the term veto. A release cannot be
> vetoes, it can be VOTEd on with a -1, which is not a veto, but is usually
> interpreted as one, by me, at least, as a courtesy to my fellow PMD member
> for putting the time in to care.
>
> You can -1 a commit which is not really a veto either because the change as
> already happened and requires someone to do the reverting.
>
> So maybe we should not get all hung up on vetoes.
>
> My beef around here is how $%@^ hard to is make publish a release :(
>
> Gary
>
>
> On Wed, Mar 13, 2013 at 8:25 AM, James Carman
> <jcarman@carmanconsulting.com <javascript:;>>wrote:
>
> >
> > On Mar 12, 2013, at 12:36 PM, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> > >
> > > In which case, vetoing the commit that causes the problem makes more
> > > sense, surely?
> > >
> >
> > Perhaps we should set up a Sonar rule to catch stuff like this to save
> you
> > the trouble of trolling the SVN commit log messages.
> >
> > The veto was unnecessary. It's a wonder we keep any committers around
> > here.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com <javascript:;> | ggregory@apache.org<javascript:;>
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by Gary Gregory <ga...@gmail.com>.
Hi All:
It seems to me that we are misusing the term veto. A release cannot be
vetoes, it can be VOTEd on with a -1, which is not a veto, but is usually
interpreted as one, by me, at least, as a courtesy to my fellow PMD member
for putting the time in to care.
You can -1 a commit which is not really a veto either because the change as
already happened and requires someone to do the reverting.
So maybe we should not get all hung up on vetoes.
My beef around here is how $%@^ hard to is make publish a release :(
Gary
On Wed, Mar 13, 2013 at 8:25 AM, James Carman
<jc...@carmanconsulting.com>wrote:
>
> On Mar 12, 2013, at 12:36 PM, sebb <se...@gmail.com> wrote:
> >
> > In which case, vetoing the commit that causes the problem makes more
> > sense, surely?
> >
>
> Perhaps we should set up a Sonar rule to catch stuff like this to save you
> the trouble of trolling the SVN commit log messages.
>
> The veto was unnecessary. It's a wonder we keep any committers around
> here.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by James Carman <jc...@carmanconsulting.com>.
On Mar 12, 2013, at 12:36 PM, sebb <se...@gmail.com> wrote:
>
> In which case, vetoing the commit that causes the problem makes more
> sense, surely?
>
Perhaps we should set up a Sonar rule to catch stuff like this to save you the trouble of trolling the SVN commit log messages.
The veto was unnecessary. It's a wonder we keep any committers around here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by sebb <se...@gmail.com>.
On 12 March 2013 11:17, James Carman <jc...@carmanconsulting.com> wrote:
>
> On Mar 9, 2013, at 7:32 AM, sebb <se...@gmail.com> wrote:
>>
>> I would have voted -1 on the RC, because the tag would not agree with
>> the source archive.
>>
>
> However, releases cannot be vetoed.
In which case, vetoing the commit that causes the problem makes more
sense, surely?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by James Carman <jc...@carmanconsulting.com>.
On Mar 9, 2013, at 7:32 AM, sebb <se...@gmail.com> wrote:
>
> I would have voted -1 on the RC, because the tag would not agree with
> the source archive.
>
However, releases cannot be vetoed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by sebb <se...@gmail.com>.
On 9 March 2013 11:56, Niall Pemberton <ni...@gmail.com> wrote:
> On Sat, Mar 9, 2013 at 9:00 AM, sebb <se...@gmail.com> wrote:
>> On 9 March 2013 00:39, Ralph Goers <ra...@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.
I would have voted -1 on the RC, because the tag would not agree with
the source archive.
> Niall
>
>
>>> Ralph
>>>
>>>
>>> On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
>>>
>>>>
>>>>
>>>> Niall Pemberton <ni...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 9, 2013 at 9:00 AM, sebb <se...@gmail.com> wrote:
> On 9 March 2013 00:39, Ralph Goers <ra...@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.
Niall
>> Ralph
>>
>>
>> On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
>>
>>>
>>>
>>> Niall Pemberton <ni...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by sebb <se...@gmail.com>.
On 9 March 2013 00:39, Ralph Goers <ra...@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 <ni...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Posted by Ralph Goers <ra...@dslextreme.com>.
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.
Ralph
On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote:
>
>
> Niall Pemberton <ni...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org