Oolite on GitHub?

[Gimi]

After Jens posted a link to the "new" Oolite Issue tracker on GitHub I had a look around to see what was there, and it seems to me that the Oolite project has, or is in the process of being moved from Berlios to GitHub.

I also tested to see if I could compile Oolite for windows using the Simplified development environment provided by AC and the source pulled from GitHub, and that worked without a hitch. (I'm using the GitHub client for Windows to pull the source).

I have a couple of questions though. (I'm a complete amateur at this, so please excuse stupid questions)

• GitHub shows latest commit as a hex value. Would this be the revision number to be used if I report issues?
• When compiling I pointed the compiler directly at the source as downloaded from GitHub, and just wrote "make debug=no". This will probably make most programmers cringe, as my GitHub client now reports 423 files to be committed (I don't have write access, so it won't happen). Is there a simple way to redirect the compiled files (leaving me with a working version of Oolite) to another directory using the simplified development environment as provided by AC.
• When will updating of the Berlios source cease (if that is the plan).

[JensAyton]

Answers will be forthcoming when they’re ready.

[Gimi]

Answers will be forthcoming when they’re ready.

Fair enough, thanks.

[Zireael]

Also, is the BerliOS or GitHub the place for bug tracker now?

[cim]

Github.

[JensAyton]

Answers will be forthcoming when they’re ready.

We should probably get on that one of these months.

[cim]

Answers will be forthcoming when they’re ready.

We should probably get on that one of these months.

Oops.

GitHub shows latest commit as a hex value. Would this be the revision number to be used if I report issues?

Yes, if building from source. The nightly builds have an official build watermark, which includes the hex commit and the build date.

When compiling I pointed the compiler directly at the source as downloaded from GitHub, and just wrote "make debug=no". This will probably make most programmers cringe, as my GitHub client now reports 423 files to be committed (I don't have write access, so it won't happen). Is there a simple way to redirect the compiled files (leaving me with a working version of Oolite) to another directory using the simplified development environment as provided by AC.

No, but we did update the .gitignore file to ignore those build files, so this should be okay now.

When will updating of the Berlios source cease (if that is the plan).

After the release of 1.77.1 (which has now happened)

[Gimi]

Thank you for the answers. Kind of taken over by events , but good information.
I see that people are still using Berlios for reporting bugs and more. Is it possible to leave a message/sign/notice that points people towards GitHub?

[JensAyton]

The bug tracker was left on to give people time to answer questions about old bugs that I didn’t think were relevant any longer. I’ve closed those, and will migrate the new bug reports soon; after that, the BerliOS bug tracker will be removed. I’ve turned off the feature tracker and task manager, which didn’t have anything newer than 2008.

[Zireael]

If I have a Github account, can I make some suggestions under Issues?

There's a grand total of three, and all three were made on this forum.

[cim]

You can, though if they've already been made here then there's perhaps not much benefit to doing so.

[Zireael]

You can, though if they've already been made here then there's perhaps not much benefit to doing so.

The suggestion I'd love to see first and foremost is detailed in the Expansion Pack forum, linky.

As you see, it involves digging into the source and:
1) I don't think Pleb has a github account
2) I can't compile

[cim]

I think the right way of going about that one is probably to start by not randomly generating the systems in the first place. If we want system 0:7 to be Lave at particular coordinates with particular properties, we can just put those properties into planetinfo.plist. Considerably more efficient - with modern hardware - than repeatedly regenerating them, and would also have the advantage that (e.g) system.info.corona_flare would be readable for the baseline value even if you hadn't set it per-system.

[Zireael]

I think the right way of going about that one is probably to start by not randomly generating the systems in the first place. If we want system 0:7 to be Lave at particular coordinates with particular properties, we can just put those properties into planetinfo.plist. Considerably more efficient - with modern hardware - than repeatedly regenerating them, and would also have the advantage that (e.g) system.info.corona_flare would be readable for the baseline value even if you hadn't set it per-system.

This is a good point.

The only reason for keeping random generation would be enabling different seeds as an option, but I seem to recall a comment by one of the devs that it won't happen.

[Zireael]

I hoped to be able to contribute, but the repo is so slow to clone, even 2h weren't enough...