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: [VOTE] Apache BatchEE 0.4-incubating
Date Mon, 26 Sep 2016 16:50:03 GMT
Was about to suggest the same. Add them all and remove the old after some time. Just to get
it propagated to the archives.


Btw: I've also added a LICENSE and NOTICE to our root in GIT. 

Please note that both files *are* available in the source release.

So again: txs for bringing it up, as it is important! But doesn't block the release again
- phew ;) 


LieGrue,
strub




> On Monday, 26 September 2016, 17:59, Stian Soiland-Reyes <stain@apache.org> wrote:
> > I think it's sufficient if you push to dist for the 0.4 release under
> vote here.
> 
> If you want to add the older versions to archive.apache.org then you
> can add them to dist and then remove them again after 24h.
> 
> 
> On 26 September 2016 at 16:52, Romain Manni-Bucau <rmannibucau@gmail.com> 
> wrote:
>>  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
> 
>>> 
>>> 
> 
> 
> 
> -- 
> 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
View raw message