[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] Getting Started
Hi Hank,
Sorry for the delay.
Le 24/10/2013 20:18, Hank Grabowski a écrit :
> Thank you for the reply, Luc. I have an account on the Forge (I'm
> HankG). I understand your workflow better now, so it looks like testing
> wouldn't necessarily be the best thing to do to help burn down issues.
> Would you rather I look at one of the older high priority "new" ones or
> the low priority elevation detector one?
Issue 144 is probably a good one to cut your teeth on contributing.
>
> When it comes time to start making pull requests and the like I will
> probably want to e-mail what steps I would take (assuming there is no
> step-by-step guide for that I can crib from).
Up to now, for issues that are not handled directly by developers, we
prefer patches sent as attachements to the issue in our forge. Of
course, there are other possibilities too like other public Git
repositories, so it really depends on what method you are more
conmfortable with.
>
> I agree that stages of the propagation can be parallelized to some
> extent, but the actual steps are going to essentially be in a sequential
> fashion. I suppose a variable step size integrator with
> predictor/corrector methods could sample each simultaneously, but if we
> are relying on Apache Math for the integrator it would be on that code
> to be parallelized.
>
> I suppose it would be possible to make the code thread safe but not make
> it parallelizeable, just in case someone accidentally adds cross-thread
> accesses by accident. Alternatively we could document in which methods
> are thread safe and which aren't in Javadoc.
It makes sense.
best regards,
Luc
>
> Thanks again,
> Hank
>
>
> On Thu, Oct 24, 2013 at 1:31 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr
> <mailto:luc.maisonobe@c-s.fr>> wrote:
>
> Hi Hank,
>
> Hank Grabowski <hank@applieddefense.com
> <mailto:hank@applieddefense.com>> a écrit :
>
>
> As I stated in a previous e-mail, I've been following and using
> Orekit in
> varying degrees for awhile now but just recently joined the
> development
> team to see how I could contribute back to the project.
>
>
> Thanks a lot for your interest in Orekit.
>
>
> I've read over the
> Orekit Governance document, all of the pages on the wiki with
> respect to
> coding philosophy, style, et cetera. According to the website,
> wiki and
> governance document it seems the next step would be for me to
> e-mail this
> mailing list to begin interacting with the development team to
> start taking
> on tasks. I have my own ideas for some things I'd like to see
> added to
> Orekit, however before I get to that point I often find it good
> to get my
> feet wet on a new code base by helping on existing targeted tasks.
>
>
> Exchanging ideas on this mailing list is a good start. Feel free to
> do it, as you have started with the thread safety about propagator.
> I see Evan also answered to this, so you see it is an interesting topic.
>
> When I said propagator will not be thread safe is because they are
> sequential by nature. However, I agree some part of the computation
> could be done in some cores and other parts in other cores. I also
> agree with Evan that some large data structure may be interesting to
> share between different propagators, so am ready to be convinced I
> am wrong and we should think more about this feature.
>
>
>
> I have been through the issue tracker on the orekit.org
> <http://orekit.org> site and see a few
> new issues that haven't been started yet. A couple of them seem
> like
> smaller issues that may be good to get started with.
>
>
> Sure. If you see low hanging fruits, you can grab them, they can be
> interesting to get used to our way to develop. If you don't have an
> account on the forge, set up one so you can attach files and patches
> to the issue tracker.
>
>
> I see many resolved
> issues that look like they have been successfully submitted. I
> do not know
> your issue workflow, but in traditional work flows I'm
> experienced with
> independent verification is necessary to move an issue from
> "resolved" to
> "closed".
>
>
> We usually wait until the official release of the version wehre the
> fix is included before closing the issue.
>
>
> I'd be happy to help burn down those issues by starting the
> process of validating their completeness. Since this would be
> my first
> contribution I'd be happy to coordinate either effort with one
> of the
> primary developers (based on my reading of the repository stats
> that would
> be either Luc Maisonobe, Pascal Parraud or Fabien Maussion).
>
>
> Fabien Maussion have left the project some years ago, after his
> internship ended. The other current developers are Evan Ward and
> Thomas Neidhart.
>
>
>
> Thanks for all of your efforts to date. I look forward to
> contributing.
>
>
> Thanks again for you proposal, we are happy to have new contributors.
>
> best regards,
> Luc
>
>
> Thanks,
>
> Hank
>
>
>
>
> ------------------------------__------------------------------__----
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
>
>
> --
> Hank Grabowski
> Chief Technology Officer
>
> 10440 Little Patuxent Parkway, Suite 600
>
> Columbia, MD 21044____
>
> (410) 715-0005 Office____
>
> (410) 715-0008 Fax____
>
> (301) 525-6219 Mobile____
>
> hank@applieddefense.com <mailto:hank@applieddefense.com>____
>
> www.AppliedDefense.com <http://www.applieddefense.com/>
>