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