incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [VOTE] Apache BatchEE 0.4-incubating
Date Mon, 26 Sep 2016 15:52:49 GMT
Think you lost me a bit :s

so here where we started the fork from:
http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html

About dist: should i push it there now or is that a todo for next release?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes <stain@apache.org>:

> I didn't want to start a git tag best practices war :)
>
> I think we agree that as long as a commit ID is in the email, and/or
> the hash of the source distribution, then we know what we're voting on
> and their location is not so important.  If you want to skip those,
> then my opinion is that the release candidate must be on a
> *.apache.org server - ideally with some kind of log.
>
>
> I am flagging it mainly as I got a bit concerned when adding up
> several issues around Batchee releases - it should be easy to fix with
> a few svn commands on https://dist.apache.org/repos/dist/.
>
> The older Batchee releases are already voted over - although without
> checksums in the email - but this is the incubator so I guess they can
> just be dug out from
> https://repository.apache.org/content/repositories/releases/
> org/apache/batchee/batchee/
> (ode Archaeologists go check those git tags!)
>
>
>
>
> On 26 September 2016 at 16:22, Mark Struberg <struberg@yahoo.de> 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 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
> >>
>
>
>
> --
> 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