Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Stian Soiland-Reyes]

On 28 September 2016 at 16:40, Mark Struberg  wrote:
> But otoh if a project decides to use -RC1..17 it's also fine.
> BUT: they pollute their branches and tags and they actually would need to do 
> a 2nd VOTE afterwards on the .Final release. So it is much more work and thus 
> not recommended. But otoh it's not a blocker neither.

They will not need a second vote to retag from say "0.5.0-RC3" to
"0.5.0" - the whole point of a VOTE is to decide if a RC is to going
out as the version it aspires to. It just means you have to use the
"RCx" string only in the tag name and dist directories, not inside the
candidate's  strings or filenames.

(Apache projects can also distribute milestone releases - but to avoid
confusion those should not be called "Release Candidates" but rather
'alpha2' etc. and are still formally an "Apache release" with their
own RCs- see https://www.apache.org/dev/release.html#release-types )


Projects are not required to do a vote to make a git tag. They are
required to make a vote to publish a release artifact (by policy the
upload to http://www.apache.org/dist). And as you said, the git commit
is (somewhat) cryptographically sound (sha1 has known collisions)  -
so assigning another tag for the commit that was approved (and
referenced) in VOTE is not another release.


One complicating factor is that GitHub will list any tag as a
"Release": See for instance

https://github.com/apache/incubator-commonsrdf/releases

The tag "apache-import-20150327" was not a release, but is clearly a
good use-case for tagging - in fact I think every SG-imported code
should have such a tag (ideally with --sign).  So a -RC tag will be
listed as a "Release" on GitHub while it's under vote - I can see that
is not good. A workaround would be to use a branch instead - which is
more clearly a moving target.


Perhaps it's possible to enquire with INFRA if there are particular
tags that can be filtered out from the mirroring.


A deleted -RC tag disappears from the main GitHub repository - however
they might appear in forks - not a big deal to me - downstream forks
could also add arbitrary "release" tags in their forks if they so
like. The impact of this varies a bit with the popularity of the
project - something widely known like Groovy is more of risk of having
their Release Candidates sneak into production "out there". (which is
OK as long as they don't call it "Apache Groovy").

I think each project can (and should) decide this - we can list these
pros and cons in the recommendation.


Some projects (incubator and TLP) might have done a VOTE, and then
push out binary and source artifacts to say Maven Central without a
corresponding git tag or source release in dist. This is of course bad
practice - but not what we are talking about here.

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

[RESULT][VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

And here is my +1

So we have 3 +1 bindings (Justin, JB, me) and 1 +1 non binding (Stian) and
no other votes so the release passes.

Thanks to all who had a look.

Will continue with the release steps.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-09-27 12:50 GMT+02:00 Stian Soiland-Reyes :

> OpenJDK 1.8.0 from Ubuntu 16.04.
> Java version: 1.8.0_91, vendor: Oracle Corporation
>
> It seems it was a threading issue as I was using the optimistic -T1.0C
> - which of course is not required to work. My fault!
>
> The build works now (but of course takes a bit longer :).
>
> [INFO] BUILD SUCCESS
>
> My vote changed to +1 (non-binding) -  if you carry over your three
> IPMC-binding votes you should be good to go.
>
>
> On 27 September 2016 at 11:27, Mark Struberg 
> wrote:
> > That's weird. Which Java version do you exactly use?
> > I did run the full build with java7 and it passed perfectly fine.
> >
> >
> > LieGrue,
> > strub
> >
> >
> > On Tuesday, 27 September 2016, 12:24, Stian Soiland-Reyes <
> st...@apache.org> wrote:
> >>-0 (non-binding)  -- changes my previous -1 vote after dist/ was
> populated.
> >>
> >>I'm afraid it's not positive vote from me as the unit tests were
> >>failing the build, otherwise I would say +1. But feel free to ignore
> >>this vote :)
> >>
> >>
> >>-1 .md5 .sha1 missing from dist
> >>+1 valid .asc signature
> >>-1 KEYS file missing
> >>+1 dist matches mvn (same sha1 of batchee-0.4-incubating-source-
> release.zip)
> >>+1 LICENSE
> >>+0 NOTICE:  should say "Apache Batchee" instead of "Batchee".
> >>Copyright should be 2013-2016 (or so), not just 2016.
> >>-0 DISCLAIMER present - but it says "Apache Sirona" instead of "Apache
> >>BatchEE" (already fixed in git)
> >>+1 no binaries in source archive
> >>+1 mvn apache-rat:check (but jbatch/.../jaxb/* don't have ASF headers)
> >>-1 mvn clean install fails
> >>+1 source kind of match git commit
> >>985047e8cefb46056fcb0bda36af096a0d228fa2 (except LICENSE, NOTICE,
> >>.gitignore, DEPENDENCIES)
> >>-0 git tag missing LICENSE, NOTICE (already fixed in git master)
> >>
> >>
> >>I would recommend for the JAXB generated files to use the
> >>maven-jaxb-plugin from src/main/xsd so that the generated files end up
> >>in target/generated-sources instead of being checked in.  If they have
> >>to stay (e.g. because they have been modified post generation (uh
> >>oh..)) then they should have the ASF header as they are derived from
> >>the ASF-licensed xsds.
> >>
> >>
> >>Build failure:
> >>
> >>[INFO] BatchEE :: GUI :: JAXRS :: Server .. FAILURE [
> 19.111 s]
> >>
> >>Tests run: 9, Failures: 1, Errors: 8, Skipped: 0, Time elapsed: 3.912
> >>sec <<< FAILURE! - in org.apache.batchee.jaxrs.server.RestTest
> >>getRunningExecutions(org.apache.batchee.jaxrs.server.RestTest)  Time
> >>elapsed: 0.772 sec  <<< FAILURE!
> >>java.lang.AssertionError: expected:<500> but was:<404>
> >>at org.junit.Assert.fail(Assert.java:88)
> >>at org.junit.Assert.failNotEquals(Assert.java:834)
> >>at org.junit.Assert.assertEquals(Assert.java:645)
> >>at org.junit.Assert.assertEquals(Assert.java:631)
> >>at org.apache.batchee.jaxrs.server.RestTest.
> getRunningExecutions(RestTest.java:82)
> >>
> >>
> >>and then loads of these:
> >>
> >>getJobExecution(org.apache.batchee.jaxrs.server.RestTest)  Time
> >>elapsed: 0.079 sec  <<< ERROR!
> >>org.apache.cxf.jaxrs.client.ServerWebApplicationException:
> >>Apache Tomcat/7.0.50 - Error
> >>report HTTP Status 404 -
> >>/batchee-gui/api/batchee/job-execution/0 >>noshade="noshade">type Status reportmessage
> >>/batchee-gui/api/batchee/job-execution/0description
> >>The requested resource is not available. >>noshade="noshade">Apache Tomcat/7.0.50
> >>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:791)
> >>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:749)
> >>at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:365)
> >>at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:501)
> >>at org.apache.batchee.jaxrs.server.Res

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[David Nalley]

On Mon, Sep 26, 2016 at 4:09 PM, Ate Douma  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?
>

There is precedent both ways. It's been discussed pretty heavily in
specific instances, but AFAIK, no policy exists.
If you're interested in backstory of two examples, look at board@
discussions on AsterixDB using Gerrit and Usergrid using Github.

Sam has also written a document up that discusses the nuances of DVCS
and how commits land in ASF git repo and the fact that 'canonical'
doesn't really exist in the way we think it does for DVCSes.

--David

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

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Mark Struberg]

Hi Jochen!


The discussion was about whether a local release build (GIT runs locally and a 
'commit' doesn't push to the canonical ASF repo) should immediately get pushed 
to the ASF repo or just to a PMC owned 'other' GIT repo (e.g. on github). 


In various projects we prefer pushing to github because it doesn't pollute the 
ASF repo in case the VOTE needs to get cancelled. Remember that you cannot 
effectively delete a commit/branch/tag from our repos as they almost 
immediately get pulled downstream. 

And as the sha1 is cryptographically strong it is guaranteed that when the VOTE 
succeeds we get the exact content which was voted upon pushed to the ASF repo 
anyway.


But otoh if a project decides to use -RC1..17 it's also fine.
BUT: they pollute their branches and tags and they actually would need to do a 
2nd VOTE afterwards on the .Final release. So it is much more work and thus not 
recommended. But otoh it's not a blocker neither.


LieGrue,
strub




> On Wednesday, 28 September 2016, 16:13, Jochen Wiedmann 
>  wrote:
> > On Mon, Sep 26, 2016 at 10:09 PM, Ate Douma  wrote:
> 
>>>  Stian, this is established practice in the ASF since the very early 
> days
> 
> Could someone please enlighten me, what "this" is about?
> 
> Thanks,
> 
> Jochen
> 
> 
> -- 
> The next time you hear: "Don't reinvent the wheel!"
> 
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> 
> 
> -
> 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

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Jochen Wiedmann]

On Mon, Sep 26, 2016 at 10:09 PM, Ate Douma  wrote:

>> Stian, this is established practice in the ASF since the very early days

Could someone please enlighten me, what "this" is about?

Thanks,

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Mark Struberg]

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

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Ate Douma]

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

 wrote:

 On 26 September 2016 at 14:34, Mark Struberg



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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

OpenJDK 1.8.0 from Ubuntu 16.04.
Java version: 1.8.0_91, vendor: Oracle Corporation

It seems it was a threading issue as I was using the optimistic -T1.0C
- which of course is not required to work. My fault!

The build works now (but of course takes a bit longer :).

[INFO] BUILD SUCCESS

My vote changed to +1 (non-binding) -  if you carry over your three
IPMC-binding votes you should be good to go.


On 27 September 2016 at 11:27, Mark Struberg  wrote:
> That's weird. Which Java version do you exactly use?
> I did run the full build with java7 and it passed perfectly fine.
>
>
> LieGrue,
> strub
>
>
> On Tuesday, 27 September 2016, 12:24, Stian Soiland-Reyes  
> wrote:
>>-0 (non-binding)  -- changes my previous -1 vote after dist/ was populated.
>>
>>I'm afraid it's not positive vote from me as the unit tests were
>>failing the build, otherwise I would say +1. But feel free to ignore
>>this vote :)
>>
>>
>>-1 .md5 .sha1 missing from dist
>>+1 valid .asc signature
>>-1 KEYS file missing
>>+1 dist matches mvn (same sha1 of batchee-0.4-incubating-source-release.zip)
>>+1 LICENSE
>>+0 NOTICE:  should say "Apache Batchee" instead of "Batchee".
>>Copyright should be 2013-2016 (or so), not just 2016.
>>-0 DISCLAIMER present - but it says "Apache Sirona" instead of "Apache
>>BatchEE" (already fixed in git)
>>+1 no binaries in source archive
>>+1 mvn apache-rat:check (but jbatch/.../jaxb/* don't have ASF headers)
>>-1 mvn clean install fails
>>+1 source kind of match git commit
>>985047e8cefb46056fcb0bda36af096a0d228fa2 (except LICENSE, NOTICE,
>>.gitignore, DEPENDENCIES)
>>-0 git tag missing LICENSE, NOTICE (already fixed in git master)
>>
>>
>>I would recommend for the JAXB generated files to use the
>>maven-jaxb-plugin from src/main/xsd so that the generated files end up
>>in target/generated-sources instead of being checked in.  If they have
>>to stay (e.g. because they have been modified post generation (uh
>>oh..)) then they should have the ASF header as they are derived from
>>the ASF-licensed xsds.
>>
>>
>>Build failure:
>>
>>[INFO] BatchEE :: GUI :: JAXRS :: Server .. FAILURE [ 19.111 
>>s]
>>
>>Tests run: 9, Failures: 1, Errors: 8, Skipped: 0, Time elapsed: 3.912
>>sec <<< FAILURE! - in org.apache.batchee.jaxrs.server.RestTest
>>getRunningExecutions(org.apache.batchee.jaxrs.server.RestTest)  Time
>>elapsed: 0.772 sec  <<< FAILURE!
>>java.lang.AssertionError: expected:<500> but was:<404>
>>at org.junit.Assert.fail(Assert.java:88)
>>at org.junit.Assert.failNotEquals(Assert.java:834)
>>at org.junit.Assert.assertEquals(Assert.java:645)
>>at org.junit.Assert.assertEquals(Assert.java:631)
>>at 
>>org.apache.batchee.jaxrs.server.RestTest.getRunningExecutions(RestTest.java:82)
>>
>>
>>and then loads of these:
>>
>>getJobExecution(org.apache.batchee.jaxrs.server.RestTest)  Time
>>elapsed: 0.079 sec  <<< ERROR!
>>org.apache.cxf.jaxrs.client.ServerWebApplicationException:
>>Apache Tomcat/7.0.50 - Error
>>report HTTP Status 404 -
>>/batchee-gui/api/batchee/job-execution/0>noshade="noshade">type Status reportmessage
>>/batchee-gui/api/batchee/job-execution/0description
>>The requested resource is not available.>noshade="noshade">Apache Tomcat/7.0.50
>>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:791)
>>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:749)
>>at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:365)
>>at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:501)
>>at org.apache.batchee.jaxrs.server.RestTest.getJobExecution(RestTest.java:117)
>>
>>
>>
>>For reference:
>>
>>stain@biggiebuntu:~/src/batchee/dist/0.4-incubating$ sha1sum
>>batchee-0.4-incubating-source-release.zip
>>05535de5554b598356f27bdb475853675b80b8b4
>>batchee-0.4-incubating-source-release.zip
>>
>>
>>Tested with:
>>Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>>2015-11-10T16:41:47+00:00)
>>Maven home: /home/stain/software/maven
>>Java version: 1.8.0_91, vendor: Oracle Corporation
>>Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
>>Default locale: en_GB, platform encoding: UTF-8
>>OS name: "linux", version: "4.4.0-38-generic", arch: "amd64", family: "unix"
>>
>>
>>On 26 September 2016 at 07:28, Romain Manni-Bucau  
>>wrote:
>>> Hi guys,
>>>
>>> batchee community voted the 0.4-incubating good to release, here is the
>>> time for general@ to vote on 

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

That's weird. Which Java version do you exactly use?
I did run the full build with java7 and it passed perfectly fine.


LieGrue,
strub


On Tuesday, 27 September 2016, 12:24, Stian Soiland-Reyes  
wrote:
>-0 (non-binding)  -- changes my previous -1 vote after dist/ was populated.
>
>I'm afraid it's not positive vote from me as the unit tests were
>failing the build, otherwise I would say +1. But feel free to ignore
>this vote :)
>
>
>-1 .md5 .sha1 missing from dist
>+1 valid .asc signature
>-1 KEYS file missing
>+1 dist matches mvn (same sha1 of batchee-0.4-incubating-source-release.zip)
>+1 LICENSE
>+0 NOTICE:  should say "Apache Batchee" instead of "Batchee".
>Copyright should be 2013-2016 (or so), not just 2016.
>-0 DISCLAIMER present - but it says "Apache Sirona" instead of "Apache
>BatchEE" (already fixed in git)
>+1 no binaries in source archive
>+1 mvn apache-rat:check (but jbatch/.../jaxb/* don't have ASF headers)
>-1 mvn clean install fails
>+1 source kind of match git commit
>985047e8cefb46056fcb0bda36af096a0d228fa2 (except LICENSE, NOTICE,
>.gitignore, DEPENDENCIES)
>-0 git tag missing LICENSE, NOTICE (already fixed in git master)
>
>
>I would recommend for the JAXB generated files to use the
>maven-jaxb-plugin from src/main/xsd so that the generated files end up
>in target/generated-sources instead of being checked in.  If they have
>to stay (e.g. because they have been modified post generation (uh
>oh..)) then they should have the ASF header as they are derived from
>the ASF-licensed xsds.
>
>
>Build failure:
>
>[INFO] BatchEE :: GUI :: JAXRS :: Server .. FAILURE [ 19.111 s]
>
>Tests run: 9, Failures: 1, Errors: 8, Skipped: 0, Time elapsed: 3.912
>sec <<< FAILURE! - in org.apache.batchee.jaxrs.server.RestTest
>getRunningExecutions(org.apache.batchee.jaxrs.server.RestTest)  Time
>elapsed: 0.772 sec  <<< FAILURE!
>java.lang.AssertionError: expected:<500> but was:<404>
>at org.junit.Assert.fail(Assert.java:88)
>at org.junit.Assert.failNotEquals(Assert.java:834)
>at org.junit.Assert.assertEquals(Assert.java:645)
>at org.junit.Assert.assertEquals(Assert.java:631)
>at 
>org.apache.batchee.jaxrs.server.RestTest.getRunningExecutions(RestTest.java:82)
>
>
>and then loads of these:
>
>getJobExecution(org.apache.batchee.jaxrs.server.RestTest)  Time
>elapsed: 0.079 sec  <<< ERROR!
>org.apache.cxf.jaxrs.client.ServerWebApplicationException:
>Apache Tomcat/7.0.50 - Error
>report HTTP Status 404 -
>/batchee-gui/api/batchee/job-execution/0noshade="noshade">type Status reportmessage
>/batchee-gui/api/batchee/job-execution/0description
>The requested resource is not available.noshade="noshade">Apache Tomcat/7.0.50
>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:791)
>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:749)
>at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:365)
>at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:501)
>at org.apache.batchee.jaxrs.server.RestTest.getJobExecution(RestTest.java:117)
>
>
>
>For reference:
>
>stain@biggiebuntu:~/src/batchee/dist/0.4-incubating$ sha1sum
>batchee-0.4-incubating-source-release.zip
>05535de5554b598356f27bdb475853675b80b8b4
>batchee-0.4-incubating-source-release.zip
>
>
>Tested with:
>Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>2015-11-10T16:41:47+00:00)
>Maven home: /home/stain/software/maven
>Java version: 1.8.0_91, vendor: Oracle Corporation
>Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
>Default locale: en_GB, platform encoding: UTF-8
>OS name: "linux", version: "4.4.0-38-generic", arch: "amd64", family: "unix"
>
>
>On 26 September 2016 at 07:28, Romain Manni-Bucau  
>wrote:
>> Hi guys,
>>
>> batchee community voted the 0.4-incubating good to release, here is the
>> time for general@ to vote on it as well
>>
>> dev@ result:
>> http://mail-archives.apache.org/mod_mbox/batchee-dev/201609.mbox/browser
>>
>> Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
>> jspa?projectId=12314924&version=12334147
>>
>> Staging repo: https://repository.apache.org/content/repositories/
>> orgapachebatchee-1004/ (yes numbers are funny sometimes ;))
>>
>> Source zip: https://repository.apache.org/content/repositories/
>> orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
>> incubating-source-release.zip
>>
>> Tag: https://github.com/rm

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

 -0 (non-binding)  -- changes my previous -1 vote after dist/ was populated.

I'm afraid it's not positive vote from me as the unit tests were
failing the build, otherwise I would say +1. But feel free to ignore
this vote :)


-1 .md5 .sha1 missing from dist
+1 valid .asc signature
-1 KEYS file missing
+1 dist matches mvn (same sha1 of batchee-0.4-incubating-source-release.zip)
+1 LICENSE
+0 NOTICE:  should say "Apache Batchee" instead of "Batchee".
Copyright should be 2013-2016 (or so), not just 2016.
-0 DISCLAIMER present - but it says "Apache Sirona" instead of "Apache
BatchEE" (already fixed in git)
+1 no binaries in source archive
+1 mvn apache-rat:check (but jbatch/.../jaxb/* don't have ASF headers)
-1 mvn clean install fails
+1 source kind of match git commit
985047e8cefb46056fcb0bda36af096a0d228fa2 (except LICENSE, NOTICE,
.gitignore, DEPENDENCIES)
-0 git tag missing LICENSE, NOTICE (already fixed in git master)


I would recommend for the JAXB generated files to use the
maven-jaxb-plugin from src/main/xsd so that the generated files end up
in target/generated-sources instead of being checked in.  If they have
to stay (e.g. because they have been modified post generation (uh
oh..)) then they should have the ASF header as they are derived from
the ASF-licensed xsds.


Build failure:

[INFO] BatchEE :: GUI :: JAXRS :: Server .. FAILURE [ 19.111 s]

Tests run: 9, Failures: 1, Errors: 8, Skipped: 0, Time elapsed: 3.912
sec <<< FAILURE! - in org.apache.batchee.jaxrs.server.RestTest
getRunningExecutions(org.apache.batchee.jaxrs.server.RestTest)  Time
elapsed: 0.772 sec  <<< FAILURE!
java.lang.AssertionError: expected:<500> but was:<404>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.batchee.jaxrs.server.RestTest.getRunningExecutions(RestTest.java:82)


and then loads of these:

getJobExecution(org.apache.batchee.jaxrs.server.RestTest)  Time
elapsed: 0.079 sec  <<< ERROR!
org.apache.cxf.jaxrs.client.ServerWebApplicationException:
Apache Tomcat/7.0.50 - Error
report HTTP Status 404 -
/batchee-gui/api/batchee/job-execution/0type Status reportmessage
/batchee-gui/api/batchee/job-execution/0description
The requested resource is not available.Apache Tomcat/7.0.50
at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:791)
at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:749)
at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:365)
at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:501)
at org.apache.batchee.jaxrs.server.RestTest.getJobExecution(RestTest.java:117)



For reference:

stain@biggiebuntu:~/src/batchee/dist/0.4-incubating$ sha1sum
batchee-0.4-incubating-source-release.zip
05535de5554b598356f27bdb475853675b80b8b4
batchee-0.4-incubating-source-release.zip


Tested with:
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-38-generic", arch: "amd64", family: "unix"

On 26 September 2016 at 07:28, Romain Manni-Bucau  wrote:
> Hi guys,
>
> batchee community voted the 0.4-incubating good to release, here is the
> time for general@ to vote on it as well
>
> dev@ result:
> http://mail-archives.apache.org/mod_mbox/batchee-dev/201609.mbox/browser
>
> Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
> jspa?projectId=12314924&version=12334147
>
> Staging repo: https://repository.apache.org/content/repositories/
> orgapachebatchee-1004/ (yes numbers are funny sometimes ;))
>
> Source zip: https://repository.apache.org/content/repositories/
> orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
> incubating-source-release.zip
>
> Tag: https://github.com/rmannibucau/incubator-batchee/
> tree/batchee-0.4-incubating
>
> My gpg key is in tomee KEYS file (https://dist.apache.org/
> repos/dist/release/tomee/KEYS)
>
> Please VOTE
> [+1] yep
> [+0] don’t care
> [-1] no cause [...]
>
> The VOTE is open for 72h or as needed
>
> Thanks,
> Romain Manni-Bucau
> @rmannibucau  |  Blog
> 

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Mark Struberg]

PS: back then I also summed up information about the difference between SVN and 
GIT regarding handling from a user pov
http://wiki.apache.org/couchdb/SVNvsGIT

Most of it is nowadays common knowledge I hope, but some might still find it 
useful.


LieGrue,
strub




> On Tuesday, 27 September 2016, 9: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.
> 
> 
> But I agree it might be time to collect all these informations together and 
> write an incubator compendium for it.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
>>  On Monday, 26 September 2016, 22:09, Ate Douma  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 
>>   wrote:
>   On 26 September 2016 at 14:34, Mark Struberg 
>>  
   wrote:
>We *never* push commits for in-progress votes to hte ASF 
> repos 
>>  when we use

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Mark Struberg]

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.


But I agree it might be time to collect all these informations together and 
write an incubator compendium for it.

LieGrue,
strub




> On Monday, 26 September 2016, 22:09, Ate Douma  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 
>  wrote:
  On 26 September 2016 at 14:34, Mark Struberg 
> 
>>>  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-R

Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Ate Douma]

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

On 26 September 2016 at 14:34, Mark Struberg 

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/-0001-9842-9718



-
To unsubscribe, e-mail: general-unsubscr

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

added asc (thanks to have caught that!)


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-09-26 18:54 GMT+02:00 Mark Struberg :

> + md5 and sha1
>
>
> LieGrue,
> strub
>
> PS: thanks for the review again!
>
>
>
>
> > On Monday, 26 September 2016, 18:43, John D. Ament <
> johndam...@apache.org> wrote:
> > > Can you include the .asc file?
> >
> > John
> >
> > On Mon, Sep 26, 2016 at 12:32 PM Romain Manni-Bucau
> > 
> > wrote:
> >
> >>  added batchee source zip there
> >>  https://dist.apache.org/repos/dist/dev/incubator/batchee/0.
> 4-incubating/
> >>
> >>
> >>  Romain Manni-Bucau
> >>  @rmannibucau  |  Blog
> >>   | Old Wordpress Blog
> >>   | Github <
> >>  https://github.com/rmannibucau> |
> >>  LinkedIn  | Tomitriber
> >>   | JavaEE Factory
> >>  
> >>
> >>  2016-09-26 18:03 GMT+02:00 Romain Manni-Bucau
> > :
> >>
> >>  > creating dist/dev, please be patient a moment
> >>  >
> >>  >
> >>  > Romain Manni-Bucau
> >>  > @rmannibucau  |  Blog
> >>  >  | Old Wordpress Blog
> >>  >  | Github
> >>  >  | LinkedIn
> >>  >  | Tomitriber
> >>  >  | JavaEE Factory
> >>  > 
> >
> >>  >
> >>  > 2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau
> > :
> >>  >
> >>  >>
> >>  >>
> >>  >> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes
> > :
> >>  >>
> >>  >>> On 26 September 2016 at 16:45, Mark Struberg
> >  >>  >
> >>  >>> wrote:
> >>  >>> > Again the question is not about our own repo. The problem
> > are the
> >>  >>> dozen downstream repos. You cannot delete it from there once
> > it got
> >>  pulled
> >>  >>> downstream. Or is there now a way to prevent downstream
> > replication?
> >>  How
> >>  >>> does that work?
> >>  >>>
> >>  >>> Just a thought .. you can push to other refs/ than heads/ and
> > tags/
> >>  >>>
> >>  >>>
> >>  >>>
> > stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
> >>  >>> push origin
> >>  f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
> >>  >>> ng-SNAPSHOT
> >>  >>>
> >>  >>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
> >>  >>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
> >>  >>>
> >>  >>> does not seem to be show on
> >>  >>> https://github.com/apache/incubator-taverna-maven-parent as a
> > branch
> >>  >>> or tag
> >>  >>>
> >>  >>> but exists as a commit:
> >>  >>>
> >>  >>> https://github.com/apache/incubator-taverna-maven-parent/com
> >>  >>> mit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
> >>  >>>
> >>  >>>
> >>  >>> bug or feature?
> >>  >>>
> >>  >>> I don't think it's too usable, as you have to do git
> > fetch origin
> >>  >>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight
> > with Maven
> >>  >>> release plugin to do so.. But it's not all black and
> > white. :)
> >>  >>>
> >>  >>>
> >>  >> Think I'll leave that topic for this thread since it has been
> > discussed
> >>  >> several times and we can change it later but not the moment IMHO.
> >>  >>
> >>  >>
> >>  >>>
> >>  >>> --
> >>  >>> Stian Soiland-Reyes
> >>  >>> http://orcid.org/-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
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

+ md5 and sha1


LieGrue,
strub

PS: thanks for the review again! 




> On Monday, 26 September 2016, 18:43, John D. Ament  
> wrote:
> > Can you include the .asc file?
> 
> John
> 
> On Mon, Sep 26, 2016 at 12:32 PM Romain Manni-Bucau 
> 
> wrote:
> 
>>  added batchee source zip there
>>  https://dist.apache.org/repos/dist/dev/incubator/batchee/0.4-incubating/
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau  |  Blog
>>   | Old Wordpress Blog
>>   | Github <
>>  https://github.com/rmannibucau> |
>>  LinkedIn  | Tomitriber
>>   | JavaEE Factory
>>  
>> 
>>  2016-09-26 18:03 GMT+02:00 Romain Manni-Bucau 
> :
>> 
>>  > creating dist/dev, please be patient a moment
>>  >
>>  >
>>  > Romain Manni-Bucau
>>  > @rmannibucau  |  Blog
>>  >  | Old Wordpress Blog
>>  >  | Github
>>  >  | LinkedIn
>>  >  | Tomitriber
>>  >  | JavaEE Factory
>>  > 
> 
>>  >
>>  > 2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau 
> :
>>  >
>>  >>
>>  >>
>>  >> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes 
> :
>>  >>
>>  >>> On 26 September 2016 at 16:45, Mark Struberg 
> >  >
>>  >>> wrote:
>>  >>> > Again the question is not about our own repo. The problem 
> are the
>>  >>> dozen downstream repos. You cannot delete it from there once 
> it got
>>  pulled
>>  >>> downstream. Or is there now a way to prevent downstream 
> replication?
>>  How
>>  >>> does that work?
>>  >>>
>>  >>> Just a thought .. you can push to other refs/ than heads/ and 
> tags/
>>  >>>
>>  >>>
>>  >>> 
> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
>>  >>> push origin
>>  f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
>>  >>> ng-SNAPSHOT
>>  >>>
>>  >>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
>>  >>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
>>  >>>
>>  >>> does not seem to be show on
>>  >>> https://github.com/apache/incubator-taverna-maven-parent as a 
> branch
>>  >>> or tag
>>  >>>
>>  >>> but exists as a commit:
>>  >>>
>>  >>> https://github.com/apache/incubator-taverna-maven-parent/com
>>  >>> mit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
>>  >>>
>>  >>>
>>  >>> bug or feature?
>>  >>>
>>  >>> I don't think it's too usable, as you have to do git 
> fetch origin
>>  >>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight 
> with Maven
>>  >>> release plugin to do so.. But it's not all black and 
> white. :)
>>  >>>
>>  >>>
>>  >> Think I'll leave that topic for this thread since it has been 
> discussed
>>  >> several times and we can change it later but not the moment IMHO.
>>  >>
>>  >>
>>  >>>
>>  >>> --
>>  >>> Stian Soiland-Reyes
>>  >>> http://orcid.org/-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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

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  
> 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  
> 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  |  Blog
>>   | Old Wordpress Blog
>>   | Github 
>  |
>>  LinkedIn  | Tomitriber
>>   | JavaEE Factory
>>  
>> 
>>  2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes :
>> 
>>>  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  
> 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 <
>>>  st...@apache.org> wrote:
>>>  >> > On 26 September 2016 at 14:34, Mark Struberg
>>>  
>>>  >> 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 thin

Re: [VOTE] Apache BatchEE 0.4-incubating

[John D. Ament]

Can you include the .asc file?

John

On Mon, Sep 26, 2016 at 12:32 PM Romain Manni-Bucau 
wrote:

> added batchee source zip there
> https://dist.apache.org/repos/dist/dev/incubator/batchee/0.4-incubating/
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-09-26 18:03 GMT+02:00 Romain Manni-Bucau :
>
> > creating dist/dev, please be patient a moment
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github
> >  | LinkedIn
> >  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau :
> >
> >>
> >>
> >> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes :
> >>
> >>> On 26 September 2016 at 16:45, Mark Struberg  >
> >>> wrote:
> >>> > Again the question is not about our own repo. The problem are the
> >>> dozen downstream repos. You cannot delete it from there once it got
> pulled
> >>> downstream. Or is there now a way to prevent downstream replication?
> How
> >>> does that work?
> >>>
> >>> Just a thought .. you can push to other refs/ than heads/ and tags/
> >>>
> >>>
> >>> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
> >>> push origin
> f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
> >>> ng-SNAPSHOT
> >>>
> >>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
> >>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
> >>>
> >>> does not seem to be show on
> >>> https://github.com/apache/incubator-taverna-maven-parent as a branch
> >>> or tag
> >>>
> >>> but exists as a commit:
> >>>
> >>> https://github.com/apache/incubator-taverna-maven-parent/com
> >>> mit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
> >>>
> >>>
> >>> bug or feature?
> >>>
> >>> I don't think it's too usable, as you have to do git fetch origin
> >>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
> >>> release plugin to do so.. But it's not all black and white. :)
> >>>
> >>>
> >> Think I'll leave that topic for this thread since it has been discussed
> >> several times and we can change it later but not the moment IMHO.
> >>
> >>
> >>>
> >>> --
> >>> Stian Soiland-Reyes
> >>> http://orcid.org/-0001-9842-9718
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >>
> >
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

added batchee source zip there
https://dist.apache.org/repos/dist/dev/incubator/batchee/0.4-incubating/


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-09-26 18:03 GMT+02:00 Romain Manni-Bucau :

> creating dist/dev, please be patient a moment
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github
>  | LinkedIn
>  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau :
>
>>
>>
>> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes :
>>
>>> On 26 September 2016 at 16:45, Mark Struberg 
>>> wrote:
>>> > Again the question is not about our own repo. The problem are the
>>> dozen downstream repos. You cannot delete it from there once it got pulled
>>> downstream. Or is there now a way to prevent downstream replication? How
>>> does that work?
>>>
>>> Just a thought .. you can push to other refs/ than heads/ and tags/
>>>
>>>
>>> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
>>> push origin f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
>>> ng-SNAPSHOT
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
>>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
>>>
>>> does not seem to be show on
>>> https://github.com/apache/incubator-taverna-maven-parent as a branch
>>> or tag
>>>
>>> but exists as a commit:
>>>
>>> https://github.com/apache/incubator-taverna-maven-parent/com
>>> mit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
>>>
>>>
>>> bug or feature?
>>>
>>> I don't think it's too usable, as you have to do git fetch origin
>>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
>>> release plugin to do so.. But it's not all black and white. :)
>>>
>>>
>> Think I'll leave that topic for this thread since it has been discussed
>> several times and we can change it later but not the moment IMHO.
>>
>>
>>>
>>> --
>>> Stian Soiland-Reyes
>>> http://orcid.org/-0001-9842-9718
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>>
>>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

creating dist/dev, please be patient a moment


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau :

>
>
> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes :
>
>> On 26 September 2016 at 16:45, Mark Struberg 
>> wrote:
>> > Again the question is not about our own repo. The problem are the dozen
>> downstream repos. You cannot delete it from there once it got pulled
>> downstream. Or is there now a way to prevent downstream replication? How
>> does that work?
>>
>> Just a thought .. you can push to other refs/ than heads/ and tags/
>>
>>
>> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
>> push origin f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
>> ng-SNAPSHOT
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
>>
>> does not seem to be show on
>> https://github.com/apache/incubator-taverna-maven-parent as a branch
>> or tag
>>
>> but exists as a commit:
>>
>> https://github.com/apache/incubator-taverna-maven-parent/
>> commit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
>>
>>
>> bug or feature?
>>
>> I don't think it's too usable, as you have to do git fetch origin
>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
>> release plugin to do so.. But it's not all black and white. :)
>>
>>
> Think I'll leave that topic for this thread since it has been discussed
> several times and we can change it later but not the moment IMHO.
>
>
>>
>> --
>> Stian Soiland-Reyes
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes :

> On 26 September 2016 at 16:45, Mark Struberg 
> wrote:
> > Again the question is not about our own repo. The problem are the dozen
> downstream repos. You cannot delete it from there once it got pulled
> downstream. Or is there now a way to prevent downstream replication? How
> does that work?
>
> Just a thought .. you can push to other refs/ than heads/ and tags/
>
>
> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
> push origin f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-
> incubating-SNAPSHOT
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
>
> does not seem to be show on
> https://github.com/apache/incubator-taverna-maven-parent as a branch
> or tag
>
> but exists as a commit:
>
> https://github.com/apache/incubator-taverna-maven-parent/commit/
> f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
>
>
> bug or feature?
>
> I don't think it's too usable, as you have to do git fetch origin
> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
> release plugin to do so.. But it's not all black and white. :)
>
>
Think I'll leave that topic for this thread since it has been discussed
several times and we can change it later but not the moment IMHO.


>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

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  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  |  Blog
>  | Old Wordpress Blog
>  | Github  |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes :
>
>> 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  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 <
>> st...@apache.org> wrote:
>> >> > On 26 September 2016 at 14:34, Mark Struberg
>> 
>> >> 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 - branch

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

On 26 September 2016 at 16:45, Mark Struberg  wrote:
> Again the question is not about our own repo. The problem are the dozen 
> downstream repos. You cannot delete it from there once it got pulled 
> downstream. Or is there now a way to prevent downstream replication? How does 
> that work?

Just a thought .. you can push to other refs/ than heads/ and tags/


stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
push origin 
f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubating-SNAPSHOT

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT

does not seem to be show on
https://github.com/apache/incubator-taverna-maven-parent as a branch
or tag

but exists as a commit:

https://github.com/apache/incubator-taverna-maven-parent/commit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b


bug or feature?

I don't think it's too usable, as you have to do git fetch origin
refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
release plugin to do so.. But it's not all black and white. :)


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

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  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes :

> 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  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 <
> st...@apache.org> wrote:
> >> > On 26 September 2016 at 14:34, Mark Struberg
> 
> >> 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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

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  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  
>> wrote:
>> > On 26 September 2016 at 14:34, Mark Struberg 
>> 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 So

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

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


Again the question is not about our own repo. The problem are the dozen 
downstream repos. You cannot delete it from there once it got pulled 
downstream. Or is there now a way to prevent downstream replication? How does 
that work?


I suggested to give every project a 2nd 'playground' or sandbox GIT repo for 
exactly that.
But the benefit over a github repo was not really there, so it got downvoted.


LieGrue,
strub



> On Monday, 26 September 2016, 17:25, John D. Ament  
> wrote:
> > On Mon, Sep 26, 2016 at 11:23 AM 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.
>> 
> 
> 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 <
>>  st...@apache.org> wrote:
>>  > > On 26 September 2016 at 14:34, Mark Struberg 
> >  >
>>  > 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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

This is a valid point for the older releases.
We obviously missed that in our steps.
And we also need to add a download page.

But that doesn't invalidate this very release.
Note that we must not push the release to dist until the vote succeeded.

The releases are btw also on repository.apache.org. But that's of course not 
good enough. We gonna fix that.


txs and LieGrue,
strub





> On Monday, 26 September 2016, 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 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 
>  wrote:
>>  > On 26 September 2016 at 14:34, Mark Struberg 
>  
>>  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/-0001-9842-9718
>> 
> 

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[John D. Ament]

On Mon, Sep 26, 2016 at 11:23 AM 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.
>

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 <
> st...@apache.org> wrote:
> > > On 26 September 2016 at 14:34, Mark Struberg  >
> > 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/-0001-9842-9718
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

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  
> wrote:
> > On 26 September 2016 at 14:34, Mark Struberg  
> 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/-0001-9842-9718
> 

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Alex Harui]

On 9/26/16, 1:53 AM, "Mark Struberg"  wrote:

>
>No, we didn't get an official grant, but the RI is ALv2 and we actively
>asked the IBM devs/managers and they are perfectly fine with it.

AIUI, IBM could give you or one of their employees who participate in your
project permission to move their (c) to NOTICE without it being a "grant".
 I don't think that makes a difference as to the validity of the release,
just whether scanning tools pick up such things in the future.

-Alex

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

I am a bit concerned about BatchEE's release procedure.

Your vote refers to a KEYS file from a different project (tomee)

This would be the fourth BatchEE incubator release - so I'm expecting
to find a batchee 0.1-incubating, 0.2-incubating and 0.3-incubating
somewhere.


Where are the source code downloads?

http://batchee.incubator.apache.org/modules.html only describes Maven
coordinates.

https://dist.apache.org/repos/dist/release/incubator/ does not contain batchee
https://dist.apache.org/repos/dist/dev/incubator/ does not contain batchee
https://dist.apache.org/repos/dist/release/tomee/ does not contain
batchee (had to check! :)


Yet https://dist.apache.org/repos/dist/release/tomee/ contains various
binary artifacts.

http://central.maven.org/maven2/org/apache/batchee/batchee/ seems to
have some source releases.



The ASF Release Policy is quite clear on this:

http://www.apache.org/dev/release.html#where-do-releases-go

On 26 September 2016 at 07:28, Romain Manni-Bucau  wrote:
> Hi guys,
>
> batchee community voted the 0.4-incubating good to release, here is the
> time for general@ to vote on it as well
>
> dev@ result:
> http://mail-archives.apache.org/mod_mbox/batchee-dev/201609.mbox/browser
>
> Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
> jspa?projectId=12314924&version=12334147
>
> Staging repo: https://repository.apache.org/content/repositories/
> orgapachebatchee-1004/ (yes numbers are funny sometimes ;))
>
> Source zip: https://repository.apache.org/content/repositories/
> orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
> incubating-source-release.zip
>
> Tag: https://github.com/rmannibucau/incubator-batchee/
> tree/batchee-0.4-incubating
>
> My gpg key is in tomee KEYS file (https://dist.apache.org/
> repos/dist/release/tomee/KEYS)
>
> Please VOTE
> [+1] yep
> [+0] don’t care
> [-1] no cause [...]
>
> The VOTE is open for 72h or as needed
>
> Thanks,
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github  |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

On 26 September 2016 at 14:34, Mark Struberg  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/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

Hi Stian!

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.

Please find more in depth explanation over at [1]


Of course we should have added the sha1 of the commit to the VOTE mail. Guilty 
as charged for this. Romain, could you please officially denote the commit?


txs and LieGrue,
strub


[1] http://deltaspike.apache.org/staging/steps_for_a_release.html



On Monday, 26 September 2016, 15:21, Stian Soiland-Reyes  
wrote:
>
>On 26 September 2016 at 07:28, Romain Manni-Bucau  
>wrote:
>> Hi guys,
>>
>> batchee community voted the 0.4-incubating good to release, here is the
>> time for general@ to vote on it as well
>
>-1 (non-binding)
>
>Your vote email didn't include any hashes or commit IDs - please
>provide these those next time.
>
>
>
>> Tag: https://github.com/rmannibucau/incubator-batchee/
>> tree/batchee-0.4-incubating
>
>I would appreciate if the tag under voting was not under a personal
>GitHub account.
>
>Your suggested tag is of commit
>985047e8cefb46056fcb0bda36af096a0d228fa2, which is not on
>git.apache.org
>
>https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=985047e8cefb46056fcb0bda36af096a0d228fa2
>
>
>However I find an alternative commit:
>https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=0dabf849ce59fa26d4dbde301335b74e5715ca2f
>
>
>I didn't investigate further if the commits are content-wise different or not.
>
>
>Note that it is not a strict ASF requirement that there is a matching
>tag (the vote is on the source archive) - but personally I can't
>support a release without commits/tag in the official repository.
>
>
>-- 
>Stian Soiland-Reyes
>http://orcid.org/-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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 15:20 GMT+02:00 Stian Soiland-Reyes :

> On 26 September 2016 at 07:28, Romain Manni-Bucau 
> wrote:
> > Hi guys,
> >
> > batchee community voted the 0.4-incubating good to release, here is the
> > time for general@ to vote on it as well
>
> -1 (non-binding)
>
> Your vote email didn't include any hashes or commit IDs - please
> provide these those next time.
>
>
This is this one
https://github.com/rmannibucau/incubator-batchee/commit/985047e8cefb46056fcb0bda36af096a0d228fa2
corresponding to
https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=0dabf849ce59fa26d4dbde301335b74e5715ca2f
on asf (tag intentionnally not pushed yet, see next comment)


>
> > Tag: https://github.com/rmannibucau/incubator-batchee/
> > tree/batchee-0.4-incubating
>
> I would appreciate if the tag under voting was not under a personal
> GitHub account.
>
> Your suggested tag is of commit
> 985047e8cefb46056fcb0bda36af096a0d228fa2, which is not on
> git.apache.org
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.
> git;a=commit;h=985047e8cefb46056fcb0bda36af096a0d228fa2
>
>
This was intended and will likely stay that way for future releases (like
on several asf projects using git) to avoid to push cancelled tag on asf
repos (cause you can't delete a tag from a git repo without advanced infra
work).

Side note: don't read it as a personal opinion please but as the followed
rule.

Difference in hashes comes from the fact Reinhard committed after the tag
has been created and I pushed the release hashes with the notice/license
commits - yes I should maybe have removed them. However no big deal there
since the tag itself is not yet on ASF and will be sync-ed only when this
vote will pass.


> However I find an alternative commit:
> https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.
> git;a=commit;h=0dabf849ce59fa26d4dbde301335b74e5715ca2f
>
>
> I didn't investigate further if the commits are content-wise different or
> not.
>
>
> Note that it is not a strict ASF requirement that there is a matching
> tag (the vote is on the source archive) - but personally I can't
> support a release without commits/tag in the official repository.
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

On 26 September 2016 at 07:28, Romain Manni-Bucau  wrote:
> Hi guys,
>
> batchee community voted the 0.4-incubating good to release, here is the
> time for general@ to vote on it as well

-1 (non-binding)

Your vote email didn't include any hashes or commit IDs - please
provide these those next time.


> Tag: https://github.com/rmannibucau/incubator-batchee/
> tree/batchee-0.4-incubating

I would appreciate if the tag under voting was not under a personal
GitHub account.

Your suggested tag is of commit
985047e8cefb46056fcb0bda36af096a0d228fa2, which is not on
git.apache.org

https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=985047e8cefb46056fcb0bda36af096a0d228fa2


However I find an alternative commit:
https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=0dabf849ce59fa26d4dbde301335b74e5715ca2f


I didn't investigate further if the commits are content-wise different or not.


Note that it is not a strict ASF requirement that there is a matching
tag (the vote is on the source archive) - but personally I can't
support a release without commits/tag in the official repository.


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Jean-Baptiste Onofré]

+1 (binding)

Checked:
- build
- NOTICE and DISCLAIMERS
- ASF headers
- LICENSE should be cleaned up but nothing blocker IMHO

Regards
JB

On 09/26/2016 08:28 AM, Romain Manni-Bucau wrote:

Hi guys,

batchee community voted the 0.4-incubating good to release, here is the
time for general@ to vote on it as well

dev@ result:
http://mail-archives.apache.org/mod_mbox/batchee-dev/201609.mbox/browser

Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
jspa?projectId=12314924&version=12334147

Staging repo: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/ (yes numbers are funny sometimes ;))

Source zip: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
incubating-source-release.zip

Tag: https://github.com/rmannibucau/incubator-batchee/
tree/batchee-0.4-incubating

My gpg key is in tomee KEYS file (https://dist.apache.org/
repos/dist/release/tomee/KEYS)

Please VOTE
[+1] yep
[+0] don’t care
[-1] no cause [...]

The VOTE is open for 72h or as needed

Thanks,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[justin]

Hi,

Changing my vote to +1 binding.

Thanks,
Justin


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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Justin Mclean]

Hi,

> yes there https://github.com/WASdev/standards.jsr352.jbatch . I think we
> are good - at least we were when imported the code.

Yuck a malformed NOTICE that looks to include things that are most likley not 
bundled and lists ALv2 things. You may want to help them out with that.

But there’s nothing there I think needs to be copied to your NOTICE file. [1]

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#alv2-dep
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 11:31 GMT+02:00 Justin Mclean :

> Hi,
>
> > Comes from OpenEJB for cli - thought it was ok to rely on transitive
> > dependencies there - and for the maven plugin it is JUNG (BSD) so think
> it
> > is ok, did I miss one?
>
> I think so but it not clear to me when those LICENSES end up.
>
> MPL and CDDL (known at category B) are not OK in source releases [1] so as
> long at that followed it’s all OK.
>
>
Not in source AFAIK but binaries transitively.


> Thanks,
> Justin
>
> [1] http://www.apache.org/legal/resolved.html#category-b
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 11:27 GMT+02:00 Justin Mclean :

> Hi,
>
> > No, we didn't get an official grant, but the RI is ALv2 and we actively
> asked the IBM devs/managers and they are perfectly fine with it. They even
> give feedback on JIRA and contributed patches later on.
> >
> > We are actively working together so to say.
> > But by not having a grant we cannot change the copyright for those files.
>
> Thanks for that that sounds fine to me. ASF policy to to not add copyright
> lines to ASF headers, but if they are a 3rd parties then I guess that needs
> to be respected.
>
> One last question - does the IBM project have a NOTICE file?
>
>
yes there https://github.com/WASdev/standards.jsr352.jbatch . I think we
are good - at least we were when imported the code.


> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Justin Mclean]

Hi,

> Comes from OpenEJB for cli - thought it was ok to rely on transitive
> dependencies there - and for the maven plugin it is JUNG (BSD) so think it
> is ok, did I miss one?

I think so but it not clear to me when those LICENSES end up. 

MPL and CDDL (known at category B) are not OK in source releases [1] so as long 
at that followed it’s all OK.

Thanks,
Justin

[1] http://www.apache.org/legal/resolved.html#category-b
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache BatchEE 0.4-incubating

[Justin Mclean]

Hi,

> No, we didn't get an official grant, but the RI is ALv2 and we actively asked 
> the IBM devs/managers and they are perfectly fine with it. They even give 
> feedback on JIRA and contributed patches later on. 
> 
> We are actively working together so to say.
> But by not having a grant we cannot change the copyright for those files.

Thanks for that that sounds fine to me. ASF policy to to not add copyright 
lines to ASF headers, but if they are a 3rd parties then I guess that needs to 
be respected.

One last question - does the IBM project have a NOTICE file?

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 10:21 GMT+02:00 Justin Mclean :

> Hi,
>
> +0 until IBM copyright question sorted. Happy to change to +1 if there’s a
> good reason for it.
>
> I’d guess that the code come from them in a software grant and the
> copyright has just been forgotten to be removed and IBM added to the NOTICE
> file?
>
>
Mark answered that one I think


> I checked:
> - inculcating in name
> - signature and hashes correct
> - DISCLAIMER exists
> - LICENSE is missing normalise.css found inside this file [4] and for
> jQuery [5] Please fix in next release.
>

added
https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commitdiff;h=6caf91cc17547b47f4c803d5212c7d88f7488cad


> - NOTICE correct
> - No binary files in release
> - All source files have ASF header but there’s an issue with IBM copyright
> - Can compile from source
>
> It would be use to place the artefacts here [1] for voting on that was
> they can be released with an svn move.
>
> I’m a little confused by these [2][3] They contain BSD. MIT, MPL, CDDL
> licenses but it’s not mentioned in LICENSE.
>
>
Comes from OpenEJB for cli - thought it was ok to rely on transitive
dependencies there - and for the maven plugin it is JUNG (BSD) so think it
is ok, did I miss one?


> There are several files e.g. with ASF header with copyright 2012 or 2013
> International Business Machines Corp. Is this correct? If so what ASv2
> licensed software did they come from or were they part of a software grant?
>
> Thanks,
> Justin
>
> 1. https://dist.apache.org/repos/dist/dev/incubator/batchee
> 2. ./tools/maven-plugin/src/main/resources/META-INF/LICENSE
> 3 ./tools/cli/src/main/resources/META-INF/LICENSE
> 4. ./gui/servlet/embedded/src/main/resources/META-INF/
> resources/internal/batchee/css/bootstrap.min.3.0.0.css
> 5. ./gui/servlet/embedded/src/main/resources/META-INF/
> resources/internal/batchee/js/jquery-2.0.3.min.js
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Mark Struberg]

Hi Justin!

First, thanks for the review!

The question got asked as well while we started incubation. 

I'll try to quickly sum up the outcome:
No, we didn't get an official grant, but the RI is ALv2 and we actively asked 
the IBM devs/managers and they are perfectly fine with it. They even give 
feedback on JIRA and contributed patches later on. 

We are actively working together so to say.
But by not having a grant we cannot change the copyright for those files.


We have the (c) ASF header for stuff we wrote our own, and the (c) IBM header 
for stuff IBM wrote.Given this I think the header is fine, isn't?

LieGrue,
strub


On Monday, 26 September 2016, 10:22, Justin Mclean  
wrote:
>
>
>Hi,
>
>+0 until IBM copyright question sorted. Happy to change to +1 if there’s a 
>good reason for it.
>
>I’d guess that the code come from them in a software grant and the copyright 
>has just been forgotten to be removed and IBM added to the NOTICE file?
>
>I checked:
>- inculcating in name
>- signature and hashes correct
>- DISCLAIMER exists
>- LICENSE is missing normalise.css found inside this file [4] and for jQuery 
>[5] Please fix in next release.
>- NOTICE correct
>- No binary files in release
>- All source files have ASF header but there’s an issue with IBM copyright
>- Can compile from source
>
>It would be use to place the artefacts here [1] for voting on that was they 
>can be released with an svn move.
>
>I’m a little confused by these [2][3] They contain BSD. MIT, MPL, CDDL 
>licenses but it’s not mentioned in LICENSE.
>
>There are several files e.g. with ASF header with copyright 2012 or 2013 
>International Business Machines Corp. Is this correct? If so what ASv2 
>licensed software did they come from or were they part of a software grant?
>
>Thanks,
>Justin
>
>
>1. https://dist.apache.org/repos/dist/dev/incubator/batchee
>2. ./tools/maven-plugin/src/main/resources/META-INF/LICENSE
>3 ./tools/cli/src/main/resources/META-INF/LICENSE
>4. 
>./gui/servlet/embedded/src/main/resources/META-INF/resources/internal/batchee/css/bootstrap.min.3.0.0.css
>5. 
>./gui/servlet/embedded/src/main/resources/META-INF/resources/internal/batchee/js/jquery-2.0.3.min.js
>
>
>-
>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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Justin Mclean]

Hi,

+0 until IBM copyright question sorted. Happy to change to +1 if there’s a good 
reason for it.

I’d guess that the code come from them in a software grant and the copyright 
has just been forgotten to be removed and IBM added to the NOTICE file?

I checked:
- inculcating in name
- signature and hashes correct
- DISCLAIMER exists
- LICENSE is missing normalise.css found inside this file [4] and for jQuery 
[5] Please fix in next release.
- NOTICE correct
- No binary files in release
- All source files have ASF header but there’s an issue with IBM copyright
- Can compile from source

It would be use to place the artefacts here [1] for voting on that was they can 
be released with an svn move.

I’m a little confused by these [2][3] They contain BSD. MIT, MPL, CDDL licenses 
but it’s not mentioned in LICENSE.

There are several files e.g. with ASF header with copyright 2012 or 2013 
International Business Machines Corp. Is this correct? If so what ASv2 licensed 
software did they come from or were they part of a software grant?

Thanks,
Justin

1. https://dist.apache.org/repos/dist/dev/incubator/batchee
2. ./tools/maven-plugin/src/main/resources/META-INF/LICENSE
3 ./tools/cli/src/main/resources/META-INF/LICENSE
4. 
./gui/servlet/embedded/src/main/resources/META-INF/resources/internal/batchee/css/bootstrap.min.3.0.0.css
5. 
./gui/servlet/embedded/src/main/resources/META-INF/resources/internal/batchee/js/jquery-2.0.3.min.js


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

[VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

Hi guys,

batchee community voted the 0.4-incubating good to release, here is the
time for general@ to vote on it as well

dev@ result:
http://mail-archives.apache.org/mod_mbox/batchee-dev/201609.mbox/browser

Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
jspa?projectId=12314924&version=12334147

Staging repo: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/ (yes numbers are funny sometimes ;))

Source zip: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
incubating-source-release.zip

Tag: https://github.com/rmannibucau/incubator-batchee/
tree/batchee-0.4-incubating

My gpg key is in tomee KEYS file (https://dist.apache.org/
repos/dist/release/tomee/KEYS)

Please VOTE
[+1] yep
[+0] don’t care
[-1] no cause [...]

The VOTE is open for 72h or as needed

Thanks,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory

Fwd: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

Hi general@!

FYI the BatchEE incubation project is votiing on batchee 0.4-incubating

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>

-- Forwarded message --
From: Romain Manni-Bucau 
Date: 2016-09-22 18:16 GMT+02:00
Subject: [VOTE] Apache BatchEE 0.4-incubating
To: "d...@batchee.incubator.apache.org" 


Hi guys,

we discussed it several time so here it is: the vote for batchee N+1

Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
jspa?projectId=12314924&version=12334147

Staging repo: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/ (yes numbers are funny sometimes ;))

Source zip: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
incubating-source-release.zip

Tag: https://github.com/rmannibucau/incubator-batchee/
tree/batchee-0.4-incubating

My gpg key is in tomee KEYS file (https://dist.apache.org/
repos/dist/release/tomee/KEYS) - didn't find the batchee one ATM

Please VOTE
[+1] yep
[+0] don’t care
[-1] no cause [...]

The VOTE is open for 72h

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