Re: [VOTE] Release Apache PredictionIO 0.10.0 (incubating) RC4

[Justin Mclean]

Hi,

Just doing review and is the doc directory meant to be included in the source 
release? I’m seeing a number of pieces of 3rd party licensed code bundled in 
there that’s not mentioned in LICENSE.

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

[VOTE] Release Apache PredictionIO 0.10.0 (incubating) RC4

[Donald Szeto]

Hi all,

The PredictionIO community has voted that 0.10.0-incubating-rc4 to be good
for a source-only release. This thread is to facilitate a voting for the
IPMC before a final official source-only release.

Vote result on dev@:
http://mail-archives.apache.org/mod_mbox/incubator-predictionio-dev/201609.mbox/%3CCAD8z1JK5Dp_EY2P1_CdQuesehZPPN46Ko2nvRmNxmJvAQYLsdA%40mail.gmail.com%3E

The original vote thread on dev@:
http://mail-archives.apache.org/mod_mbox/incubator-predictionio-dev/201609.mbox/%3CCAD8z1JKoMfsynbTSpUSDvMS2Thu9RD2y_iEZ6ABWVXauPWhUDQ%40mail.gmail.com%3E

The release candidate Git commit is:
3179dd8d64f4293da868c7cfca3867800a8aca9c

The release candidate Git tag is:
v0.10.0-incubating-rc4

The source-only release candidate artifacts can be downloaded here:
https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.10.0-
incubating-rc4/

Test results of RC4 can be found here:
https://travis-ci.org/apache/incubator-predictionio/builds/161704456

Build instructions of previous versions can be used on this RC:
http://predictionio.incubator.apache.org/install/install-sourcecode/

Unit and integration tests instructions can be found at:
https://github.com/apache/incubator-predictionio/blob/release/0.10.0/tests/README.md

Maven artifacts are built from the release candidate artifacts above, and
are provided as convenience for testing with PredictionIO engine templates.
The Maven
artifacts are provided at the Maven staging repo here:
https://repository.apache.org/content/repositories/
orgapachepredictionio-1006/

All JIRAs completed for this release are tagged with 'FixVersion = 0.10.0'.
You can view them here: https://issues.apache.org/
jira/secure/ReleaseNote.jspa?projectId=12320420=12337844

The artifacts have been signed with Key : 8BF4ABEB

Please vote accordingly:

[ ] +1, accept RC as the official 0.10.0 release
[ ] 0, neutral because...
[ ] -1, do not accept RC as the official 0.10.0 release because...

The vote will be open for 72 hours and close at 9pm PST 9/29/2016.

Regards,
Donald

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Geertjan Wielenga]

Thankl of the below has been done.

Some more are being added. However at this point the more we add the more
insulting to those we omit. We've done our best. The list is strong. None
will commit nothing, all have a history of years being active in one way or
another in the NetBeans community.

Gj


On Monday, September 26, 2016, Emmanuel Lécharny 
wrote:

> Le 26/09/16 à 07:32, Geertjan Wielenga a écrit :
> > On Mon, Sep 26, 2016 at 6:52 AM, Alex Harui wrote:
> >
> >
> >> But if you are thinking 100 people, I'd try to get it down to 40-ish.
> >
> > Seems like a very random number. In the case of NetBeans, that would mean
> > we'd have few others on the list than those from Oracle, which is not
> what
> > we want -- instead, we want to reflect the various communities (Oracle,
> > NetBeans Platform companies, NetBeans plugin developers, NetBeans Dream
> > Team members, etc) in our list and yes that's going to result in a number
> > larger than 40.
>
> The number doesn't matter.
>
> Just ask the existing committers if they want to keep going under an
> Apache flag. Some will say yes, add them to the list. Some will say no,
> don't put them on the list. Some will simply not reply, ask tehm once
> more just in case they forgot to answer (vacations, etc), and act
> accordingly to their answer - or non answer . At the end of the day, you
> have your list.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 26/09/16 à 07:32, Geertjan Wielenga a écrit :
> On Mon, Sep 26, 2016 at 6:52 AM, Alex Harui wrote:
>
>
>> But if you are thinking 100 people, I'd try to get it down to 40-ish.
>
> Seems like a very random number. In the case of NetBeans, that would mean
> we'd have few others on the list than those from Oracle, which is not what
> we want -- instead, we want to reflect the various communities (Oracle,
> NetBeans Platform companies, NetBeans plugin developers, NetBeans Dream
> Team members, etc) in our list and yes that's going to result in a number
> larger than 40.

The number doesn't matter.

Just ask the existing committers if they want to keep going under an
Apache flag. Some will say yes, add them to the list. Some will say no,
don't put them on the list. Some will simply not reply, ask tehm once
more just in case they forgot to answer (vacations, etc), and act
accordingly to their answer - or non answer . At the end of the day, you
have your list.


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

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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Geertjan Wielenga]

Yup, done -- what will you be working on in Apache NetBeans? Based on the
books and documentation you've written, I imagine something along those
lines, while you're also a Java EE expert, so I could see you contributing
in different ways there too, as well as being a JCP expert group member. A
big win for the project, thank you.

Gj

On Mon, Sep 26, 2016 at 8:08 PM, Michael Müller <
michael.muel...@mueller-bruehl.de> wrote:

> Hi GJ,
>
>
> due to technical problems I missed one day of the discussion. I'm going to
> catch up.
>
> If possible, please add to to the initial commiters.
>
>
> Herzliche Grüße - Best Regards,
>
> Michael Müller
> Brühl, Germany
> blog.mueller-bruehl.de 
> it-rezension.de 
> @muellermi
>
>
> Read my books
> "Web Development with Java and JSF": https://leanpub.com/jsf
> "Java Lambdas und (parallel) Streams" Deutsche Ausgabe:
> https://leanpub.com/lambdas-de
> "Java Lambdas and (parallel) Streams" English edition:
> https://leanpub.com/lambdas
>
> On 09/23/2016 03:30 PM, Geertjan Wielenga wrote:
>
>> OK. Before the vote, will work on making the initial contributors list as
>> complete as possible.
>>
>> What is the process for doing that? Do I simply make changes directly in
>> the proposal? Do I make the changes public here before adding them to the
>> proposal? Do I work directly with the mentors via e-mails to discuss and
>> then after than make the changes?
>>
>> Thanks,
>>
>> Geertjan
>>
>> On Fri, Sep 23, 2016 at 10:02 AM, John D. Ament 
>> wrote:
>>
>> Hi Bertrand,
>>>
>>> Responses in line.
>>>
>>> On Thu, Sep 22, 2016 at 11:54 PM Bertrand Delacretaz <
>>> bdelacre...@apache.org>
>>> wrote:
>>>
>>> Hi Geertjan,

 I won't have time to look at your whole message now, just a few
 clarifications as far as committers/PMC is concerned.

 On Fri, Sep 23, 2016 at 7:50 AM, Geertjan Wielenga <
 geertjan.wiele...@googlemail.com> wrote:

> ...Anyone on the list
> will, once the proposal has been voted on and accepted, automatically
>
 be
>>>
 contributors to the Apache NetBeans project...
>
 They will be commiters to be precise.

 Agreed, the way I interpretted Geertjan is that Netbeans contributor ==
>>> ASF
>>> committer.  They don't have the role of PMC/PPMC presently, so we'll see
>>> how that evolves.
>>>
>>>
>>> Anyone not on the list will
> need to be voted in by the initial contributors, which is a process
>
 that
>>>
 could be fast, but is still a process and can be avoided by inclusion
>
 in
>>>
 the initial contributors list...
>
 It's a simple process, the incubating project could very well have one

>>> vote
>>>
 for N people if that makes sense and they are all wanted.

 Its simple but hard.  And no, I don't think we want bulk votes.  What if
>>> someone is +1 add Mark S and -1 add Bertrand D?  At least when its come
>>> up
>>> to the IPMC previously, we've recommended against it.
>>>
>>>
>>> Everyone on the initial contributors list is
> automatically part of the PMC.
>
 There's no PMC for an incubating project, just a PPMC as per
 http://incubator.apache.org/guides/ppmc.html

 That group has no formal power, only the Incubator PMC can vote on the
 podling's releases or make other decisions which are binding at the
 foundation level.

 In practice, you are correct that the PPMC is a PMC in training, but

>>> really
>>>
 in a podling being a PPMC member doesn't make a difference IMO.

 It does.  PPMC has one important job - vote on adding more people.  We
>>> hope
>>> that they will learn to look at their releases very carefully while under
>>> incubation.
>>>
>>>
>>> ...Anyone on the list when the project leaves
> incubation gets write access to the project for the rest of their
>
 life...
>>>
 That's correct, but there can be a difference between the committers and
 PMC members once the project graduates. As a mentor, when graduating I
 would not accept a PMC member who has not contributed during incubation

>>> for
>>>
 example, whereas a committer that hasn't really been active during
 incubation is harmless.

 Committers don't have formal power once the project graduates, and if

>>> they
>>>
 don't behave their commits rights can easily be suspended, temporarily
 or
 permanently. That very rarely happens, just mentioning it to clarify the
 risks.

 That's... odd to say the least.  I'm not aware of any specific cases,
>>> doesn't mean it hasn't' happened, but I can't think of any cases where it
>>> has (other than one special case recently of someone being asked out of
>>> the
>>> organization...)
>>>
>>>
>>> In summary, what you don't want in an Apache project is poisonous PMC
 members, so in my view to be on the PMC once graduating people will 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Michael Müller]

Hi GJ,


due to technical problems I missed one day of the discussion. I'm going 
to catch up.


If possible, please add to to the initial commiters.


Herzliche Grüße - Best Regards,

Michael Müller
Brühl, Germany
blog.mueller-bruehl.de 
it-rezension.de 
@muellermi


Read my books
"Web Development with Java and JSF": https://leanpub.com/jsf
"Java Lambdas und (parallel) Streams" Deutsche Ausgabe: 
https://leanpub.com/lambdas-de
"Java Lambdas and (parallel) Streams" English edition: 
https://leanpub.com/lambdas


On 09/23/2016 03:30 PM, Geertjan Wielenga wrote:

OK. Before the vote, will work on making the initial contributors list as
complete as possible.

What is the process for doing that? Do I simply make changes directly in
the proposal? Do I make the changes public here before adding them to the
proposal? Do I work directly with the mentors via e-mails to discuss and
then after than make the changes?

Thanks,

Geertjan

On Fri, Sep 23, 2016 at 10:02 AM, John D. Ament 
wrote:


Hi Bertrand,

Responses in line.

On Thu, Sep 22, 2016 at 11:54 PM Bertrand Delacretaz <
bdelacre...@apache.org>
wrote:


Hi Geertjan,

I won't have time to look at your whole message now, just a few
clarifications as far as committers/PMC is concerned.

On Fri, Sep 23, 2016 at 7:50 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

...Anyone on the list
will, once the proposal has been voted on and accepted, automatically

be

contributors to the Apache NetBeans project...

They will be commiters to be precise.


Agreed, the way I interpretted Geertjan is that Netbeans contributor == ASF
committer.  They don't have the role of PMC/PPMC presently, so we'll see
how that evolves.



Anyone not on the list will
need to be voted in by the initial contributors, which is a process

that

could be fast, but is still a process and can be avoided by inclusion

in

the initial contributors list...

It's a simple process, the incubating project could very well have one

vote

for N people if that makes sense and they are all wanted.


Its simple but hard.  And no, I don't think we want bulk votes.  What if
someone is +1 add Mark S and -1 add Bertrand D?  At least when its come up
to the IPMC previously, we've recommended against it.



Everyone on the initial contributors list is
automatically part of the PMC.

There's no PMC for an incubating project, just a PPMC as per
http://incubator.apache.org/guides/ppmc.html

That group has no formal power, only the Incubator PMC can vote on the
podling's releases or make other decisions which are binding at the
foundation level.

In practice, you are correct that the PPMC is a PMC in training, but

really

in a podling being a PPMC member doesn't make a difference IMO.


It does.  PPMC has one important job - vote on adding more people.  We hope
that they will learn to look at their releases very carefully while under
incubation.



...Anyone on the list when the project leaves
incubation gets write access to the project for the rest of their

life...

That's correct, but there can be a difference between the committers and
PMC members once the project graduates. As a mentor, when graduating I
would not accept a PMC member who has not contributed during incubation

for

example, whereas a committer that hasn't really been active during
incubation is harmless.

Committers don't have formal power once the project graduates, and if

they

don't behave their commits rights can easily be suspended, temporarily or
permanently. That very rarely happens, just mentioning it to clarify the
risks.


That's... odd to say the least.  I'm not aware of any specific cases,
doesn't mean it hasn't' happened, but I can't think of any cases where it
has (other than one special case recently of someone being asked out of the
organization...)



In summary, what you don't want in an Apache project is poisonous PMC
members, so in my view to be on the PMC once graduating people will have

to

demonstrate during incubation that they are making positive contributions
to it - just being on the initial list of committers doesn't count

towards

that, in my book.


...If the above is accurate, we do need to work on the initial

contributors

list prior to voting on the proposal, quite aside from the infra

assessment...

I still don't think that's required and should be avoided if it delays

the

vote for NetBeans acceptance, as the list of committers can be modified
during incubation with just a bit of additional work.


I don't think this will add a lot of work.  I even gave him the idea of
just generating a script of past committers based on commit history.



If you still want do expand the list during incubation, best is to come

up

with a list of additional names that the existing NetBeans community

feels

deserve to be on that list (maybe based on votes on the existing NetBeans
community's channels), and have the NetBeans 

Re: Preliminary NetBeans cost findings

[Bertrand Delacretaz]

On Mon, Sep 26, 2016 at 7:35 PM, John D. Ament  wrote:
> I see moving plugins.netbeans.org out of Oracle control as being a
> graduation goal, not a start incubation goal.

+1

-Bertrand

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

Re: Preliminary NetBeans cost findings

[John D. Ament]

I see moving plugins.netbeans.org out of Oracle control as being a
graduation goal, not a start incubation goal.

John

On Mon, Sep 26, 2016 at 1:28 PM Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> On Mon, Sep 26, 2016 at 7:19 PM, Jochen Theodorou wrote:
>
>
> > won't plugins.netbeans.org run for another few months with Oracle
> > infrastructure? If it does, is it urgent enough to block incubation? For
> me
> > it does not look that way.
>
>
> Indeed, this is not an urgent issue from the point of view of NetBeans. I
> feel it is an urgent point for some of those in this discussion who want to
> be sure there won't be frustration later down the line when it turns out
> that Apache will not be hosting the NetBeans plugins. Let me reiterate --
> in the same way as Maven plugins are not hosted by Apache, the NetBeans
> community is under no assumption that Apache will be hosting NetBeans
> plugins.
>
> And we will find a solution, we are working on it actively right now,
> though there is no big immediate rush for this.
>
> Gj
>
>
> On Mon, Sep 26, 2016 at 7:19 PM, Jochen Theodorou 
> wrote:
>
> > On 26.09.2016 17:04, Bertrand Delacretaz wrote:
> > [...]
> >
> >> b) We vote on the NetBeans proposal without waiting, and the podling
> >> assumes the risk of having to wait for budget or technical solutions
> >> to run plugins.netbeans.org at or via the ASF.
> >>
> >
> > won't plugins.netbeans.org run for another few months with Oracle
> > infrastructure? If it does, is it urgent enough to block incubation? For
> me
> > it does not look that way.
> >
> > bye Jochen
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Preliminary NetBeans cost findings

[Geertjan Wielenga]

On Mon, Sep 26, 2016 at 7:19 PM, Jochen Theodorou wrote:


> won't plugins.netbeans.org run for another few months with Oracle
> infrastructure? If it does, is it urgent enough to block incubation? For me
> it does not look that way.


Indeed, this is not an urgent issue from the point of view of NetBeans. I
feel it is an urgent point for some of those in this discussion who want to
be sure there won't be frustration later down the line when it turns out
that Apache will not be hosting the NetBeans plugins. Let me reiterate --
in the same way as Maven plugins are not hosted by Apache, the NetBeans
community is under no assumption that Apache will be hosting NetBeans
plugins.

And we will find a solution, we are working on it actively right now,
though there is no big immediate rush for this.

Gj


On Mon, Sep 26, 2016 at 7:19 PM, Jochen Theodorou  wrote:

> On 26.09.2016 17:04, Bertrand Delacretaz wrote:
> [...]
>
>> b) We vote on the NetBeans proposal without waiting, and the podling
>> assumes the risk of having to wait for budget or technical solutions
>> to run plugins.netbeans.org at or via the ASF.
>>
>
> won't plugins.netbeans.org run for another few months with Oracle
> infrastructure? If it does, is it urgent enough to block incubation? For me
> it does not look that way.
>
> bye Jochen
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Preliminary NetBeans cost findings

[Geertjan Wielenga]

PS: GitHub may be an option too, though right now we're working with two or
three different organizations, to see which would be the best home for
plugins.netbeans.org.

On Mon, Sep 26, 2016 at 6:19 PM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Yup. For sure. Together with Bertrand and the organizations volunteering
> to host this service, we'll need to find terms of agreement -- which I
> think we should try to model on those of Sonatype in relation to Apache
> Maven.
>
> However, there are many many months of incubation ahead -- I believe that
> in those months these kinds of arrangements can be made. I am not in a
> hurry to have the vote on the proposal done. On the other hand, I don't
> believe that the finding of a home for plugins.netbeans.org should be a
> blocker for that, given that everyone recognizes the importance of
> plugins.netbeans.org and the range of organizations available who could
> be the host of that service and the fact that we are already exploring this
> with some of them.
>
> Just my 2c on this.
>
> Gj
>
>
> On Mon, Sep 26, 2016 at 6:11 PM, David Nalley  wrote:
>
>> On Mon, Sep 26, 2016 at 11:21 AM, Geertjan Wielenga
>>  wrote:
>> > We're actively discussing with various organizations about the future
>> home
>> > of plugins.netbeans.org. We'd certainly not want to go into the future
>> > without our Plugin Portal and plugins, there's no point in pointing out
>> to
>> > the NetBeans community the importance of its plugins. :-) I am
>> comfortable
>> > that we'll find a home for them in one organization or another. We have
>> no
>> > intention nor any expectation that Apache will be the future home for
>> > plugins.netbeans.org, in the same way as Maven's plugins etc are also
>> not
>> > hosted on Apache.
>> >
>> > Hope the above helps,
>> >
>>
>> It helps, but ultimately, if the project is going to come to the ASF,
>> the Foundation will have to sign off on the terms of any such
>> agreement once it comes to the ASF. I know what we have a bit of a
>> chicken-egg situation[1] , so I'd urge you to have someone involved
>> from the ASF side - your champion looks to be in an ideal place to
>> help there.
>>
>>
>> [1] http://idioms.thefreedictionary.com/a+chicken+and+egg+situation
>>
>>
>> --David
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

Re: Preliminary NetBeans cost findings

[Jochen Theodorou]

On 26.09.2016 17:04, Bertrand Delacretaz wrote:
[...]

b) We vote on the NetBeans proposal without waiting, and the podling
assumes the risk of having to wait for budget or technical solutions
to run plugins.netbeans.org at or via the ASF.


won't plugins.netbeans.org run for another few months with Oracle 
infrastructure? If it does, is it urgent enough to block incubation? For 
me it does not look that way.


bye Jochen

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

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: Preliminary NetBeans cost findings

[Geertjan Wielenga]

Yup. For sure. Together with Bertrand and the organizations volunteering to
host this service, we'll need to find terms of agreement -- which I think
we should try to model on those of Sonatype in relation to Apache Maven.

However, there are many many months of incubation ahead -- I believe that
in those months these kinds of arrangements can be made. I am not in a
hurry to have the vote on the proposal done. On the other hand, I don't
believe that the finding of a home for plugins.netbeans.org should be a
blocker for that, given that everyone recognizes the importance of
plugins.netbeans.org and the range of organizations available who could be
the host of that service and the fact that we are already exploring this
with some of them.

Just my 2c on this.

Gj


On Mon, Sep 26, 2016 at 6:11 PM, David Nalley  wrote:

> On Mon, Sep 26, 2016 at 11:21 AM, Geertjan Wielenga
>  wrote:
> > We're actively discussing with various organizations about the future
> home
> > of plugins.netbeans.org. We'd certainly not want to go into the future
> > without our Plugin Portal and plugins, there's no point in pointing out
> to
> > the NetBeans community the importance of its plugins. :-) I am
> comfortable
> > that we'll find a home for them in one organization or another. We have
> no
> > intention nor any expectation that Apache will be the future home for
> > plugins.netbeans.org, in the same way as Maven's plugins etc are also
> not
> > hosted on Apache.
> >
> > Hope the above helps,
> >
>
> It helps, but ultimately, if the project is going to come to the ASF,
> the Foundation will have to sign off on the terms of any such
> agreement once it comes to the ASF. I know what we have a bit of a
> chicken-egg situation[1] , so I'd urge you to have someone involved
> from the ASF side - your champion looks to be in an ideal place to
> help there.
>
>
> [1] http://idioms.thefreedictionary.com/a+chicken+and+egg+situation
>
>
> --David
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Preliminary NetBeans cost findings

[David Nalley]

On Mon, Sep 26, 2016 at 11:21 AM, Geertjan Wielenga
 wrote:
> We're actively discussing with various organizations about the future home
> of plugins.netbeans.org. We'd certainly not want to go into the future
> without our Plugin Portal and plugins, there's no point in pointing out to
> the NetBeans community the importance of its plugins. :-) I am comfortable
> that we'll find a home for them in one organization or another. We have no
> intention nor any expectation that Apache will be the future home for
> plugins.netbeans.org, in the same way as Maven's plugins etc are also not
> hosted on Apache.
>
> Hope the above helps,
>

It helps, but ultimately, if the project is going to come to the ASF,
the Foundation will have to sign off on the terms of any such
agreement once it comes to the ASF. I know what we have a bit of a
chicken-egg situation[1] , so I'd urge you to have someone involved
from the ASF side - your champion looks to be in an ideal place to
help there.


[1] http://idioms.thefreedictionary.com/a+chicken+and+egg+situation


--David

-
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 

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' 

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 

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 

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: Preliminary NetBeans cost findings

[Geertjan Wielenga]

We're actively discussing with various organizations about the future home
of plugins.netbeans.org. We'd certainly not want to go into the future
without our Plugin Portal and plugins, there's no point in pointing out to
the NetBeans community the importance of its plugins. :-) I am comfortable
that we'll find a home for them in one organization or another. We have no
intention nor any expectation that Apache will be the future home for
plugins.netbeans.org, in the same way as Maven's plugins etc are also not
hosted on Apache.

Hope the above helps,

Geertjan


On Mon, Sep 26, 2016 at 5:04 PM, Bertrand Delacretaz  wrote:

> Hi,
>
> On Mon, Sep 26, 2016 at 4:40 PM, David Nalley  wrote:
> > On Mon, Sep 26, 2016 at 1:52 AM, Bertrand Delacretaz
> >  wrote:
> >> ...my suggestion is for infra (David or Greg) to give us their ok to
> >> proceed with the vote...
>
> > ...The Office of the President doesn't have any oversight over PMCs, so
> > strictly speaking the IPMC can proceed with this however it likes on
> > whatever timetable it sees fit...
>
> My intention as the NetBeans champion is to be collaborative, so even
> though you guys have no formal power w.r.t voting the podling in I
> think it's worth agreeing on how we proceed.
>
> > ...With my VP Infra/member/IPMC member hats on, I'd prefer seeing the
> > plan for plugins.nb.o in place before you consider this
>
> I see two options then:
>
> a) We don't vote on the NetBeans proposal until the current NetBeans
> team + mentors have worked with infra (on this list I assume) on a
> plan for plugins.netbeans.org once NetBeans moves to the ASF. I
> suspect this can easily take two weeks.
>
> b) We vote on the NetBeans proposal without waiting, and the podling
> assumes the risk of having to wait for budget or technical solutions
> to run plugins.netbeans.org at or via the ASF.
>
> Do people agree that these options make sense, and Geertjan which one
> is your and your team's favorite?
>
> -Bertrand
>
> -
> 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: Preliminary NetBeans cost findings

[Bertrand Delacretaz]

Hi,

On Mon, Sep 26, 2016 at 4:40 PM, David Nalley  wrote:
> On Mon, Sep 26, 2016 at 1:52 AM, Bertrand Delacretaz
>  wrote:
>> ...my suggestion is for infra (David or Greg) to give us their ok to
>> proceed with the vote...

> ...The Office of the President doesn't have any oversight over PMCs, so
> strictly speaking the IPMC can proceed with this however it likes on
> whatever timetable it sees fit...

My intention as the NetBeans champion is to be collaborative, so even
though you guys have no formal power w.r.t voting the podling in I
think it's worth agreeing on how we proceed.

> ...With my VP Infra/member/IPMC member hats on, I'd prefer seeing the
> plan for plugins.nb.o in place before you consider this

I see two options then:

a) We don't vote on the NetBeans proposal until the current NetBeans
team + mentors have worked with infra (on this list I assume) on a
plan for plugins.netbeans.org once NetBeans moves to the ASF. I
suspect this can easily take two weeks.

b) We vote on the NetBeans proposal without waiting, and the podling
assumes the risk of having to wait for budget or technical solutions
to run plugins.netbeans.org at or via the ASF.

Do people agree that these options make sense, and Geertjan which one
is your and your team's favorite?

-Bertrand

-
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 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=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: Preliminary NetBeans cost findings

[David Nalley]

On Mon, Sep 26, 2016 at 1:52 AM, Bertrand Delacretaz
 wrote:
> On Mon, Sep 26, 2016 at 5:57 AM, David Nalley  wrote:
>> ...My guess is, based on Daniels estimate, that
>> first year is 13-30k - each year thereafter is 3-10k per year in costs..
>
> Are these estimates sufficient for our infra team to give us their ok
> to proceed with the NetBeans vote, or do you guys need more time?
>
> I'm asking because
>
> a) discussions about the current proposal are currently going into all
> kinds of side tracks which are not really useful as far as informing
> the NetBeans vote decision, IMO
>
> and b) as it's the first time we do such an assessment for an incoming
> podling, IMO we shouldn't make NetBeans wait more than strictly
> needed, while we refine this costing thing internally.
>
> So my suggestion is for infra (David or Greg) to give us their ok to
> proceed with the vote if you guys agree, and sort out the (important)
> budget details internally in parallel.
>

The Office of the President doesn't have any oversight over PMCs, so
strictly speaking the IPMC can proceed with this however it likes on
whatever timetable it sees fit. However, please don't be surprised
if/when we deny requests to Infrastructure because they exceed what we
have available in time/staff/money; we're also likely to push a number
of tasks down to the podling itself.

With my VP Infra/member/IPMC member hats on, I'd prefer seeing the
plan for plugins.nb.o in place before you consider this. As Greg said
elsewhere, I don't think that piece can be ignored - it's vital to the
community, and any agreement would need to be formally agreed to by
the foundation (similar to the contract we have with Sonatype) if the
project moved here. I'd also point out the comments from Ross to the
IPMC about budget and get that squared away before you proceed.

--David

-
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

[RESULT] [IP CLEARANCE] JWPlayer SQE (Streaming Query Engine)

[P. Taylor Goetz]

With 72 hours having elapsed with no objections, this vote passes.

-Taylor

> On Sep 21, 2016, at 2:41 PM, P. Taylor Goetz  wrote:
> 
> Apache Storm has received a code donation for JWPlayer SQE (Streaming Query 
> Engine):
> 
> http://incubator.apache.org/ip-clearance/storm-sqe.html 
> 
> 
> The source code can be found at https://github.com/jwplayer/SQE 
>  with the following git commit SHA: 
> 68dbbde1117a043a7bded73d89d3d82238715a4b
> 
> Please vote to approve this contribution. Lazy consensus applies. If no -1
> votes are cast within the next 72 hours, the vote passes.
> 
> Regards,
> 
> -Taylor



signature.asc
Description: Message signed with OpenPGP using GPGMail

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: Fwd: [VOTE] Release SAMOA 0.4.0 (incubating) RC1

[Jean-Baptiste Onofré]

+1 (binding)

Checked:
- Build OK
- LICENSE, DISCLAIMER, NOTICE look good
- Signatures OK
- ASF headers present

Regards
JB

On 09/19/2016 03:50 PM, Nicolas Kourtellis wrote:

Hi all,

Our new release has been voted from the Apache SAMOA team and we are
opening the vote to the incubator email list for testing.

Please vote on releasing the following release candidate as Apache
SAMOA (incubating)
version 0.4.0. This release will be the second release for SAMOA in the
incubator.

-
The commit to be voted on is in the branch "releases/0.4.0-incubating"
(commit fc39238dd7d3674c069a8142312da8c1812bc907):
https://git1-us-west.apache.org/repos/asf/incubator-samoa/
repo?p=incubator-samoa.git;a=commit;h=fc39238dd7d3674c069a8142312da8
c1812bc907

Tag v0.4.0-incubating:
https://git1-us-west.apache.org/repos/asf/incubator-samoa/
repo?p=incubator-samoa.git;a=tag;h=aa5bd941ccbed1aabb46b8119049ac1bb293c3a2

Release artifacts are signed with the following key:
*https://people.apache.org/keys/committer/nkourtellis.asc
*

The staging repository for this release can be found at:
https://repository.apache.org/content/repositories/staging/
org/apache/samoa/samoa/0.4.0-incubating/

The developer's version artifacts:
https://dist.apache.org/repos/dist/dev/incubator/samoa/0.4.0-incubating-rc1/

-

Please vote on releasing this package as Apache SAMOA 0.4.0 (incubating).

The vote is open for the next 72 hours and passes if a majority of at least
three +1 PPMC votes are cast.

[ ] +1 Release this package as Apache SAMOA 0.4.0 (incubating)
[ ] -1 Do not release this package because ...

I'm +1 on the release.

Cheers,

Nicolas





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

[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=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: Request to join Apache Streams (Incubating) as Mentor

[Sergio Fernández]

OK. Just try to properly report all this in your next cycle (including
links to each important discussion/vote mail) to have it properly tracked.

All the best for the podling.

On Mon, Sep 26, 2016 at 2:37 PM, Ate Douma  wrote:

> On 2016-09-26 09:42, Sergio Fernández wrote:
>
>> How this vote relates with the other thread about retiring Apache Streams
>> to the attic?
>>
>> https://lists.apache.org/thread.html/077e46f67271c2e2e2d406b
>> 8b1f8cf9ae633a71bccffefdfd206d0b4@%3Cgeneral.incubator.apache.org%3E
>>
>> I'm a bit confused... maybe I missed some mails.
>>
> I guess so :-)
>
> There has been new feedback and input which potentially might bring this
> podling back on its feet.
> And the offer from Suneel to become mentor for Apache Streams is part of
> that.
>
> For these reasons I've cancelled the vote for retirement, for now.
>
> Concerning the process for assigning Suneel as mentor, can we assume lazy
> consensus and just 'make it so' in a few days, if nobody objects?
>
> Thanks, Ate
>
>
>
>>
>> On Sun, Sep 25, 2016 at 12:25 PM, Ate Douma  wrote:
>>
>> I'm happy to add and have Suneel join me as mentor for Apache Streams.
>>>
>>> I can't find anything about this: Is there any formal process or voting
>>> needed
>>> before I make this so?
>>>
>>> Ate
>>>
>>> On 2016-09-23 19:51, Suneel Marthi wrote:
>>>
>>> 



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


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: [VOTE] Release SAMOA 0.4.0 (incubating) RC1

[Justin Mclean]

Hi,

> I think we forget to close the vote and announce the results. Apologies for 
> that.

As far as I could tell I think you only had 2 +1 binding votes before I voted 
so I’m not sure the vote was closed.

Please take more care in future and please send a RESULT email on this vote.

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

Re: Request to join Apache Streams (Incubating) as Mentor

[Ate Douma]

On 2016-09-26 09:42, Sergio Fernández wrote:

How this vote relates with the other thread about retiring Apache Streams
to the attic?

https://lists.apache.org/thread.html/077e46f67271c2e2e2d406b8b1f8cf9ae633a71bccffefdfd206d0b4@%3Cgeneral.incubator.apache.org%3E

I'm a bit confused... maybe I missed some mails.

I guess so :-)

There has been new feedback and input which potentially might bring this podling 
back on its feet.

And the offer from Suneel to become mentor for Apache Streams is part of that.

For these reasons I've cancelled the vote for retirement, for now.

Concerning the process for assigning Suneel as mentor, can we assume lazy
consensus and just 'make it so' in a few days, if nobody objects?

Thanks, Ate




On Sun, Sep 25, 2016 at 12:25 PM, Ate Douma  wrote:


I'm happy to add and have Suneel join me as mentor for Apache Streams.

I can't find anything about this: Is there any formal process or voting
needed
before I make this so?

Ate

On 2016-09-23 19:51, Suneel Marthi wrote:







-
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] Release SAMOA 0.4.0 (incubating) RC1

[Gianmarco De Francisci Morales]

Hi Justin,

I think we forget to close the vote and announce the results. Apologies for
that.
Thanks for checking the release.

The headers are automatically generated by a mvn plugin, we will try to fix
them by changing its configuration.

Thanks,

-- Gianmarco

On Mon, Sep 26, 2016 at 11:04 AM, Dor Ben Dov 
wrote:

> Justin,
>
> About Apache Samoa - Any known plugin to Hbase , Spark ?
>
> Regards,
> Dor Ben Dov
>
> -Original Message-
> From: Justin Mclean [mailto:jus...@classsoftware.com]
> Sent: יום ב 26 ספטמבר 2016 10:40
> To: general@incubator.apache.org
> Subject: Re: [VOTE] Release SAMOA 0.4.0 (incubating) RC1
>
> Hi,
>
> +1 binding
>
> I checked:
> - incubating in name
> - signatures and hashes correct
> - DISCLAIMER exists
> - LICENSE and NOTICE good
> - No unexpected binary in source
> - Looks like most if not all files have incorrect ASF headers. The ASF
> header should not include a copyright line [2]. Not that it matters but the
> copyright date range is also incorrect. Please remove in next release.
> - Can compile from source
>
> Some very minor things:
> - would be good if release was signed by an apache email address (not a
> gmail one)
> - might want to update the copyright year in this file [1]
>
> It also looks like you may of got ahead of yourself and published the
> release before the incubator vote results and linked to it from your web
> site. Please don’t do that.
>
> Thanks,
> Justin
>
> 1. ./samoa-0.4.0-incubating/samoa-api/src/main/java/org/
> apache/samoa/core/Globals.java
> 2. https://www.apache.org/legal/src-headers.html#headers
> 3. https://www.apache.org/dist/incubator/samoa/0.4.0-incubating/
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

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

RE: [VOTE] Release SAMOA 0.4.0 (incubating) RC1

[Dor Ben Dov]

Justin, 

About Apache Samoa - Any known plugin to Hbase , Spark ? 

Regards,
Dor Ben Dov

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com] 
Sent: יום ב 26 ספטמבר 2016 10:40
To: general@incubator.apache.org
Subject: Re: [VOTE] Release SAMOA 0.4.0 (incubating) RC1

Hi,

+1 binding

I checked:
- incubating in name
- signatures and hashes correct
- DISCLAIMER exists
- LICENSE and NOTICE good
- No unexpected binary in source
- Looks like most if not all files have incorrect ASF headers. The ASF header 
should not include a copyright line [2]. Not that it matters but the copyright 
date range is also incorrect. Please remove in next release.
- Can compile from source

Some very minor things:
- would be good if release was signed by an apache email address (not a gmail 
one)
- might want to update the copyright year in this file [1]

It also looks like you may of got ahead of yourself and published the release 
before the incubator vote results and linked to it from your web site. Please 
don’t do that.

Thanks,
Justin

1. 
./samoa-0.4.0-incubating/samoa-api/src/main/java/org/apache/samoa/core/Globals.java
2. https://www.apache.org/legal/src-headers.html#headers
3. https://www.apache.org/dist/incubator/samoa/0.4.0-incubating/
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

Re: Request to join Apache Streams (Incubating) as Mentor

[Sergio Fernández]

How this vote relates with the other thread about retiring Apache Streams
to the attic?

https://lists.apache.org/thread.html/077e46f67271c2e2e2d406b8b1f8cf9ae633a71bccffefdfd206d0b4@%3Cgeneral.incubator.apache.org%3E

I'm a bit confused... maybe I missed some mails.


On Sun, Sep 25, 2016 at 12:25 PM, Ate Douma  wrote:

> I'm happy to add and have Suneel join me as mentor for Apache Streams.
>
> I can't find anything about this: Is there any formal process or voting
> needed
> before I make this so?
>
> Ate
>
> On 2016-09-23 19:51, Suneel Marthi wrote:
>
>> 
>>
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: [VOTE] Release SAMOA 0.4.0 (incubating) RC1

[Justin Mclean]

Hi,

+1 binding

I checked:
- incubating in name
- signatures and hashes correct
- DISCLAIMER exists
- LICENSE and NOTICE good
- No unexpected binary in source
- Looks like most if not all files have incorrect ASF headers. The ASF header 
should not include a copyright line [2]. Not that it matters but the copyright 
date range is also incorrect. Please remove in next release.
- Can compile from source

Some very minor things:
- would be good if release was signed by an apache email address (not a gmail 
one)
- might want to update the copyright year in this file [1]

It also looks like you may of got ahead of yourself and published the release 
before the incubator vote results and linked to it from your web site. Please 
don’t do that.

Thanks,
Justin

1. 
./samoa-0.4.0-incubating/samoa-api/src/main/java/org/apache/samoa/core/Globals.java
2. https://www.apache.org/legal/src-headers.html#headers
3. https://www.apache.org/dist/incubator/samoa/0.4.0-incubating/
-
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=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