commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
Date Sat, 09 Mar 2013 15:54:49 GMT
2013/3/9 Christian Grobmeier <grobmeier@gmail.com>

> On Sat, Mar 9, 2013 at 10:00 AM, sebb <sebbaz@gmail.com> wrote:
> > On 9 March 2013 00:39, Ralph Goers <ralph.goers@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.pemberton@gmail.com> wrote:
> >>>
> >>>> On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas <markt@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message