Closed damencho closed 5 years ago
I think for the initial import we should make as few changes to all this as possible (to have something as close as possible to the original code/repo as a baseline) and then follow up with improvements/changes.
@bbaldino I have done that but in separate commits. If you two agree I can separate it in two PRs.
I think it's okay to merge it without squashing. Eventually squash/rebase and force push the fixes from the follow up commits into the Update extension implementation to use XmlStringBuilder.
@bbaldino WDYT ?
If you're saying the very first commit of this compiles and works fine with everything, then yeah i think it's ok to do and just not squash. It can just be tricky if you find a compile error later and it gets buried amongst the other commits it can be confusing (so just squash any base fixes into the very first commit I guess?)
So the first commit just moves the files with few modifications, so we do not depend on libjitsi and some jitsi stuff but can compile and use it. This is how I did it and tested it with jicofo. Then after adding and the fixes I was testing with jigasi and jvb.
ok...i think i'm saying it'd be good to have a set of changes that was nothing but what was necessary to move this code to a new repo. then after that is done we could do the improvements and other fixes (to bugs that existed in the original code)
Okay LGTM, now you have to check with @bbaldino about the first commit as it seems there's no agreement
I see two options:
if all the commits related to moving the code/making it work are before the "improvement" commits, then that's fine with me. i just wanted to make sure we had a hash we could check out that will be as close as possible to the original code, just in this new repo is all.
Initial import of all extension and fixing extensions to use XmlStringBuilder.