On 26 June 2013 01:04, Chris Graham <chrisgw...@gmail.com> wrote: > -1 > Except then the poms will point to the wrong place.
Depends how the poms are updated. > > > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory <garydgreg...@gmail.com>wrote: > >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <seb...@gmail.com> wrote: >> >> > It would be a lot better to use RC1 RC2 etc initially, and copy the >> > successful tag to the GA tag. >> > >> >> +1 ! :) >> >> Gary >> >> >> > >> > On 25 June 2013 19:38, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a >> failed >> > release vote instead of deleting them. >> > > >> > > >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: >> > > >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers < >> > ralph.go...@dslextreme.com>wrote: >> > >> >> > >>> Again I have to disagree. The release manager will send an email >> > closing >> > >>> the prior release. At this point all the prior release artifacts are >> > junk >> > >>> even if they still exist. At some point the release manager will >> > delete >> > >>> the tag and rerun the release. >> > >> >> > >> >> > >> That's a no-no IMO. Tags that have been voted on should never be >> > deleted. >> > >> >> > >> Gary >> > >> >> > >> >> > >> >> > >>> At this point the tag is still junk to everyone else because they >> have >> > no >> > >>> idea what the RM is doing - so they shouldn't be making assumptions >> > about >> > >>> non-released tags. Once he sends the email though the tag will be >> > valid. >> > >>> Sure having the revision number helps but unless the RM completely >> > screws >> > >>> up the tag should be sufficient. >> > >>> >> > >>> Ralph >> > >>> >> > >>> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: >> > >>> >> > >>>> Not really, no. The developer may have re-spun it again and be about >> > to >> > >>>> email again. You have no idea what you're looking at unless you know >> > the >> > >>>> revision. SVN will die off within a decade and this discussion will >> > >>> become >> > >>>> critical. Better to figure out how to support proper techniques now, >> > >>> rather >> > >>>> than wait until forced to. >> > >>>> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers < >> > ralph.go...@dslextreme.com >> > >>>> wrote: >> > >>>> >> > >>>>> I disagree that the revision is required. I know that the RM is >> > going >> > >>> to >> > >>>>> recreate the tag with each release candidate. Therefore, so long >> as >> > I >> > >>>>> refetch that tag for every release vote I can be confident that I >> am >> > >>>>> reviewing the release contents. >> > >>>>> >> > >>>>> Ralph >> > >>>>> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote: >> > >>>>> >> > >>>>>> The mission of the ASF is to release software as source, and to >> > ensure >> > >>>>>> that the released source is available under the Apache Licence. >> > >>>>>> >> > >>>>>> Before a release can be approved it must be voted on by the PMC. >> > >>>>>> The review process needs to establish that the proposed source >> > release >> > >>>>>> meets those aims. >> > >>>>>> >> > >>>>>> It's all but impossible for reviewers to examine every single file >> > in >> > >>>>>> a source archive to determine if it meets the criteria. >> > >>>>>> And it's not unknown for spurious files to creep into a release >> > >>>>>> (perhaps from a stale workspace - are releases always built from a >> > >>>>>> fresh checkout of the tag?) >> > >>>>>> >> > >>>>>> However, PMCs are also required to check what is added to the SCM >> > >>>>>> (SVN/Git) to make sure it meets the required license criteria. >> > >>>>>> This is done on an ongoing basis as part of reviewing check-ins >> and >> > >>>>>> accepting new contributions. >> > >>>>>> So provided that all the files in the source release are also >> > present >> > >>>>>> in SCM, the PMC can be reasonably sure that the source release >> meets >> > >>>>>> the ASF criteria. >> > >>>>>> >> > >>>>>> Without having the SCM as a database of validated files, there are >> > far >> > >>>>>> too many files in the average source archive to check >> individually. >> > >>>>>> And how would one check their provenance? The obvious way is to >> > >>>>>> compare them with the entries in SCM. >> > >>>>>> >> > >>>>>> Therefore, I contend that a release vote does not make sense >> without >> > >>>>>> the SCM tag. >> > >>>>>> In the case of SVN, since tags are not immutable, the vote e-mail >> > also >> > >>>>>> needs the revision. >> > >>>>>> >> > >>>>>> Whether every reviewer actually checks the source archive against >> > SCM >> > >>>>>> is another matter. >> > >>>>>> But if the required SCM information is not present, it would be >> > >>>>>> difficult to argue that the RM had provided sufficient information >> > for >> > >>>>>> a valid review to take place. >> > >>>>>> >> > >>>>>> >> > --------------------------------------------------------------------- >> > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >> > >>>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> --------------------------------------------------------------------- >> > >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >> > >>>>> >> > >>>>> >> > >>> >> > >>> >> > >>> --------------------------------------------------------------------- >> > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >>> For additional commands, e-mail: dev-h...@maven.apache.org >> > >>> >> > >>> >> > >> >> > >> >> > >> -- >> > >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> > >> Java Persistence with Hibernate, Second Edition< >> > http://www.manning.com/bauer3/> >> > >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> > >> Spring Batch in Action <http://www.manning.com/templier/> >> > >> Blog: http://garygregory.wordpress.com >> > >> Home: http://garygregory.com/ >> > >> Tweet! http://twitter.com/GaryGregory >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > > For additional commands, e-mail: dev-h...@maven.apache.org >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition< >> http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
