Open cobratbq opened 4 years ago
One of our developers made https://github.com/redsolution/otr4j when he found that it was hosted on Google Code, and it happened to be the first one on github, so all other repos are branched from it. I'm not currently ready to comment on which fork is the most dominant, but we don't do any work on our repository at the moment. So if anyone has suggestions on what to do to remove unnecessary confusion, we'll be receptive to it.
@andrewnenakhov: Thanks for your comment, we want to recover the redsolution/otr4j to be the future otr4j/otr4j, can you transfer like I have requested you?
Thanks in advance.
@Neustradamus ok we'll transfer it to you in a few moments.
I can't transfer https://github.com/redsolution/otr4j to https://github.com/otr4j/otr4j:
I've granted admin role on https://github.com/redsolution/otr4j to @Neustradamus.
@a-iv: Thanks, I have done the transfer! @cobratbq: Do you have all rights on the otr4j/otr4j?
As the original otr4j author I am disappointed and confused about the need to create a separate organisation for otr4j :( All of the jitsi projects are Apache 2.0 licensed and that has never been an issue so I don't understand why we can't foster collaboration and future work under the jitsi org, where the project initially started?
@gpolitis: the otr4j organization exists since several years! Now redsolution/otr4j (not updated since a lot of years) is now otr4j/otr4j, all changes from previous otr4j/otr4j (currently in otr4j-temp, it is not possible to have a fork with the main project in the same organization) will be integrated in the historical GitHub repository :)
The question is about jitsi/otr4j changes, what we do? It is possible to give rights to @cobratbq and me? I have already contacted @emcho.
The current jitsi/otr4j is not updated since a very long time.
About otr4j organization, you can see for example about @cobratbq commits:
A lot of, the beginning is here:
@gpolitis: Read here, confirmation: https://stackoverflow.com/questions/7161301/which-java-otr-library-should-i-choose/11692461#11692461.
Hey @cobratbq nice to meet again!
AFAICT @cobratbq has the commit bit on the Jitsi repos, so that's not a problem. And we can add more people if need be.
The current state after repo transfers is that https://github.com/otr4j-temp/otr4j is the mosst advancedd one, this one is second and https://github.com/otr4j/otr4j has a last commit of 2014.
I don't have a horse in this race, but I've always believed that repos belong to those who work on them. But also, moving things around for the sake of doing it is just needless churn.
So, since @cobratbq has put in a lot more work on it in the recent past (I still remember us talking about it at FOSDEM a couple of years ago), I'd ask: Danny, where do you feel more comfortable continuing your effort?
If this repo is that place we'll ask GH to "unfork" the repo, this is possible to do.
@saghul: otr4j/otr4j was the old redsolution/otr4j and otr4j-temp/otr4j was the old otr4j/otr4j. It is planned to integrate all from otr4j-temp to otr4j and remove the temp. The question was about jitsi/otr4j which is no longer maintained...
It doesn't matter what "was" it matters what "is".
The question was about jitsi/otr4j which is no longer maintained...
My understanding from a talk I had with @cobratbq back in the day (he can confirm if my recount is accurate) was that he was working on a separate fork with the intention of merging back once ready. The reason to do it that way was because it was very heavy rewrite. Looks like things might have fallen through the cracks though.
jitsi/otr4j is a Jitsi project that started in GSoC 2009 and it follows the Jitsi coding process:
You can you open a PR in jitsi/otr4j and let it go through the normal review process. Everybody's welcome to comment on your changes and this is how we foster collaboration.
The PR author needs to sign our CLA, which is what all of our contributors across all other Jitsi projects have been doing for several years. You don't need commit rights to open a PR but we're happy to grant commit access to people that have worked their way to be voted as a Jitsi developer. @cobratbq has achieved that milestone with his work on Jitsi desktop.
If you don't agree with our license, or if you don't feel confortable signing a CLA, then you're free to fork the project but it doesn't constitue a reason why we would want to change anything on our end.
I would be delighted to review a PR from you guys. It would help clear up the situation and your hard work would be incorporated in otr4j intended home.
Sorry for long response, but I have to catch up on the conversation.
@Neustradamus
Do you have all rights on the otr4j/otr4j?
Yes, that seems to be in order.
@gpolitis
As the original otr4j author I am disappointed and confused about the need to create a separate organisation for otr4j :( All of the jitsi projects are Apache 2.0 licensed and that has never been an issue so I don't understand why we can't foster collaboration and future work under the jitsi org, where the project initially started?
I share your sentiment on this. I was originally sceptical and I don't regret working under the original license. But @saghul recalls this correctly and I am very happy he does so, there was never the intention to interfere. Eighthave (not mentioning on purpose) originally started the initiative to unify and it didn't work out. At the time I had already started my efforts there.
I am impartial as to where otr4j lives. I do think there is value in unifying all forks with relevance.
@Neustradamus simply counting commits distracts from the real goal and shouldn't be a qualitative metric. To be clear, my work of the past years is mostly meaningless if OTRv4 is not released. The restructuring still benefits OTRv2 and OTRv3, but only after significant clean up of dead OTRv4-code. Someone who just wants OTRv3 to work, can just as easily adopt existing otr4j libraries. And even if the redesign has significant improvements, they are as of yet unproven and not tested in the real world.
(The stackoverflow post proves that unifying would clear up confusion.)
@saghul I left the 'jitsi' github team a year or so ago, due to problems/harassment on a personal level .. I can't even explain. So, someone would need to add me again. (Sorry :-P)
@saghul
My understanding from a talk I had with @cobratbq back in the day (he can confirm if my recount is accurate) was that he was working on a separate fork with the intention of merging back once ready. The reason to do it that way was because it was very heavy rewrite. Looks like things might have fallen through the cracks though.
That is correct. And I bet you wouldn't recognize the code anymore. :-)
Danny, where do you feel more comfortable continuing your effort?
I don't have a clear preference. I think most important is that we unify the various repos. I think there is something to say for using the otr4j github organization, but if we "use" it to redirect to "jitsi/otr4j" then we tackle that problem. Ideally, there is one repo with a code base everyone can rely on.
There are a few possibilities:
It is important that we can agree on the solution together. I won't always be able to maintain the fork by myself. And I do not like that the confusion develops into a "competition of otr4j forks".
I am not sure if the CLA is a problem. I signed it a while back already. And whatever you will say of the CLA, you can always clone the repo up until today and have that backup "in case it disappears" or whatever your favorite risk is. Apache 2.0 license is liberal enough, so no risk there AFAICT.
Incidentally, has anyone checked whas is really different between jitsi/otr4j and (originally) redsolution/otr4j? It would be helpful if we can at least unify those two already.
There are a few possibilities:
I agree with @cobratbq fwiw. I would love to clear up the confusion, so option 3 is not ideal. Merging in master without a review sounds like a bad and unnecessary idea, we can merge once the code is stable, so option 1 isn't great either. Option 2 sounds indeed like a very reasonable approach.
@cobratbq: otr4j/otr4j@master...jitsi:master
This is tricky. I checked the merge locally, but most files have moved in jitsi
repo due to restructuring effort for maven. Now it shows many files as separately added
/deleted
instead of the combined rename
(which can also be a move
).
So either we assume jitsi/otr4j
is strictly better and do the shallow merge and accept jitsi/otr4j
's files, or we do a thorough merge, i.e. take into account the renames, and we have more files to check for merge conflicts and semantically relevant changes.
The merge is prepared at https://github.com/otr4j/otr4j/pull/3.
Effectively it is almost identical to jitsi/otr4j
given that almost all improvements happened at that repository. Now, due to the merge, this code-base is different, so transferring this to jitsi
is probably not easy.
Any ideas? (github does not allow having 2 repositories with same root in an account, so simply transferring under different name is not feasible.)
So... i missed this thread. Whatever you do, please have something in any org/repo that is published to Maven, has an updated (or removed, see #32) BouncyCastle and that I can update in Jitsi (i.e. has OSGi metadata). Publishing to Maven Central is possible with GitHub actions in this repo and Key/User from Jitsi, see the Action in #34.
@cobratbq what's the state of this? Personally, I'd prefer to have otr4j here as it's always been affiliated with Jitsi. If necessary, I think we can rename this repo to e.g. otr4j_archive, make it readonly and move otr4j/otr4j back here.
@ibauersachs basically the merge is completed. It's uploaded in a different branch. I've been upgrading some plug-ins and IIRC maven-javadoc-plugin fails due to mixed modules with unnamed module. Some thing that should be fairly easy to fix.
As for moving the repo, github will refuse as long as jitsi/otr4j and otr4j/otr4j have the fork-relationship. You can have only one repo for each fork-root or something. (Maybe there is an exception when archived/private???)
If you guys could verify you're happy with the merge, then you can move. I don't currently have organization/repo permissions on github.com/jitsi so I cannot do anything myself.
Also note that if you move the repo in github.com/otr4j/otr4j, then you have the original one (previously github.com/redsolution) so jitsi/otr4j will become the root of the otr4j fork-tree.
What's with the license situation? Are there any contributions in the other repo besides from yourself? Has everyone agreed to relicense their contributions to Apache 2?
@ibauersachs: Do not forget that jitsi/otr4j had not been maintained since several years (more 4 years).
It is not possible to move jitsi/otr4j in otr4j organization but all will be merged soon (otr4j-temp in otr4j), @cobratbq is on the progress, after we will have a best otr4j :)
But the current state is:
/*
* otr4j, the open source java otr library.
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*
* SPDX-License-Identifier: LGPL-3.0-only
*/
/**
What's with the license situation? Are there any contributions in the other repo besides from yourself? Has everyone agreed to relicense their contributions to Apache 2?
I have first focused on the differences between jitsi/otr4j
and otr4j/otr4j
(previously redsolution/otr4j
): the incoming differences are minimal. Licensing changes should only be aligned with @a-iv, according to the diff. NOTE: this excludes the work-in-progress effort for OTRv4.
That would unify jitsi/otr4j
with redsolution/otr4j
, which also means that we have an up-to-date fork-root.
Okay. I've renamed this repo to otr4j_fork. If you want me to move otr4j/otr4j into Jitsi, you'll need to make me an admin there.
Oh, and what's with the custom branch? There are a lot more changes than the diff you linked above.
@ibauersachs: It is not possible to move fork into the same place of the base :/
It is for this that currently there are:
After all complete steps, only one will be here.
And https://github.com/jitsi/otr4j_fork can be removed or archived.
@cobratbq: Like @ibauersachs has seen, what do you think about 4 commits here: https://github.com/otr4j/otr4j/commits/custom?
Oh, and what's with the custom branch? There are a lot more changes than the diff you linked above.
I wasn't aware of this one. Comparing the two seems to show that only a single piece of functionality was added: support for transforming messages when one is off-line or at least when otr4j should not automatically respond to whitespace-/query-tags.
I think we should also consider whether or not otr4j should even be invoked in that case. I'd rather pick this up as a feature-request and handle it appropriately. We should even consider that client should disable otr4j through policy.
Okay then. Any objections to move otr4j/otr4j into jitsi/ and merging your open PR? The custom branch can be kept open as a separate PR.
@ibauersachs before we do, I don't think we can "just delete" the other repo. There are issues and releases that you might want to preserve. Have you considered that? Anything else we need to take into account?
@ibauersachs also, Github has the following complaints :-)
jitsi already has a repository in the otr4j/otr4j network and You don’t have the permission to create public repositories on jitsi
I'm not going to delete any repo. The we're discussing this issue in is now named otr4j_fork to avoid a name clash. I would archive it after otr4j/ is moved to jitsi/. Any open issues could be transferred before archiving if necessary.
I can't grant you admin permissions on jitsi/ without Emils consent. So either you grant me or George admin on otr4j or we'll have to ask Emil.
Not sure why GitHub is annoyed, but if it still doesn't work with an admin account in both orgs, we can ask their support.
I can't grant you admin permissions on jitsi/ without Emils consent. So either you grant me or George admin on otr4j or we'll have to ask Emil.
You've got an invite for the otr4j
organization.
Not sure why GitHub is annoyed, but if it still doesn't work with an admin account in both orgs, we can ask their support.
This is because github keeps a directed graph of forks from some original repository, in this case otr4j/otr4j
(renamed from redsolution/otr4j
). The nasty thing is, that we can simply break the link, but that breaks the link for a lot of forked otr4j repos.
I can't grant you admin permissions on jitsi/ without Emils consent. So either you grant me or George admin on otr4j or we'll have to ask Emil.
You've got an invite for the
otr4j
organization.
Accepted, thanks.
Not sure why GitHub is annoyed, but if it still doesn't work with an admin account in both orgs, we can ask their support.
This is because github keeps a directed graph of forks from some original repository, in this case
otr4j/otr4j
(renamed fromredsolution/otr4j
). The nasty thing is, that we can simply break the link, but that breaks the link for a lot of forked otr4j repos.
I get that, but there's really no reason to not have a fork of a repo inside the same org.
I get that, but there's really no reason to not have a fork of a repo inside the same org.
Of course, you're right.
So as almost expected, the fork error stays. Options are:
What's your preference?
I'll need to think about this for a bit. I'll check back tomorrow or so. There's really no good choice here.
I created a Github support ticket (#747630, for reference) to check if there are other options available. Or maybe they can manually support w.r.t. this limitation.
For a good management like this has existed for many years, the best place must remain separate from the Jitsi.
@cobratbq has done a lot of work and the best place is to stay here.
The Jitsi organization (and members from) has not done contributions before this process.
It is a better thing than giving freedom to this project, and it is deserved.
About the license part:
/*
* otr4j, the open source java otr library.
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
* Copyright @ 2015 Atlassian Pty Ltd
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
How we can change it?
Atlassian Pty Ltd and Jitsi, it is finish.
Thanks Danny! Actually there is option 3:
@Neustradamus Since 8x8 purchased all Jitsi assets that would now say "8x8, Inc." it's a one line change.
@saghul: Thanks.
@ibauersachs: I do not understand, it is better to do not move the best repository in Jitsi organization.
This change will announce the second death of OTR4J.
@Neustradamus LIke President Bartlet said: "decisions are made by those who show up". I don't see you here: https://github.com/otr4j/otr4j/graphs/contributors And neither am I.
Thus, please stop pushing others to do what you want. You've been heard AFAICT. Now let the people who actually do the work find the best way forward.
@cobratbq Have you heard anything from GitHub?
@cobratbq Have you heard anything from GitHub?
Yes, actually I have. Unfortunately, not possible. The recommendations they do make are about deleting the original jitsi/otr4j
but that is with the well-known consequences of having the fork-graph impacted. They can't really provide the options that we'd like to hear.
@saghul @ibauersachs I do understand what @Neustradamus is saying. What is actually the issue with moving the leading otr4j repository into a different organization? As mentioned before, permissions shouldn't be an issue. At this point it is not merely a "political" preference, but also due to technical limitations.
What about option 3) i mentioned on 24th?
But basically I don't really care as long as I can soon get a version that 1) has no dependency on BouncyCastle 2) has OSGi metadata 3) is published to Maven Central.
I can do all of that in this repo myself and not care much for anything else. I can do a PR in otr4j/ for 1 and 2, but 3 is only possible into org.jitsi from within jitsi/. If you plan on publishing to org.otr4j:otr4j:0.23 on Maven Central, you'll need to control the domain (who owns this btw? it points to this repo). And for 1 and 2, I'd rather do those changes in a repo that isn't abandoned outside of Jitsi Desktop.
Hi all,
There has been a request (@Neustradamus) to re-establish work on otr4j/otr4j's effort as organization for otr4j and with it the question of which repo's exist, and for what purpose and why so many and what to use. I'd like to see if we can pick up the conversation again.
I was under the impression that there were no issues regarding the existence of otr4j/otr4j. However, recently I have doubts. Please know that there was no bad intention for my continued work on that fork other than wanting to implement under the original license. I am happy to merge the work into jitsi/otr4j, and that includes the license change, for as far as I can grant this. So, if this is a sensitive topic then I would like to discuss it. (Note that I have not offered any changes so far because the work is incomplete.)
Further more there is additional confusion given that https://github.com/redsolution/otr4j is listed by github.com as "the original otr4j repo", with rest being forks of that. However, IIUC jitsi/otr4j is the only one that publishes packages to maven, for example. (I do not know if the release packages at otr4j/otr4j are used by anyone or who created those.)
I have already invited George to the organization. Of course we can change/add invites as needed.
Your thoughts?