incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de.INVALID>
Subject Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]
Date Tue, 27 Sep 2016 07:56:47 GMT
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 <struberg@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 <ate@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 
>>  <stain@apache.org> wrote:
>>>>>   On 26 September 2016 at 14:34, Mark Struberg 
>>  <struberg@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?dev@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-unsubscribe@incubator.apache.org
>>>   For additional commands, e-mail: general-help@incubator.apache.org
>> 
>>> 
>> 
>> 
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  For additional commands, e-mail: general-help@incubator.apache.org
>> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message