Was about to suggest the same. Add them all and remove the old after some time. Just to get it propagated to the archives.
Btw: I've also added a LICENSE and NOTICE to our root in GIT. Please note that both files *are* available in the source release. So again: txs for bringing it up, as it is important! But doesn't block the release again - phew ;) LieGrue, strub > On Monday, 26 September 2016, 17:59, Stian Soiland-Reyes <st...@apache.org> > wrote: > > I think it's sufficient if you push to dist for the 0.4 release under > vote here. > > If you want to add the older versions to archive.apache.org then you > can add them to dist and then remove them again after 24h. > > > On 26 September 2016 at 16:52, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: >> Think you lost me a bit :s >> >> so here where we started the fork from: >> > http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html >> >> About dist: should i push it there now or is that a todo for next release? >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog >> <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> >> >> 2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>: >> >>> I didn't want to start a git tag best practices war :) >>> >>> I think we agree that as long as a commit ID is in the email, and/or >>> the hash of the source distribution, then we know what we're voting > on >>> and their location is not so important. If you want to skip those, >>> then my opinion is that the release candidate must be on a >>> *.apache.org server - ideally with some kind of log. >>> >>> >>> I am flagging it mainly as I got a bit concerned when adding up >>> several issues around Batchee releases - it should be easy to fix with >>> a few svn commands on https://dist.apache.org/repos/dist/. >>> >>> The older Batchee releases are already voted over - although without >>> checksums in the email - but this is the incubator so I guess they can >>> just be dug out from >>> https://repository.apache.org/content/repositories/releases/ >>> org/apache/batchee/batchee/ >>> (ode Archaeologists go check those git tags!) >>> >>> >>> >>> >>> On 26 September 2016 at 16:22, Mark Struberg <strub...@yahoo.de> > wrote: >>> > Stian, this is established practice in the ASF since the very > early days >>> of playing with GIT. >>> > It is used e.g. in the following TLPs: >>> > TomEE >>> > DeltaSpike >>> > Johnzon >>> > CouchDB >>> > Maven >>> > and many, many more! >>> > >>> > >>> > It also got discussed on members, infra and even board lists. >>> > >>> > The nice thing about GIT is that it absolutely doesn't matter > where I >>> push the commit to as long as the sha1 of the commit later pushed to > the >>> ASF repo is the same. >>> > >>> > >>> > Regarding 'pushing something different'. I trust an ASF > member that he >>> doesn't do that. Plus we have the sha as explained before. >>> > Regarding 'not getting pushed at all': This would get > catched pretty >>> quickly as we would miss the version update ;) >>> > >>> > >>> > Also bear in mind that ASF projects do NOT vote on the tags nor > branches >>> - we solely vote on the release source distributable! >>> > >>> > >>> > >>> >> branches are there to be created and removed again >>> > Branches in GIT _cannot_ get removed from any downstream repo! >>> > >>> > That's the whole point. And if you do RCs, then you actually > would have >>> to later do a NEW vote again with the 'RC' removed from the > version. But >>> who guarantees that the source tarball is the same now? What if someone >>> changed the source in the meantime? You see, it also has flaws. >>> > >>> >> Perhaps "git tag --sign" so you get a PGP-signed tag > commit >>> > >>> >> would be a good idea? >>> > >>> > Agree, would be a good idea! >>> > It happens that I wrote the Maven GIT integration somewhen in the >>> 2000s... ;) >>> > >>> > We don't have the tagging feature yet. Could you please file a > ticket >>> against Maven SCM? >>> > >>> > >>> > txs and LieGrue, >>> > strub >>> > >>> > >>> > >>> > >>> >> On Monday, 26 September 2016, 16:34, Stian Soiland-Reyes < >>> st...@apache.org> wrote: >>> >> > On 26 September 2016 at 14:34, Mark Struberg >>> <strub...@yahoo.de.invalid> >>> >> wrote: >>> >>> We *never* push commits for in-progress votes to hte ASF > repos when >>> we use >>> >> GIT! >>> >>> The reason is that we cannot get rid of those afterwards! > Of course >>> we can >>> >> delete the branch/tag/commit from the ASF repo, but we cannot > delete >>> them from >>> >> all the hundreds downstream repos which almost immediately > pull those >>> changes... >>> >>> >>> >>> You can think of pushing this to a private (but PMC > owned!) github >>> repo as >>> >> kind of parallel to the Maven 'staging' process. >>> >> >>> >> Of course it is up to each project what particular release/tag >>> >> practice they want to follow. Many projects do this > classically even >>> >> with git, e.g. using branches or tags like 0.4-RC1 - see for > instance: >>> >> >>> >> > https://lists.apache.org/list.html?d...@jena.apache.org:lte=10M:VOTE >>> >> >>> >> Some communities like Apache Commons even keep around all RC > tags; >>> >> then archived emails around failed RCs still have valid links > - e.g. >>> >> https://github.com/apache/commons-lang/releases >>> >> >>> >> I wouldn't personally see a problem with a RC branch > showing up in >>> >> forked repositories - branches are there to be created and > removed >>> >> again - if downstream want to keep them for archival purposes > that's >>> >> their choice - just like they can keep the commit emails. >>> >> >>> >> >>> >> But if that's not your project's cup of tea, then I > guess just a >>> >> commit IDs and hashes in the email should work, no matter > where the >>> >> commit 'is' - in git the commit is hashed and it's > not forgotten >>> >> after >>> >> the vote is passed. >>> >> >>> >> Perhaps "git tag --sign" so you get a PGP-signed tag > commit would be a >>> >> good idea? >>> >> >>> >> >>> >> Without the commit ID or hashes in the email - then > particularly for >>> >> mutable release candidates tags hosted in third-party > repositories, we >>> >> don't have a record over exactly what was voted on and the > commiter >>> >> could easily by mistake push the 'wrong' RC commits or > dists without >>> >> anyone being able to notice or check later. In fact, this very > vote >>> >> shows two different commit IDs which this time luckily had the > same >>> >> content. >>> >> >>> >> Many projects posts RCs on > https://dist.apache.org/repos/dist/dev/ - >>> >> which is SVN-based - here the revision number and log is > sufficient - >>> >> we assume the ASF-hosted SVN repository to be > 'trusted'. A closed >>> >> Nexus repository is similarly tracked and immutable. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Stian Soiland-Reyes >>> >> http://orcid.org/0000-0001-9842-9718 >>> >> >>> >>> >>> >>> -- >>> Stian Soiland-Reyes >>> http://orcid.org/0000-0001-9842-9718 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org > >>> >>> > > > > -- > Stian Soiland-Reyes > http://orcid.org/0000-0001-9842-9718 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
