How about using a repo with history?

[ams-tschoening]

You have created a repo for your fork of IKVM without preserving the history. When I had a look at IKVM, I collected as much parts of the project I could find and created individual repos here at GitHub:

https://github.com/ams-ts-ikvm-bag

Especially the source repo might be of interest, because I converted the original CVS one, preserving the history:

https://github.com/ams-ts-ikvm-bag/ikvm

As you seem to collect more bugs and PRs, how about changing your repo to a fork of mine?

It surely makes development easier in the long term to have access to old commits. At this point you didn't introduce too many changes yet, so porting things might still be pretty easy. I'm already cherry picking some of your changes and might pick those I wasn't sure if I want them as well. Ad least using additional branches, which you can then make master in your fork again and don't lose anything in the end.

[ams-tschoening]

I've created the branch wwrd_fork_integ, in which I cherry-picked most of your changes into the master of my fork. Only most, because your codebase is slightly older than mine and based on a release, so contains files slightly outdated, created during the build automatically and things like that. Your most important changes like version numbers, the fixes you applied regarding Optimized C2J.ConvertShape() and Fix arrayIndexScale are contained, though.

[ghost]

Once done you will post a pull request to merge this into the Windward branch - correct?

[ams-tschoening]

It doesn't work that way around, you would need to fork my repo and start using that instead of your own. The point is that your repo doesn't contain the history my repo has and that can not be (easily?) added afterwards anymore. But by forking my repo, you would get access to the created branch and could make that to your master simply by merging, so not too much work for you anymore (I hope).

So you need to decide if the history is worth migrating for you or not. I don't think it's that difficult, might take you very few hours I guess to clone, delete, test a bit...

Alternatively we could create another organization to maintain IKVM based on my repos and simply fork everything into those. We only need to know where to provide issues and PRs and I strongly suggest to keep the history if it's available already.

[ghost]

I think the most important thing is to have a single repo that all of using IKVM work from and add to. Having multiple repos just divides the efforts any of us are doing on this. And I'm fine if someone else wants to be the owner of IKVM going forward - we just did it because no one else did.

But for it to work for us, we need to add the two bug fixes we did to your repo. And we need a .NET Core IKVM in the near future so between you and us, we need to make it .NET Core compatible.

Are you good with this? And if you want to stay with our repo. the old history is not a concern to me. If we ever need that, then we can look at your repo. But it's very rare that history is needed.

thanks - dave

[mikeTWC1984]

What if wwrd fork @ams-tschoening repo under some other name like IKVM.Core and apply changes they need on top of it (if there is more stuff to add)

[mikeTWC1984]

Should we also put binaries on the release section?

[ams-tschoening]

Do you really think it's necessary to create an independent IKVM.Core? I don't, what I have in mind currently is creating an organization containing my fork of IKVM and the tests available, as people have asked for those already.

Within that one(!) fork we can start by maintaining different branches. master mostly stays at it is with wwrd-fixes applied, another net_core_compat contains what I have changed to make things usable in my UWP-app. The same way some net_standard_compat could easily be created.

The benefit of one repo is that everyone gets everything and can easily merge and cherry pick as one needs. The benefit of an organization is that we can have as many repos as we want, at least two already, and if really needed create an individual IKVM.Core in the future.

If nobody objects or provides a better name, I'm going to create the organization ikvm-revived for the beginning tomorrow and add the forks. All of you part of the discussion will get invites into that organization and permissions to manage things. Issues and PRs should afterwards only be put into that organization, wwrd might want to update their IKVM-blog entry as well to notice that new organization. Everyone with custom forks is than suggested to fork from that new organization instead.

This approach provides us the already available, most current repo-history (important for me), all the changes I already applied and one place to benefit from PRs of everyone. What people do in private branches is up to them anyway.

[mikeTWC1984]

Sounds like a plan!

[ams-tschoening]

The organisation exists now, I've invited you and the two repos of interest currently have been transferred:

https://github.com/ikvm-revived https://github.com/ikvm-revived/ikvm https://github.com/ikvm-revived/ikvm-junit

I've added some minor commits in my opinion of interest to all already to master, those include the two bug fixes applied by wwrd. Besides that, there's the branch wwrd_fork including their other changes to nuget, version numbering, copyright notices etc. Those changes could easily be merged to master, already tried that and didn't got any conflict and things built successfully.

The branch net_core_compat contains the changes I did to support UWP-apps only. In the branch vs_19_build I tested building things with VS 19 instead of ANT and removed warnings and stuff like that, but didn't care about compatibility with older .NETs. Not sure if this is of any interest to others.

@DavidThi808

You should consider moving the issues and PRs to the new organisation as well.

https://help.github.com/en/articles/transferring-an-issue-to-another-repository

Closing this for now, as I got what I was interested in. :-) Feel free to reopen as necessary.