You guessed right, we decided that we needed to start a fork and work on the whole renaming, and it happened to be the commit you mentioned.
For next week I planned to look at the diff that is already there, due to the longer time between the fork and now. I’m afraid that backporting is a time consuming task, and due to the package renaming, there is a big manual component to it. I would suggest that we create an issue in GH with multiple sub-items, identify what needs to be ported and break these down into its own task, so multiple people could be able to start working on this?
How about only taking a diff between releases, get changed files, rename paths and symbols and then create a manually reviews patch against Operaton master? Backporting every commit would be cool, but if there is any manual work required per commit, it would add up fast.
I just tried this with the “Remove telemetry” commit, and this worked surprisingly well. There were still some errors, for which it is a little late in the day to debug them now, but I was able to apply the patch without conflicts. There should be a way to semi-automate this, even
That’s very great to hear, I’ll open another thread for my thoughts regarding the roadmap then. The telemetry commit is complex, so I guess it will be doable for the smaller commmits as well
btw search and replace failed here. But this can be optimized using regular expressions.
Perhaps we should open another repo for tooling and create a script for this?
i don’t know it the deep link works and show the correct line, i was refering to the copyright statement
=> * Copyright Operaton Services GmbH and/or licensed to Operaton Services GmbH
Ah, now I see it Yes, the replacing is a little more nuanced, we need to make sure that we keep the licenses intact.
Applying the patch was a little tricky, as git am and git apply complain that I modified the patchfile by hand. In the end I applied it with IntelliJ, selected appropriate chunks by hand, and still some changes were missing and I had to spent ~ 10 minutes to correct them. I think the whole process took me 30 minutes, for a rather big commit with many changes (and refactoring on both sides), which is really not too bad
The script could use the “patch” cli tool apply the patch and then call git add/commit to create a new commit from it, if git rejects to apply it directy. It should then display if this could be done automatically or if this failed. If it fails you have to do it like you did manually with IntelliJ and manually resolve the issues
My idea is to review every commit and determine if it would be useful for the Operaton project. Since there’s not much activity in the C7 repository, this should be achievable with a moderate amount of effort.
That’s really nice, thank you, @Julian! It’s really less than I would have expected, and from the first glance, most of it seem to be dependency updates. I will take a closer look later this day
@javahippie Could you send me your Google account? I can then grant you write access to the table. When you review commits, you can add comments and update the status. For example, I’ve used the status “skip” if a commit isn’t relevant and “ported” if it’s already been ported. This way, we can prevent duplicate work.
Yes, the replacing is a little more nuanced, we need to make sure that we keep the licenses intact.
Next up, I’m working on adding a ‘rejection’ workflow to handle cases where manual fixes are needed.