Hi Ate! Note that the proposed handling is only a 'best practice' tip. It is _not_ mandated. No need to veto the release just because they do it different.
If a project does -RCx then it's legally also fine for the ASF. It is just much more work and possibly confusing to users (which browse the branches and tags). In other words: it's not wrong neither, but the project will end up with a polluted git repo ;) If you have some time then think through the process described at the DeltaSpike site. And we probably can even extract a common guideline for the incubator (or even top level). LieGrue, strub > On Tuesday, 27 September 2016, 21:21, Ate Douma <a...@douma.nu> wrote: > > Hi Mark, > > On 2016-09-27 09:44, Mark Struberg 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. >> > Thanks for the clear pointers: that'll get me going :-) > >> >> But I agree it might be time to collect all these informations together and > write an incubator compendium for it. > > Yeah I think so. > > I've just reviewed and gave a +1 a release candidate for Streams, which now > possibly might not yet be in line with the suggested Git tagging policy... > > I now will have to check again for this too. > And if it isn't, well. That would rather annoying, because it hasn't > been > documented in the incubator guidelines yet. > > Ate > >> >> 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 >> > > > --------------------------------------------------------------------- > 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
