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
