Partial surface-ellipses

[wcmatthysen]

Changed the SurfaceEllipse class to maintain an additional parameter
called "theta". This parameter is responsible for the angle between the
first and last interval of the ellipse and allows for partial ellipses
to be drawn. The default value of theta is 360-degrees, meaning that a
full ellipse will be drawn when constructing an ellipse as usual.

[wcmatthysen]

I'm seeing some strange build errors on travis:

The command "openssl aes-256-cbc -K $encrypted_1799be77f389_key -iv $encrypted_1799be77f389_iv -in keystore.tar.enc -out keystore.tar -d" failed and exited with 1 during .

[pdavidc]

We've added automatic Jar signing to the travis build, which requires decrypting the signing certificate. Builds for pull requests don't have the decryption environment variables, a travis design choice for security. We'll find a way to make this benign.

It's also worth noting that NASA World Wind is an open source project, but is closed development. Our NASA administrator can provide more insight into this if you'd like. We accept pull requests sparingly.

[wcmatthysen]

"We accept pull requests sparingly."

I don't fully understand this. Are you telling me that I should stop with the pull-requests? Or should I tone down with the number of pull-requests?

The reason I'm asking is that I have a lot of fixes / improvements outstanding from my old WorldWind fork that I would like to contribute back to WorldWind. I would love to help improve WorldWind as I have greatly benefited from using WorldWind in some of my projects. If you are telling me I'm wasting my time with these pull-requests then I will stop.

[basisbit]

as this is an open source project, maybe a good solution would be to still have these improvements as pull requests, then close them if the nasa team doesn't like/want/... them but label them with something like "optional improvement"? Would something like that be possible, @pdavidc ? Then at least others would be able to use these additions and work would not be lost. (or maybe a fork as official community version?)

[basisbit]

before the switch to github was done, one would have posted these java classes in the goworldwind forum. You already can find lots of code in there, but also lots of abandoned, not any more working code or have to dig through lots of pages of comments.

[wcmatthysen]

@basisbit The community fork sounds like a good idea. However, I think a lot more people need to get on-board to make it a success. The other forks pretty much died out after they were started.

[basisbit]

it would have to be "the" community fork, having nww java as upstream project. Otherwise it would not be worth the work

[wcmatthysen]

Agreed. I think this needs to be a point of discussion on the forums. I created a topic for discussion.

[pdavidc]

@wcmatthysen and @basisbit, the NASA team very much appreciates your contributions and your insight into potential mechanisms for handling community contributions. One of the benefits of World Wind's is the flexibility you have to extend and modify it, and we want to embrace that as much as possible while keeping what's in the core SDK manageable for the NASA team to maintain. We also want to do a better job of establishing expectations on what kinds of pull requests are feasible for the NASA team to merge into the core SDK and maintain.

Here's what the NASA team plans to put in place over the next few weeks:

• Contribution guidelines that set expectations for how the NASA team will handle pull requests.
• Pull request labels that indicate contributions that have value, but that are not feasible for the NASA team to merge into the core SDK. This is essentially @basisbit's recommendation. We're also considering establishing a section somewhere on https://worldwind.arc.nasa.gov that lists these contributions and links to GitHub.
• Travis CI scripts that build pull requests correctly.

[wcmatthysen]

@pdavidc Thanks, I think the guidelines will be a step in the right direction. However, I think there is a problem with the pull-request idea that we have to deal with if we want to make it work in the long run. The problem is that the pull requests themselves might become stale over time if they are not rebased on the master branch. This effectively becomes the same issue as all of the stale code that is lying around the WorldWind forums that do not work with the latest version of WorldWind anymore. A community fork will work better in this situation as it will become the fork-owner's responsibility to merge with upstream. This will keep the pull-requests (that have been merged into the fork's master branch) up-to-date as any conflicts with upstream's master-branch will be resolved continuously.

[pdavidc]

@wcmatthysen I agree with your point about stale pull requests. The community fork is indeed a better alternative for pull requests that won't be merged into the NASA repository, provided that it's centralized as you and @basisbit have proposed.

Given that, it seems best that the NASA team define a set of pull request labels that indicate whether the request is pending review, accepted and pending merge into the NASA repository, or should be directed to a community contributions fork. We can outline all of this in the contribution guidelines. Let me know if you have any thoughts on this.

[wcmatthysen]

Ok. I think the pull request labels will work nicely. Like you said: a pull request could be flagged as community-pending where it could be picked up by the community fork owners to merge into the community fork's main branch. I think the community needs to manage this fork. However, we probably need some ideas on how this fork will be managed. Will it be a separate github group with its own set of projects that are forks of the current projects?

[basisbit]

maybe having an official (as defined by nasa wwj team) "external" fork (another github project, partially with nasa people as administrators and partially with external people) here on github would make it independent enough while at the same time lowering the amount of work for all of us and still allow a bazaar alike software development process. New ideas and rather big changes could be implemented and tested in the community fork, while still having the api continuity and stability in the main project. (just throwing in some ideas)
I saw that there are a bunch of small but now abandoned forks here on GitHub already - most likely such a community version won't be successful and an enhancement for all if it is not "advertised" as the main community fork.

[basisbit]

Will it be a separate github group with its own set of projects that are forks of the current projects?

No need to reinvent the wheel. There are various guidelines out there and also you can look at how other projects handle this. Open communication, good + public documentation of discussions and so on are key to the success of such a project. GitHub provides a really good ecosystem for this thanks to git, the issue tracker, about everything here is publicly visible (except for entirely closed projects), forking, branching, and merging between different forks is even supported.
Additionally, lots of things are already defined in the license of the project anyways.

[wcmatthysen]

@basisbit Sounds good. I like the ideas that you mentioned.