Many of you wanted to see OregonCore on Git & GitHub.

So, it's time to move!

So what we plan to do is to have two repositories synced for some time (december) to move smoothly. They are extensions for both mercurial and git to push/pull from the other repo so the sync won't be a problem at all.

The problem seems to be with name. Both 'oregon' and 'OregonCore' were already taken but have no activity, that means we may catch one of them because of GitHub's Squatting Policy:

GitHub account names are provided on a first-come, first-served basis, and are intended for immediate and active use. Account names may not be inactively held for future use. GitHub account name squatting is prohibited. Inactive accounts may be renamed or removed by GitHub staff at their discretion. Keep in mind that not all activity on GitHub is publicly visible. Staff will not remove or rename any active account.

Attempts to sell, buy, or solicit other forms of payment in exchange for account names are prohibited and may result in permanent account suspension.

It's also possible that some of you have already been impatient and has taken/reserved the name.

"A little hard-work never killed anyone important." - Abe

oregon my opinion. The easier to write in git bash the better tongue

voted for the oregoncore simply because

1) Selphius voted for the oregon one, and i like to see him having trouble with git bash with longer words.
2) its a core..
3) i can vote for 2.


but frankly... im fine with everything thats going to be it.

dikkedeur wrote:

voted for the oregoncore simply because

1) Selphius voted for the oregon one, and i like to see him having trouble with git bash with longer words.
2) its a core..
3) i can vote for 2.


but frankly... im fine with everything thats going to be it.

Haha, good one big_smile. Either way the name simply doesn't matter, whatever will be, will be. I will act accordingly to it, but OregonCore does sound better and is more apprioprate to assimilate core with I think. Well whatever.

Nice step forward, i personaly liked HG in the past, but i love git as well, and GitHub has a lot more of features in any way then bitbucket, so lets move on...

i voted for OregonCore cause the official Project name is OregonCore, the domain is oregon-core and i would like to have things named in a consisten way wink but how ever, its fine how ever you decide

Edit: if you keep open both repos, please think about to close one of both issue tracker (i suggest closing the bitbucket) to provent missing issues or redundant discussions on both systems

Both current issue trackers will be closed in favor for githubs amazing bugtracker

OK, frankly I found out that the one who registered the name OregonCore was usagi so we'll have that one smile

Although I said the repos will be in sync it's not that true. It's time to clean up the repository and reconsider the whole structure and build progress.

  • We will need to remove the oregon_database.zip from repo and put it somewhere in download section probably directly at github, that way we can provide more updated DB packs without size overhead in the repo. The updates will still go to the main repo.

  • Next thing is - dependencies i.e. /dep directory. We use it to distribute dependencies required by oregon-core to ease the life with building process. But it certainly needs a change because they rebuilds every time cmake configuration changes (most cases are production/debug build switch); assuming that you have not two separate build directories. What we could do about this:

    • make the build of dependencies a separate process that wouldn't compile them with core, but only at the very first install or when an update is released

    • we could also demand everyone to install all dependencies - this is not flexible mainly on windows because its a long and boring process and updates would be even more unpleasant

    • or we can precompile those dependencies and link against prepared libraries. The disadvantage is that a dependency would have to be precompiled for each platform and architecture separately. Not prebuilt ones would have to compile it on their own; and also is there the trust that the .so/.dlls are safe to use?

    • or is there any other option?

"A little hard-work never killed anyone important." - Abe

+1 for refactor dependency build process.

i think demand to install would be problematic, and precomplile for all platforms is a huge amount of work for the team, and i don't think it will make sense.

if there is a simple way to separate the build process then it would be great, if not i have a little different solution.
the most time consuming dependency to compile is ACE, for sure. as far as i know the most non windows systems are installing ACE already by package manager (correct me if im wrong) if we provide 4 precompiled libs for windows (debug / release /x86 / x64) it would help a lot.
the other dep stuff is compiling fast or i remember wrong?

but for sure, its a "hacky" solution, separating the build process would be more elegant.

for the database.zip i agree, maybe we do like trinity, releasing each 6 months (or 1 year) a new full release as zip in downloads, and provide updates in repo

Nice, can you think of any implementation for the separated build process? Take updates into the mind.

"A little hard-work never killed anyone important." - Abe