Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Subject: Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache
 BatchEE 0.4-incubating]
To: general@incubator.apache.org
References: <CACLE=7MJewmrywoU2k0o34ZQmoQgOG4Lthab2vv9b9xP3cdcQQ@mail.gmail.com>
 <CAMBJEmW=D3-1dWr79ma7hJQ3-MxxZzN8UDYuLQLXSU321H=bXA@mail.gmail.com>
 <1960476297.769312.1474896868498@mail.yahoo.com>
 <CAMBJEmV-M5onK1L_ji0ue18L8PorMy2_QiEp=_fxN+X7TWB-0A@mail.gmail.com>
 <1320641991.899576.1474903369034@mail.yahoo.com>
 <b2d1d715-523b-eb89-49dc-bd55328c6cb4@douma.nu>
 <1837219454.1281997.1474962279912@mail.yahoo.com>
From: Ate Douma <ate@douma.nu>
Message-ID: <40d08a49-dbc4-e0f0-c6a4-fe54a8e47677@douma.nu>
Date: Tue, 27 Sep 2016 21:20:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <1837219454.1281997.1474962279912@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Tue, 27 Sep 2016 19:21:09 -0000

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


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