Sounds a good idea for me (probably until someone else complain :-) ). And if that stop discussions and move people to working on code/fixing issues (i.e something very important for users) that will be great!
2013/6/27 Mirko Friedenhagen <mfriedenha...@gmail.com>: > Hello there, > > when. respinning a release it would of help IMO instead of deleting the tag > to rename it to e.g. maven-javadoc-plugin-2.9-rc1 using "svn mv". > > By means of this you are able to easily diff between e.g. released 2.8 and > the final 2.9 as well as between 2.9-rc1 and the final 2.9. > > Regards Mirko > -- > Sent from my mobile > On Jun 26, 2013 12:14 PM, "sebb" <seb...@gmail.com> wrote: > >> On 26 June 2013 10:56, Chris Graham <chrisgw...@gmail.com> wrote: >> > On Wed, Jun 26, 2013 at 7:06 PM, sebb <seb...@gmail.com> wrote: >> > >> >> I meant: if the pom is created with the correct final URLs in the >> >> first place, it won't have to be changed. >> >> >> >> >> > They are. If you'd used the release plugin, then you would have seen >> this. >> > >> >> I was responding to this: >> >> >>> >> On 26 June 2013 01:04, Chris Graham <chrisgw...@gmail.com> wrote: >> > -1 >> > Except then the poms will point to the wrong place. >> <<< >> >> but maybe I misunderstood. >> >> > >> >> It might need a tweak to the appropriate plugin, but it's not >> >> impossible to achieve. >> >> >> > >> > You've not clearly stated what it is that you actually intend to achieve. >> >> I thought I stated that clearly in my original post at the start of this >> thread. >> >> > >> >> The same process would work with the system used by Lucene. >> >> >> >> No, it wouldn't. From my reading of that email, there appeared to be far >> > more manual steps involved, and probably a far larger time window >> involved >> > as well. But I'd have to grok it a little more to be sure. >> > >> > >> >> >> >> >> > On 26 June 2013 06:48, Hervé BOUTEMY <herve.bout...@free.fr> wrote: >> >> > the jar content isn't updated: so you have jar artifacts inconsistent >> >> with svn >> >> > >> >> > Le mercredi 26 juin 2013 01:08:59 sebb a écrit : >> >> >> 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 >> >> > >> >> > --------------------------------------------------------------------- >> >> > 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 >> >> -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
