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 19:51:53 GMT
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 <ate@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 <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
> 

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


Mime
View raw message