On Mon, Sep 26, 2016 at 11:23 AM Mark Struberg <strub...@yahoo.de.invalid> 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. > This is all discussed long ago. Many enhancements have been made since then. It doesn't mean that either side is wrong though. I would say its OK to have the tag on an unofficial mirror. > > 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! > This is incorrect. Infra specifically maintains protected and unprotected branches. Unprotected branches can be deleted and get sync'd on next push. > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
