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.
> 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. > 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 > >
