incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: [VOTE] Apache BatchEE 0.4-incubating
Date Mon, 26 Sep 2016 15:25:25 GMT
On Mon, Sep 26, 2016 at 11:23 AM Mark Struberg <struberg@yahoo.de.invalid>
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.
>

This is all discussed long ago.  Many enhancements have been made since
then.  It doesn't mean that either side is wrong though.  I would say its
OK to have the tag on an unofficial mirror.


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

This is incorrect.  Infra specifically maintains protected and unprotected
branches.  Unprotected branches can be deleted and get sync'd on next push.


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message