PS: back then I also summed up information about the difference between SVN and GIT regarding handling from a user pov http://wiki.apache.org/couchdb/SVNvsGIT
Most of it is nowadays common knowledge I hope, but some might still find it useful. LieGrue, strub > On Tuesday, 27 September 2016, 9:44, Mark Struberg <strub...@yahoo.de> wrote: > > Hi Ate! > > It's quite natural that many other projects just point to DeltaSpike. > DS was in 2011 amongst the very first projects using GIT at the ASF. > > One of the results of this effort (together with the CouchDB community) was > following document > http://wiki.apache.org/couchdb/Git_At_Apache_Guide > > Note the paragraph "Tagging during a VOTE": > "Please note that the only officially result of an ASF release is the > source tarball! These zipped and signed sources are also the only thing a > VOTE > is upon. All other artifacts produced during a build are just nice to have > goodies which are no official ASF products. This includes the TAG on any SCM > hosted at the ASF or elsewhere" > > > This (and many other GIT questions) also got heavily discussed at the 2014 > ApacheConEU. > Search the private repos for "[DISCUSS] sandbox GIT repo for each of our > projects using GIT". > And you will find many other GIT discussions in that timeframe around Mid > 2012 > and Nov/Dec 2014. > There have been dozen other times when this did pop up, e.g. search > "Immediate change to git". > > > And it also just recently (August 2016) got discussed on this very list here. > See the "Ease of release process and exit criteria" thread. > > > But I agree it might be time to collect all these informations together and > write an incubator compendium for it. > > LieGrue, > strub > > > > > >> On Monday, 26 September 2016, 22:09, Ate Douma <a...@douma.nu> wrote: >> > Hi Mark, >> >> On 2016-09-26 17:22, Mark Struberg 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 suggestion 'this' is established practice in the ASF made me > wonder. >> So I tried to lookup some reference, background and/or discussion around > it. >> But I have not been able to find anything! >> Of the above listed projects, only DeltaSpike actually has a page > describing >> *what* to do, written by you, but otherwise: nothing AFAICT. >> I also briefly scanned the members and board lists, seeing if I somehow > missed a >> crucial discussion about this in the last several years. >> But nothing jumped out to me what might be related. >> >> I haven't been really actively involved (much) in ASF projects using > git >> so far, so it didn't really matter much to me yet until now. >> And I probably didn't try hard enough researching it either. >> >> But if this really is an established practice, then at least it should be > easy >> to find and properly described, somewhere. Especially as some incubator > guide. >> So where is or was this discussed, do you have some pointers? >> >> Thanks, Ate >> >> >>> >>> 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 >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
