Re: develop: missing 1.2.0-SNAPSHOT -> 1.3.0-SNAPSHOT conversions?

[Christofer Dutz]

Oh ... have to add adding of the profiles to my documentation. I’ll fix the 
version mess as Sonia’s I’m at work.

Outlook für iOS beziehen

From: Dale LaBossiere 
Sent: Tuesday, November 7, 2017 12:33:28 AM
To: dev@edgent.apache.org
Subject: develop: missing 1.2.0-SNAPSHOT -> 1.3.0-SNAPSHOT conversions?

Hi Chris,

On the develop branch, I did a grep and see tons of 1.2.0-SNAPSHOT specs still:
all the poms under java7 and android,
plus distribution/pom.xml, the edgent.runtime.version property in pom.xml,
and (not surprisingly) several places under samples

For the samples ones, I create PR-319  
https://github.com/apache/incubator-edgent/pull/319 

[also another chance to see how the merge of this PR ends up looking the the 
network graph]

— Dale

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Dale LaBossiere]

Is this something INFRA has to do?  i.e., on my fork I see a settings widget 
where I can change that sort of thing for it, but I don’t see that widget on 
https://github.com/apache/incubator-edgent 
   Or maybe one of the other 
committers or mentors has the access rights to do that???

> On Nov 6, 2017, at 6:02 PM, Christofer Dutz  wrote:
> ...
> 
> I think by making develop the default branch in github, this should make 
> things a lot easier.

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Dale LaBossiere]

Just as a reminder I’m on vacation starting this Wed, 08 Nov and won’t be 
available for further review or participation in this unit I return on the 
20th.  Sorry for the bad timing!

— Dale

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Dale LaBossiere]

Don’t forget that the release needs to include a source bundle for the Samples 
(the separate the samples into their own repo task).

I know the samples are currently still part of the incubating-edgent repo but 
by design they aren’t included in the release bundle.  And all of the pending 
changes to the website to go along with the release are dependent on there 
being a separate Samples source bundle available for download.

Thanks!

> On Nov 6, 2017, at 4:25 PM, Christofer Dutz  wrote:
> ...
> Just tell me, if anything else needs to go in the release. I think we could 
> initiate the real release in a few days, if you agree.

develop: missing 1.2.0-SNAPSHOT -> 1.3.0-SNAPSHOT conversions?

[Dale LaBossiere]

Hi Chris,

On the develop branch, I did a grep and see tons of 1.2.0-SNAPSHOT specs still: 
all the poms under java7 and android,
plus distribution/pom.xml, the edgent.runtime.version property in pom.xml, 
and (not surprisingly) several places under samples

For the samples ones, I create PR-319  
https://github.com/apache/incubator-edgent/pull/319 

[also another chance to see how the merge of this PR ends up looking the the 
network graph]

— Dale

[GitHub] incubator-edgent pull request #319: Update sample poms for 1.2.0-SNAPSHOT to...

[dlaboss]

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/319

Update sample poms for 1.2.0-SNAPSHOT to 1.3.0-SNAPSHOT

commit a221f2f changed a lot of the poms but didn't get these.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent 
samples_next_snapshot_version

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/319.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #319


commit cf27ccbe53b8edf47233ba28ab76177174fdeb47
Author: Dale LaBossiere 
Date:   2017-11-06T23:30:09Z

Update sample poms for 1.2.0-SNAPSHOT to 1.3.0-SNAPSHOT

commit a221f2f changed a lot of the poms but didn't get these.




---

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Christofer Dutz]

Hi Dale,

I think by making develop the default branch in github, this should make things 
a lot easier.

Chris



Am 06.11.17, 23:41 schrieb "Dale LaBossiere" :

Hi Chris, this is great!

I just merged PR-318 [1] into develop.  The commits in that PR should be 
included in the release.  I’ll stop adding new things - didn’t know you’d be 
creating the release branch this soon :-)

Previously we all used the normal GitHub workflow as noted in 
DEVELOPMENT.md - essentially all changes to a project branch, previously we 
only had master, came about by merging a PR to it.   Presumably now that means 
all changes to the “develop” branch should arise from merging a PR.  That’s 
what I did with my two post-merge-features/maven-to-develop changes: PR-317 and 
PR-318.  Just verifying that we’re all on the same page here going forward.  
Related, isn’t there some way to make the PR-creation flow setup the PR to 
merge to “develop” by default?

[1] https://github.com/apache/incubator-edgent/pull/318 


— Dale

> On Nov 6, 2017, at 4:25 PM, Christofer Dutz  
wrote:
> ...
> So, you might have noticed, I just bumped the version of develop to 
1.3.0-SNAPSHOT and now there is a “release/1.2” branch. Also, the Multibranch 
pipeline on Jenkins kicked in nicely and almost instantly setup a new build job 
for the release branch. Both the bumped develop as well as the release branch 
built nicely. 
> 
> Just tell me, if anything else needs to go in the release. I think we 
could initiate the real release in a few days, if you agree.
> 
> In develop I’m writing a step by step guide about all the steps the how’s 
and why’s and will commit that once it’s finished.
> 
> Chris

confused by network graph - is something amiss?

[Dale LaBossiere]

Chris, 

I’m confused by what I’m seeing in the network graph on GitHub [1] and wonder 
if something’s amiss
in either the way that the feature/maven branch was merged to develop or the 
config of my fork’s [4] develop branch or ???

Previously I noted that I had created and merged PR-317 [2] and PR-318 [3] to 
the develop branch.

In the graph, the merge of change 31bc375 via PR-317 looks weird.  What did it 
get merged to?
I expected to see that “merge Pull Request #317” merge from the black branch to 
the purple (presumably “develop”) one… but it isn’t drawn that way. It ends up 
getting there via a “Merge remote tracking branch…” commit of your’s 
(9f75a0f)???

I think the merge of PR-318 looks OK (to the purple/develop branch) but my 
edgent-393-ranges task branch didn’t visually branch off the purple/develop 
branch the way I expected.

For what it’s worth here’s the config of my clone of my fork [4]

@Dales-MacBook-Pro:757> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
nothing to commit, working tree clean
@Dales-MacBook-Pro:758> git remote -v
origin  https://github.com/dlaboss/incubator-edgent.git (fetch)
origin  https://github.com/dlaboss/incubator-edgent.git (push)
upstreamhttps://github.com/apache/incubator-edgent.git (fetch)
upstreamhttps://github.com/apache/incubator-edgent.git (push)
@Dales-MacBook-Pro:759> 

[1] https://github.com/apache/incubator-edgent/network 

[2] https://github.com/apache/incubator-edgent/pull/317 

[3] https://github.com/apache/incubator-edgent/pull/318 

[4] https://github.com/dlaboss/incubator-edgent 

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Dale LaBossiere]

Hi Chris, this is great!

I just merged PR-318 [1] into develop.  The commits in that PR should be 
included in the release.  I’ll stop adding new things - didn’t know you’d be 
creating the release branch this soon :-)

Previously we all used the normal GitHub workflow as noted in DEVELOPMENT.md - 
essentially all changes to a project branch, previously we only had master, 
came about by merging a PR to it.   Presumably now that means all changes to 
the “develop” branch should arise from merging a PR.  That’s what I did with my 
two post-merge-features/maven-to-develop changes: PR-317 and PR-318.  Just 
verifying that we’re all on the same page here going forward.  Related, isn’t 
there some way to make the PR-creation flow setup the PR to merge to “develop” 
by default?

[1] https://github.com/apache/incubator-edgent/pull/318 


— Dale

> On Nov 6, 2017, at 4:25 PM, Christofer Dutz  wrote:
> ...
> So, you might have noticed, I just bumped the version of develop to 
> 1.3.0-SNAPSHOT and now there is a “release/1.2” branch. Also, the Multibranch 
> pipeline on Jenkins kicked in nicely and almost instantly setup a new build 
> job for the release branch. Both the bumped develop as well as the release 
> branch built nicely. 
> 
> Just tell me, if anything else needs to go in the release. I think we could 
> initiate the real release in a few days, if you agree.
> 
> In develop I’m writing a step by step guide about all the steps the how’s and 
> why’s and will commit that once it’s finished.
> 
> Chris

[GitHub] incubator-edgent pull request #318: Edgent-393 add Ranges.outsideOf()

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/318


---

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Christofer Dutz]

Hi All,

So, you might have noticed, I just bumped the version of develop to 
1.3.0-SNAPSHOT and now there is a “release/1.2” branch. Also, the Multibranch 
pipeline on Jenkins kicked in nicely and almost instantly setup a new build job 
for the release branch. Both the bumped develop as well as the release branch 
built nicely. 

Just tell me, if anything else needs to go in the release. I think we could 
initiate the real release in a few days, if you agree.

In develop I’m writing a step by step guide about all the steps the how’s and 
why’s and will commit that once it’s finished.

Chris



Am 06.11.17, 20:12 schrieb "William Marshall" :

+1, I like the process.

If I understand correctly, all development work is now happening on the
develop branch, and therefore master is only ever updated when a new
release is created.

On Mon, Nov 6, 2017 at 10:39 AM, Susan Cline  wrote:

> +1 - thanks for all the hard work on this!
>
> Susan
>
> > On Nov 6, 2017, at 12:20 AM, Christofer Dutz 
> wrote:
> >
> > Hi all,
> >
> > after finally merging back all changes we did in the last few months, I
> think it would be a good time to do a first release using Maven. This way
> we can give the Maven build its final and ultimate test and hopefully 
start
> releasing a lot more often.
> >
> > Even if I think the current development speed is still quite low, I
> would propose to start doing releases the following way:
> >
> >
> >  *   The intention to release is indicated by a “[DISCUSS]” Thread in
> which the intention for a new release is communicated
> >  *   After there is a general consensus on doing a new release a release
> branch is created and the version develop is incremented (In this case, I
> would create a “release/1.2” branch in which the version remains unchanged
> and the version of develop is incremented to “1.3.0-SNAPSHOT”
> >  *   As soon as this is done a “[LAST CALL]” Thread is started asking
> everyone to check the release branch, bring in last changes and fixes.
> >  *   As soon as the “[LAST CALL]” thread implies all are ready, a
> Release Candidate is created. We’ll be using the maven-release-plugin for
> that. This will create a so-called staging repository in Apache’s Nexus
> (This is like a maven repository, but it contains only the artifacts of 
the
> release candidate)
> >  *   As soon as the RC is staged, a “[VOTE]” Thread is started
> containing a link to the staging repository.
> >  *   As soon as the Vote passes, the staging repo is set to “release”
> and the artifacts automatically go to Apache’s public maven repo and get
> synced to Maven Central.
> >  *   Now the state of the release gets merged to “master” so now
> “master” represents the state of the last release done by the project.
> >  *   If there were any bugfixes, patches etc. applied to the release
> branch, these changes need to be merged to the develop branch too.
> >
> > What do you think? Should we start the games?
> >
> > Chris
>
>

[GitHub] incubator-edgent pull request #318: Edgent-393 add Ranges.outsideOf()

[dlaboss]

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/318

Edgent-393 add Ranges.outsideOf()



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent edgent-393-ranges

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/318.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #318


commit 356b63817d85522bc1f8517bf3b857fdc0335702
Author: Dale LaBossiere 
Date:   2017-11-06T21:04:04Z

Edgent-393 add Ranges.outsideOf()




---

[jira] [Commented] (EDGENT-393) Wish for Ranges.outsideOf()

[Dale LaBossiere (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240903#comment-16240903
 ] 

Dale LaBossiere commented on EDGENT-393:


Upon further thinking I'm less ready to commit to asking for / adding 
Functions.not().
Instead I'm changing this JIRA to ask for a Range specific enhancement
to accomplish the same effect:  Ranges.outsideOf().

Used like:
{code}
TStream ...
.filter(Ranges.outsideOf(Ranges.closed(100,200))) // true if outside 
[100..200]
{code}



> Wish for Ranges.outsideOf()
> ---
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
>  Issue Type: Wish
>  Components: API
>Reporter: Dale LaBossiere
>Priority: Minor
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside 
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology 
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly 
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in 
> other cases:
> {code}
> static  Predicate not(Predicate predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per 
> tuple  against the "out of line" myRange instantiation approach.  But I'd get 
> to choose which was more important to me.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (EDGENT-393) Wish for Ranges.outsideOf()

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere updated EDGENT-393:
---
Summary: Wish for Ranges.outsideOf()  (was: Wish for Functions.not())

> Wish for Ranges.outsideOf()
> ---
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
>  Issue Type: Wish
>  Components: API
>Reporter: Dale LaBossiere
>Priority: Minor
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside 
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology 
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly 
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in 
> other cases:
> {code}
> static  Predicate not(Predicate predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per 
> tuple  against the "out of line" myRange instantiation approach.  But I'd get 
> to choose which was more important to me.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (EDGENT-393) Wish for Ranges.outsideOf()

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere reassigned EDGENT-393:
--

Assignee: Dale LaBossiere

> Wish for Ranges.outsideOf()
> ---
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
>  Issue Type: Wish
>  Components: API
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside 
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology 
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly 
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in 
> other cases:
> {code}
> static  Predicate not(Predicate predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per 
> tuple  against the "out of line" myRange instantiation approach.  But I'd get 
> to choose which was more important to me.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[William Marshall]

+1, I like the process.

If I understand correctly, all development work is now happening on the
develop branch, and therefore master is only ever updated when a new
release is created.

On Mon, Nov 6, 2017 at 10:39 AM, Susan Cline  wrote:

> +1 - thanks for all the hard work on this!
>
> Susan
>
> > On Nov 6, 2017, at 12:20 AM, Christofer Dutz 
> wrote:
> >
> > Hi all,
> >
> > after finally merging back all changes we did in the last few months, I
> think it would be a good time to do a first release using Maven. This way
> we can give the Maven build its final and ultimate test and hopefully start
> releasing a lot more often.
> >
> > Even if I think the current development speed is still quite low, I
> would propose to start doing releases the following way:
> >
> >
> >  *   The intention to release is indicated by a “[DISCUSS]” Thread in
> which the intention for a new release is communicated
> >  *   After there is a general consensus on doing a new release a release
> branch is created and the version develop is incremented (In this case, I
> would create a “release/1.2” branch in which the version remains unchanged
> and the version of develop is incremented to “1.3.0-SNAPSHOT”
> >  *   As soon as this is done a “[LAST CALL]” Thread is started asking
> everyone to check the release branch, bring in last changes and fixes.
> >  *   As soon as the “[LAST CALL]” thread implies all are ready, a
> Release Candidate is created. We’ll be using the maven-release-plugin for
> that. This will create a so-called staging repository in Apache’s Nexus
> (This is like a maven repository, but it contains only the artifacts of the
> release candidate)
> >  *   As soon as the RC is staged, a “[VOTE]” Thread is started
> containing a link to the staging repository.
> >  *   As soon as the Vote passes, the staging repo is set to “release”
> and the artifacts automatically go to Apache’s public maven repo and get
> synced to Maven Central.
> >  *   Now the state of the release gets merged to “master” so now
> “master” represents the state of the last release done by the project.
> >  *   If there were any bugfixes, patches etc. applied to the release
> branch, these changes need to be merged to the develop branch too.
> >
> > What do you think? Should we start the games?
> >
> > Chris
>
>

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Susan Cline]

+1 - thanks for all the hard work on this!

Susan

> On Nov 6, 2017, at 12:20 AM, Christofer Dutz  
> wrote:
> 
> Hi all,
> 
> after finally merging back all changes we did in the last few months, I think 
> it would be a good time to do a first release using Maven. This way we can 
> give the Maven build its final and ultimate test and hopefully start 
> releasing a lot more often.
> 
> Even if I think the current development speed is still quite low, I would 
> propose to start doing releases the following way:
> 
> 
>  *   The intention to release is indicated by a “[DISCUSS]” Thread in which 
> the intention for a new release is communicated
>  *   After there is a general consensus on doing a new release a release 
> branch is created and the version develop is incremented (In this case, I 
> would create a “release/1.2” branch in which the version remains unchanged 
> and the version of develop is incremented to “1.3.0-SNAPSHOT”
>  *   As soon as this is done a “[LAST CALL]” Thread is started asking 
> everyone to check the release branch, bring in last changes and fixes.
>  *   As soon as the “[LAST CALL]” thread implies all are ready, a Release 
> Candidate is created. We’ll be using the maven-release-plugin for that. This 
> will create a so-called staging repository in Apache’s Nexus (This is like a 
> maven repository, but it contains only the artifacts of the release candidate)
>  *   As soon as the RC is staged, a “[VOTE]” Thread is started containing a 
> link to the staging repository.
>  *   As soon as the Vote passes, the staging repo is set to “release” and the 
> artifacts automatically go to Apache’s public maven repo and get synced to 
> Maven Central.
>  *   Now the state of the release gets merged to “master” so now “master” 
> represents the state of the last release done by the project.
>  *   If there were any bugfixes, patches etc. applied to the release branch, 
> these changes need to be merged to the develop branch too.
> 
> What do you think? Should we start the games?
> 
> Chris

[GitHub] incubator-edgent pull request #317: update doc: RELEASE_NOTES, samples/READM...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/317


---

[GitHub] incubator-edgent pull request #317: update doc: RELEASE_NOTES, samples/READM...

[dlaboss]

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/317

update doc: RELEASE_NOTES, samples/README.md



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent update-doc

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/317.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #317


commit 31bc375ebb34c0f404d01b854f3179b639b1a45b
Author: Dale LaBossiere 
Date:   2017-11-06T18:12:42Z

update doc: RELEASE_NOTES, samples/README.md




---

[jira] [Commented] (EDGENT-219) new keyedTimeBatchWindowTest isn't robust?

[Dale LaBossiere (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240593#comment-16240593
 ] 

Dale LaBossiere commented on EDGENT-219:


some rework of WindowsTest has occurred as part of PR-309

> new keyedTimeBatchWindowTest isn't robust?
> --
>
> Key: EDGENT-219
> URL: https://issues.apache.org/jira/browse/EDGENT-219
> Project: Edgent
>  Issue Type: Test
>  Components: Test
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> From a recent travis-ci run, the test failed.  Presumably just a test timing 
> sensitivity issue?  If so can it be desensitized?
> [junit] Running quarks.test.window.WindowTest
> [junit] Testsuite: quarks.test.window.WindowTest
> [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 
> 39.843 sec
> [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 
> 39.843 sec
> [junit] 
> [junit] Testcase: 
> keyedTimeBatchWindowTest(quarks.test.window.WindowTest):FAILED
> [junit] Values:[219, 200, 200, 200, 200, 200, 200, 200, 200, 200]
> [junit] junit.framework.AssertionFailedError: Values:[219, 200, 200, 200, 
> 200, 200, 200, 200, 200, 200]
> [junit]   at 
> quarks.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:422)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (EDGENT-219) new keyedTimeBatchWindowTest isn't robust?

[Dale LaBossiere (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240593#comment-16240593
 ] 

Dale LaBossiere edited comment on EDGENT-219 at 11/6/17 5:37 PM:
-

some rework of WindowsTest has occurred as part of PR-309 (switch to maven)


was (Author: dlaboss):
some rework of WindowsTest has occurred as part of PR-309

> new keyedTimeBatchWindowTest isn't robust?
> --
>
> Key: EDGENT-219
> URL: https://issues.apache.org/jira/browse/EDGENT-219
> Project: Edgent
>  Issue Type: Test
>  Components: Test
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> From a recent travis-ci run, the test failed.  Presumably just a test timing 
> sensitivity issue?  If so can it be desensitized?
> [junit] Running quarks.test.window.WindowTest
> [junit] Testsuite: quarks.test.window.WindowTest
> [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 
> 39.843 sec
> [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 
> 39.843 sec
> [junit] 
> [junit] Testcase: 
> keyedTimeBatchWindowTest(quarks.test.window.WindowTest):FAILED
> [junit] Values:[219, 200, 200, 200, 200, 200, 200, 200, 200, 200]
> [junit] junit.framework.AssertionFailedError: Values:[219, 200, 200, 200, 
> 200, 200, 200, 200, 200, 200]
> [junit]   at 
> quarks.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:422)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (EDGENT-219) new keyedTimeBatchWindowTest isn't robust?

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere reassigned EDGENT-219:
--

Assignee: Dale LaBossiere

> new keyedTimeBatchWindowTest isn't robust?
> --
>
> Key: EDGENT-219
> URL: https://issues.apache.org/jira/browse/EDGENT-219
> Project: Edgent
>  Issue Type: Test
>  Components: Test
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> From a recent travis-ci run, the test failed.  Presumably just a test timing 
> sensitivity issue?  If so can it be desensitized?
> [junit] Running quarks.test.window.WindowTest
> [junit] Testsuite: quarks.test.window.WindowTest
> [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 
> 39.843 sec
> [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 
> 39.843 sec
> [junit] 
> [junit] Testcase: 
> keyedTimeBatchWindowTest(quarks.test.window.WindowTest):FAILED
> [junit] Values:[219, 200, 200, 200, 200, 200, 200, 200, 200, 200]
> [junit] junit.framework.AssertionFailedError: Values:[219, 200, 200, 200, 
> 200, 200, 200, 200, 200, 200]
> [junit]   at 
> quarks.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:422)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (EDGENT-258) testMultiTopologyPollWithError failure; CME in TrackingScheduledExecutor.cancelAllAsyncTasks()

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere closed EDGENT-258.
--
Resolution: Duplicate

Duplicate of EDGENT-435

> testMultiTopologyPollWithError failure; CME in 
> TrackingScheduledExecutor.cancelAllAsyncTasks()
> --
>
> Key: EDGENT-258
> URL: https://issues.apache.org/jira/browse/EDGENT-258
> Project: Edgent
>  Issue Type: Bug
>  Components: Runtime, Test
>Reporter: Dale LaBossiere
>
> This happened in an (ant) travis-ci run.
> The DirectTStreamTest.testMultiTopologyPollWithError() test failed with a 
> CancellationException (end of the traces below).  Perhaps that was fallout 
> from a CME reported within TrackingScheduledExecutor.cancelAllAsyncTasks() on 
> the iteration of asyncTasks @ TrackingScheduledExecutor:121 which is the line:
> for (RunnableScheduledFuture task : asyncTasks) {
> (there's also an InterruptedException below)
> But I don't see how that CME can happen.  asyncTasks is a (private) 
> SynchronizedSet and all iteration on it in TrackingScheduledExecutor does the 
> required "synchronized(asyncTasks) { iterate... }" pattern.  The 
> SynchronizedSet methods all synchronize on the SynchronizedSet object 
> (asyncTasks) too so 
> an operation like add() or remove() can't occur during that synchronized 
> iteration. All access to the underlying set is via the SynchronizedSet.  So 
> how can that CME happen???
> The only possible non-CME-inducing flaw I see is in removeTrack() where 
> there's the non-synchronized sequential access:
> asyncTasks.remove();
> if (asyncTasks.isEmpty() ...   // hence may not reflect state following 
> preceeding remove()
> Note, there should normally only be 4 instances reporting "Expected Test 
> Exception" but there a 8 (maybe due to removeTrack()?).  Trust me, they're 
> all from this test method execution.  I've triple checked :-)
> I'm also confused a bit by the thread pool/thread ids reported on those 8 
> instances.  Would have expected them to all be associated with the test's 
> allocated fixed thread pool and would have expected that to have a single 
> pool with 4 thread.  But that doesn't seem to be the case?
> Here's the various msgs from the test's execution.  Maybe someone else can 
> figure it out.  From 
> https://travis-ci.org/apache/incubator-edgent/builds/164076026
> [junit] Sep 30, 2016 4:37:46 PM 
> org.apache.edgent.runtime.etiao.TrackingScheduledExecutor afterExecute
> [junit] SEVERE: Thread: 
> pool-5-thread-7-0a765e86-37c1-4299-9655-118420e3f1be: task terminated with 
> exception : 
> [junit] java.lang.RuntimeException: java.lang.RuntimeException: Expected 
> Test Exception
> [junit]   at 
> org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:83)
> [junit]   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [junit]   at 
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [junit]   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [junit]   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [junit]   at 
> org.apache.edgent.runtime.etiao.TrackingScheduledExecutor$TrackedFuture.run(TrackingScheduledExecutor.java:205)
> [junit]   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [junit]   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [junit]   at 
> org.apache.edgent.runtime.etiao.ThreadFactoryTracker$2.run(ThreadFactoryTracker.java:87)
> [junit]   at java.lang.Thread.run(Thread.java:745)
> [junit] Caused by: java.lang.RuntimeException: Expected Test Exception
> [junit]   at 
> org.apache.edgent.test.topology.TStreamTest.lambda$null$5f279479$1(TStreamTest.java:774)
> [junit]   at 
> org.apache.edgent.test.topology.TStreamTest$$Lambda$8/2070622949.accept(Unknown
>  Source)
> [junit]   at 
> org.apache.edgent.function.Functions$ThreadSafeConsumer.accept(Functions.java:204)
> [junit]   at 
> org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
> [junit]   at org.apache.edgent.oplet.core.FanOut.accept(FanOut.java:50)
> [junit]   at 
> org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
> [junit]   at org.apache.edgent.oplet.core.Source.submit(Source.java:47)
> [junit]   at 
> org.apache.edgent.oplet.functional.SupplierPeriodicSource.fetchTuples(SupplierPeriodicSource.java:52)
> [junit]   at 
> org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:81)
> [junit]   ... 9 more
> 

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Victor Dogaru]

+1
I think it's a good process.


On Mon, Nov 6, 2017 at 5:27 AM, Dale LaBossiere 
wrote:

> A BIG +1
>
> > On Nov 6, 2017, at 3:20 AM, Christofer Dutz 
> wrote:
> > ...
> > What do you think? Should we start the games?
>
>

Re: [DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Dale LaBossiere]

A BIG +1

> On Nov 6, 2017, at 3:20 AM, Christofer Dutz  wrote:
> ...
> What do you think? Should we start the games?

[DISCUSS] Release Apache Edgent 1.2.0 (incubating)

[Christofer Dutz]

Hi all,

after finally merging back all changes we did in the last few months, I think 
it would be a good time to do a first release using Maven. This way we can give 
the Maven build its final and ultimate test and hopefully start releasing a lot 
more often.

Even if I think the current development speed is still quite low, I would 
propose to start doing releases the following way:


  *   The intention to release is indicated by a “[DISCUSS]” Thread in which 
the intention for a new release is communicated
  *   After there is a general consensus on doing a new release a release 
branch is created and the version develop is incremented (In this case, I would 
create a “release/1.2” branch in which the version remains unchanged and the 
version of develop is incremented to “1.3.0-SNAPSHOT”
  *   As soon as this is done a “[LAST CALL]” Thread is started asking everyone 
to check the release branch, bring in last changes and fixes.
  *   As soon as the “[LAST CALL]” thread implies all are ready, a Release 
Candidate is created. We’ll be using the maven-release-plugin for that. This 
will create a so-called staging repository in Apache’s Nexus (This is like a 
maven repository, but it contains only the artifacts of the release candidate)
  *   As soon as the RC is staged, a “[VOTE]” Thread is started containing a 
link to the staging repository.
  *   As soon as the Vote passes, the staging repo is set to “release” and the 
artifacts automatically go to Apache’s public maven repo and get synced to 
Maven Central.
  *   Now the state of the release gets merged to “master” so now “master” 
represents the state of the last release done by the project.
  *   If there were any bugfixes, patches etc. applied to the release branch, 
these changes need to be merged to the develop branch too.

What do you think? Should we start the games?

Chris