[jitsi-dev] otr4j versioning scheme and other dev questions


#1

hello everyone! :slight_smile:

about me (as this is my first post here):
i am interested in jitsi and especially otr4j, for using them to
communicate with friends (most of which are no techies). i already
convinced 3 friends, and encountered various small usability problems and
errors, which i would like to help to smooth out. i have a college
education in software development and spent a lot of free time working on
free software projects, predominantly in java, followed by C++ and C. i am
used to git and pull requests.

i list some things here that i noticed and what i would like to do (mostly
with otr4j). i am new, and thus it may all be related due to me having
insufficient insight into code and dependencies yet, so i would just like a
bit of feedback if possible, or one or two OKs.

otr4j versioning scheme:
i saw that pom.xml (latest otr4j github commit) uses plain numeral versions
(for example "0.22"), instead of the Maven standard snapshot system.
I personally already ran into a minor problem with that, and thus would
like to ask whether it would be ok to switch it to the snapshot model,
which works like this:
only release commits have a version like "0.22". all other commits have a
version like "0.22-SNAPSHOT".
this makes sure that if one sees/uses a normal version like "0.22", one can
be sure to always have the same commit/version of the package, which is
also usually more or less stable. if one wants to use/try dev versions, one
has to manually change (for example the dependency version tag in the jitsi
project) to a snapshot version.

OTR authentication:
this seems to be kind of buggy with the current jitsi git version, and i
would like to fiddle with that too, if noone else is doing that already/it
makes sense.
what i saw for example, was that sometimes authentication seemed ot just
stop in the middle of the process without any error message, and for the
shard secret way of authenticating, it even just failed without asking the
second party for the secret.

ort4j Maven reporting:
i would also like to introduce some maven reports for ort4j, mainly PMD (&
CMP), FindBugs and Checkstyle, to make the code a bit more standard, and to
remove minor or medium possible problems.
i think this is kind of useful for security relevant code.

thanks for jitsi and otr4j! :slight_smile:


#2

Hi Robin,

Fellow jitsi user here, see one comment about static analysis below.

hello everyone! :slight_smile:

about me (as this is my first post here):
i am interested in jitsi and especially otr4j, for using them to
communicate with friends (most of which are no techies). i already
convinced 3 friends, and encountered various small usability problems
and errors, which i would like to help to smooth out. i have a college
education in software development and spent a lot of free time working
on free software projects, predominantly in java, followed by C++ and
C. i am used to git and pull requests.

i list some things here that i noticed and what i would like to do
(mostly with otr4j). i am new, and thus it may all be related due to
me having insufficient insight into code and dependencies yet, so i
would just like a bit of feedback if possible, or one or two OKs.

otr4j versioning scheme:
i saw that pom.xml (latest otr4j github commit) uses plain numeral
versions (for example "0.22"), instead of the Maven standard snapshot
system.
I personally already ran into a minor problem with that, and thus
would like to ask whether it would be ok to switch it to the snapshot
model, which works like this:
only release commits have a version like "0.22". all other commits
have a version like "0.22-SNAPSHOT".
this makes sure that if one sees/uses a normal version like "0.22",
one can be sure to always have the same commit/version of the package,
which is also usually more or less stable. if one wants to use/try dev
versions, one has to manually change (for example the dependency
version tag in the jitsi project) to a snapshot version.

OTR authentication:
this seems to be kind of buggy with the current jitsi git version, and
i would like to fiddle with that too, if noone else is doing that
already/it makes sense.
what i saw for example, was that sometimes authentication seemed ot
just stop in the middle of the process without any error message, and
for the shard secret way of authenticating, it even just failed
without asking the second party for the secret.

ort4j Maven reporting:
i would also like to introduce some maven reports for ort4j, mainly
PMD (& CMP), FindBugs and Checkstyle, to make the code a bit more
standard, and to remove minor or medium possible problems.
i think this is kind of useful for security relevant code.

Bringing static analysis into the delivery process is a great idea. If
you get a chance, I suggest using SonarQube with its default ruleset to
get feedback on the most important potential issues. In my experience,
with its out-of-the-box rules, SonarQube found far fewer debatable
issues, and only a few true issues would end up in "blocker" or
"critical" categories as compared to PMD, FindBugs which gave good
feedback but which was often overwhelming.

Jesse

路路路

On Tue, 2016-01-05 at 12:04 +0100, Robin Vobruba wrote:

thanks for jitsi and otr4j! :slight_smile:

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

hey jesse! :slight_smile:
i have not heard of it before, thanks! :slight_smile:
it seems like a good idea to use for devs, individually, but not to be
integrated into the project, as i see it.
as i get it, for it to work and not fail the build, one has to install the
binary from the homepage manually, and run it as a server, before running
the tests. also, it can be run without changing the pom, so it is up to
every dev himself whether he wants to use it or not. i will try it.
thanks again!

路路路

2016-01-09 19:37 GMT+01:00 Jesse <bickelj@gmail.com>:

Hi Robin,

Fellow jitsi user here, see one comment about static analysis below.

On Tue, 2016-01-05 at 12:04 +0100, Robin Vobruba wrote:
> hello everyone! :slight_smile:
>
> about me (as this is my first post here):
> i am interested in jitsi and especially otr4j, for using them to
> communicate with friends (most of which are no techies). i already
> convinced 3 friends, and encountered various small usability problems
> and errors, which i would like to help to smooth out. i have a college
> education in software development and spent a lot of free time working
> on free software projects, predominantly in java, followed by C++ and
> C. i am used to git and pull requests.
>
> i list some things here that i noticed and what i would like to do
> (mostly with otr4j). i am new, and thus it may all be related due to
> me having insufficient insight into code and dependencies yet, so i
> would just like a bit of feedback if possible, or one or two OKs.
>
> otr4j versioning scheme:
> i saw that pom.xml (latest otr4j github commit) uses plain numeral
> versions (for example "0.22"), instead of the Maven standard snapshot
> system.
> I personally already ran into a minor problem with that, and thus
> would like to ask whether it would be ok to switch it to the snapshot
> model, which works like this:
> only release commits have a version like "0.22". all other commits
> have a version like "0.22-SNAPSHOT".
> this makes sure that if one sees/uses a normal version like "0.22",
> one can be sure to always have the same commit/version of the package,
> which is also usually more or less stable. if one wants to use/try dev
> versions, one has to manually change (for example the dependency
> version tag in the jitsi project) to a snapshot version.
>
> OTR authentication:
> this seems to be kind of buggy with the current jitsi git version, and
> i would like to fiddle with that too, if noone else is doing that
> already/it makes sense.
> what i saw for example, was that sometimes authentication seemed ot
> just stop in the middle of the process without any error message, and
> for the shard secret way of authenticating, it even just failed
> without asking the second party for the secret.
>
> ort4j Maven reporting:
> i would also like to introduce some maven reports for ort4j, mainly
> PMD (& CMP), FindBugs and Checkstyle, to make the code a bit more
> standard, and to remove minor or medium possible problems.
> i think this is kind of useful for security relevant code.

Bringing static analysis into the delivery process is a great idea. If
you get a chance, I suggest using SonarQube with its default ruleset to
get feedback on the most important potential issues. In my experience,
with its out-of-the-box rules, SonarQube found far fewer debatable
issues, and only a few true issues would end up in "blocker" or
"critical" categories as compared to PMD, FindBugs which gave good
feedback but which was often overwhelming.

Jesse

>
> thanks for jitsi and otr4j! :slight_smile:
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hey Robin, Jesse,

Thank you for bringing up these issues and for your interest in the
project. About the versioning scheme, it makes sense to switch to what
you're suggesting, especially if this is the standard maven way. I am going
to change that today.

I'm not very familiar with all the tools that you mention (SonarQube, PMD,
FindBugs, etc.), but, if they bring value to the project I think we would
love to have them and we'd gladly accept contributions for that.

We already have some tests, could you please explain what's the added
benefit of using them, how can we incorporate them in otr4j and how they'll
work in the context of otr4j?

Best,
George

路路路

On Sat, Jan 9, 2016 at 1:04 PM, Robin Vobruba <mls.robin.vobruba@gmail.com> wrote:

hey jesse! :slight_smile:
i have not heard of it before, thanks! :slight_smile:
it seems like a good idea to use for devs, individually, but not to be
integrated into the project, as i see it.
as i get it, for it to work and not fail the build, one has to install the
binary from the homepage manually, and run it as a server, before running
the tests. also, it can be run without changing the pom, so it is up to
every dev himself whether he wants to use it or not. i will try it.
thanks again!

2016-01-09 19:37 GMT+01:00 Jesse <bickelj@gmail.com>:

Hi Robin,

Fellow jitsi user here, see one comment about static analysis below.

On Tue, 2016-01-05 at 12:04 +0100, Robin Vobruba wrote:
> hello everyone! :slight_smile:
>
> about me (as this is my first post here):
> i am interested in jitsi and especially otr4j, for using them to
> communicate with friends (most of which are no techies). i already
> convinced 3 friends, and encountered various small usability problems
> and errors, which i would like to help to smooth out. i have a college
> education in software development and spent a lot of free time working
> on free software projects, predominantly in java, followed by C++ and
> C. i am used to git and pull requests.
>
> i list some things here that i noticed and what i would like to do
> (mostly with otr4j). i am new, and thus it may all be related due to
> me having insufficient insight into code and dependencies yet, so i
> would just like a bit of feedback if possible, or one or two OKs.
>
> otr4j versioning scheme:
> i saw that pom.xml (latest otr4j github commit) uses plain numeral
> versions (for example "0.22"), instead of the Maven standard snapshot
> system.
> I personally already ran into a minor problem with that, and thus
> would like to ask whether it would be ok to switch it to the snapshot
> model, which works like this:
> only release commits have a version like "0.22". all other commits
> have a version like "0.22-SNAPSHOT".
> this makes sure that if one sees/uses a normal version like "0.22",
> one can be sure to always have the same commit/version of the package,
> which is also usually more or less stable. if one wants to use/try dev
> versions, one has to manually change (for example the dependency
> version tag in the jitsi project) to a snapshot version.
>
> OTR authentication:
> this seems to be kind of buggy with the current jitsi git version, and
> i would like to fiddle with that too, if noone else is doing that
> already/it makes sense.
> what i saw for example, was that sometimes authentication seemed ot
> just stop in the middle of the process without any error message, and
> for the shard secret way of authenticating, it even just failed
> without asking the second party for the secret.
>
> ort4j Maven reporting:
> i would also like to introduce some maven reports for ort4j, mainly
> PMD (& CMP), FindBugs and Checkstyle, to make the code a bit more
> standard, and to remove minor or medium possible problems.
> i think this is kind of useful for security relevant code.

Bringing static analysis into the delivery process is a great idea. If
you get a chance, I suggest using SonarQube with its default ruleset to
get feedback on the most important potential issues. In my experience,
with its out-of-the-box rules, SonarQube found far fewer debatable
issues, and only a few true issues would end up in "blocker" or
"critical" categories as compared to PMD, FindBugs which gave good
feedback but which was often overwhelming.

Jesse

>
> thanks for jitsi and otr4j! :slight_smile:
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev