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
