knro: yeah, submodules are the way, but remember: you're not allowed to clone 3rdparty/indi-eqmod, unless it's a standalone git repository.
You have to clone all 3rdparty each time.
As I said, probably the cleanest way to do it is to have three projects: core, 3rdparty, and cmake_modules

That is exactly how it works (I mean submodules got planted in proper places during clone).
My suggestion is as folows:
- You make a big announcement about migration and ask people (active developers) to get an account on github and fill in missing data authors.txt posted at project repo (thanks BTW for filling in some data there).
- I will try to make a test import of just trunk. We check if all is properly imported and if all users are properly mapped
- We collect/correct missing author info
- We make a final import and switch the svn to RO
I can make a commitment to do the imports etc at 27-29 May. How is that working for you Jasem?
Regarding the structure. I was thinking about splitting the project into three parts: core library and drivers, cmake, third party drivers, maybe packaging
Maybe the core could be further split into library and server&core_drivers - but I am not so sure there is any point doing this.
Alternatively we can use even finer grain splitting - like you have used on launchpad but this will make it more difficult for new developers to start their own drivers. It is easy to clone a repo add your driver and send a pull request. There is no similar mechanism (I know of) to propose to include your own repo into a organizational project like libindi is.

What do you think?

Great, I'll get to it and ask the current developers to register github accounts if not done already. It seems the organizational structure is similar to what we have:

1. cmake
2. libindi
3. 3rdparty
4. packaging
5. macosx? I'll ask Peter, maybe we can keep this in subversion

No need to further split libindi. 27-29 is perfect, hopefully we can get most of the developer's info by then.

Ok. I like this scheme. Remember to ask them to fill in the data for authors.txt

All Authors!
I have done a test import of indilib from svn.

github.com/indilib/test-import

Please do not use it for anything except testing what worked and what did not.
Please report any issues. Particularly check if your contributions are properly mapped to your github accounts.
If not either report it to me or correct authors.txt file posted in (github.com/indilib/experimental-import)
Please do it now - we will not be able to correct it after final import.

This structure makes things much easier and transparent. We will avoid cases of desynced cmake_modules which are now hard copied to new drivers and need to be manually resynced in case of major changes to indilib.

I had never done the 'pull request' thing with github before, only took a few minutes to figure it out, and get my names updated in authors.txt

But this does beg a question for me. With the migration to github, does this mean for submissions we work in our own fork, then do the pull request to merge into the main tree, or will we be working directly from the main tree as we did with svn ?

There is an elegance (and additional work for somebody to babysit merges) of doing things outside the main tree then pull in, but, there is a simplicity of working directly in the main tree. I'm not sure which model is more prevalent for github hosted projects.

I guess the use of branches is the way to go for any project. It'll never mess up the main and Jasem or other authorized admins can merge it with main if it checks out ok. Sure, that is more work, but I'd guess figuring out bugs in the main is even more of a pain.

The branching and pull requests seems to be a prevalent mode of working in git-managed projects.
We *can* work the same way we did in svn but then why migrate?
The down side is an additional workload on core developers who become stewards of the master tree.
The up side is a much lower barrier for new developers - anyone can clone the repo and work on something
with full benefits of version control but without fear of braking something for others. And if/when they eventually
make something presentable they just create a pull request. For experienced developers this is an additional
barrier for laziness and carelessness - you need to explain your changes to fellow developers - that is always good.
Another down side is slower incorporation of new edits into the repo.

I think everyone new to git should read some text on git workflow.
I personally recommend nvie.com/posts/a-successful-git-branching-model/
It is working well in few projects I am involved with.

In my opinion - this is the right time to rethink project structure and workflow.
Ultimately it is core developers decision. They will need to cope with additional workload (which is not going to be large I believe).
I think the group of stewards/core developers should be small but larger then one - for obvious reasons. On the other hand one
needs to remember that every git clone is a complete project repo so the central position of the github repository serves only
as a convenient synchronization point and base for releases - so the write access to the repo is much less critical then with SVN.

I agree. We've been using git in KDE for the last couple of years and it's been great. We don't have direct pull requests, instead we we use reviewboard.kde.org to check patches before they're accepted into whatever branch they're designated for. Anyone can clone the repo and work in it and submit pull requests whenever necessary.

Github has some code review support - you can discuss over pull requests and submit further patches. Gitlab has more powerful code review facilities and integrated CI testing. On github we can select from a number of CI services to use (I have started config for TravisCI - not ready yet, will continue on it after transition).

Preparations status:
We have a properly transferred repo and some developers are in authors.txt file.
But there are still 10 developers data missing from the file. Please supply your data
before final migration (May 27-28). Otherwise your contributions will be transferred under
your sourceforge user name and we will be unable to correct it later.