jitsi / jitsi-xmpp-extensions

Common library holding all jitsi specific smack xmpp extensions.
Apache License 2.0
15 stars 51 forks source link

Initial code import #1

Closed damencho closed 5 years ago

damencho commented 5 years ago

Initial import of all extension and fixing extensions to use XmlStringBuilder.

bbaldino commented 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.

damencho commented 5 years ago

@bbaldino I have done that but in separate commits. If you two agree I can separate it in two PRs.

paweldomas commented 5 years ago

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 ?

bbaldino commented 5 years ago

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?)

damencho commented 5 years ago

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.

bbaldino commented 5 years ago

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)

paweldomas commented 5 years ago

Okay LGTM, now you have to check with @bbaldino about the first commit as it seems there's no agreement

damencho commented 5 years ago

I see two options:

bbaldino commented 5 years ago

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.