[reSIProcate] Questions about resiprocate roadmap

Tue Mar 6 14:56:28 CST 2018

Hi Gregor,

Thanks for your help with this project lately, and your interest in
improving and moving resiprocate forward.  I've marked up your email with
my personal opinions or views.

I hope you get responses for others as well.  :)

...

On Tue, Mar 6, 2018 at 3:24 PM, Gregor Jasny via resiprocate-devel <
resiprocate-devel at resiprocate.org> wrote:

> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
> ---------- Forwarded message ----------
> From: Gregor Jasny <gjasny at googlemail.com>
> To: resiprocate-devel at resiprocate.org
> Cc:
> Bcc:
> Date: Tue, 6 Mar 2018 21:24:56 +0100
> Subject: Questions about resiprocate roadmap
> Hello,
>
> I'd like to share some thoughts and ask some questions about the future
> roadmap of resiprocate.
>
> * Schedule for stable 1.11 release *
>
> It's been a long time since the last resiprocate stable release. The
> first 1.11 alpha was tagged in November 2016, the first beta in January
> 2017. Debian seems to have picked up those betas and ships them in the
> stable distribution release.
>
> Since the last beta a lot of bug fixes went into master. Also
> resiprocate is now compatible with OpenSSL 1.1 which is crucial for most
> Linux distributions because they try to phase out OpenSSL 1.0
>
> Do you see any blockers preventing a 1.11 release or do you have patches
> that should definitely be part of an upcoming stable release? What's the
> release process for a new stable resiprocate?
>

[Scott]  Daniel Pocock was championing the resiprocate release process.
He's been a little MIA lately.  But the last time I talked to him, he was
interested in getting a release out there with the OpenSSL 1.1 support in
it.  I'm hoping he will respond to this.  :)

>
> * Switch to C++11 *
>
> At $Company we use resiprocate in a C++11 (and soon C++14 code base).
> Resiprocate's use of auto_ptr also on external interfaces gives us some
> deprecation warnings for auto_ptr. Surerely we could silence those, but
> AFAIR the final C++17 standard removed auto_ptr completely. So users of
> resiprocate will have to enable special C++ standard library
> compatibility flags, soon.
>
> What do you think about moving to C++11 after the 1.11 release has been
> branched off?
>

[Scott]  I'm in favour of this move.  I would like to understand if anyone
out there would be negatively effected by this move.   ie:  Are there some
users that are relying on older compilers, in particular older embedded
compilers?   This means VS2015+ for Windows users.

> * Google Test as a test driver *
>
> In several projects I used Google Test (and Mock) as a testing
> framework. If you don't abuse it it results in elegant and nicely
> readable tests. Also any detected errors are pretty descriptive and help
> the developer to figure out what's going on.
>
> Google Test supports fusing all own internal source files into one
> single file so embedding into a project isn't too intrusive. I prepared
> a test branch with a single converted test here:
>
> https://github.com/gjasny/resiprocate/tree/add-google-mock
>
> Google Test supports grouping of test cases into test suites and
> theoretically we could create a single unit test binary per library.
>

[Scott]  I don't have a strong opinion on this.  Because of the
complication of building our current tests in windows (needs a batch file),
I don't think they actually get built and run much right now (on Windows).
If the Google Test framework is easy to build in windows and makes running
these tests easier, I'm in favour.  However, Keep in mind we do have a set
of unit tests for dum and repro (TFM tests) that are currently using the
cppunit test framework, so bringing in another unit test framework, might
add complexity.

> * clang-format rules file *
>
> Regardless of how hard I try, there are always some formatting errors in
> my pull requests.  How about creating a clang-format file with the
> preferred formatting and add it to the repo? One could the use 'git
> clang-format' (or standalone clang-format) to format any patches to the
> desired style.
>

[Scott]  I don't know much about clang-format tool, but I'll assume it is a
tool to format code to our preferred style.  Anything to help new
developers with that is a good thing.  I say, go for it.  We could also add
a config file for Visual Studio settings as well.

> * CMake buildsystem
>
> My workstation OS is right now MacOS so there is no up-to-date
> buildsystem with IDE support within the resiprocate repository. In the
> past there was an initiative by Francis Joanis and Byron Campen to add
> the CMake buildsystem. I picked up their work and adjusted it to the
> current code base.  You can find a proof-of-concept that builds rutil,
> resip, dum, reflow, and reTurn here:
>
> https://github.com/resiprocate/resiprocate/pull/107
>
> It works with CLion, Xcode and Ninja/Make on MacOS and Ubuntu 16.04.
> I'll test (and probably fix) it on Windows later.  My general question
> would be if there is interest in CMake at all and if you could imagine
> to remove the Visual Studio solutions and projects in favour of CMake to
> reduce maintenance cost. (Same question for autotools).
>

[Scott]  The build system for linux has changed a number of times.  We
originally had a home grown make system, and a rudementary autotools build
for some embedded compilations, both were replaced by a more full
implemented autotools build by Danial Pocock (I beleive) - this is what is
used today.  To date, no solution we have has been able to sync linux and
Windows builds, so if we could find a solution for that, that would be
great.  I think Daniel has spoken of some ideas in this area in the past
(CMake/Ninja I think).  I have a number of customers using the Visual
Studio solution and project files and I believe having these readily
available is one of the draws for Windows users to resiprocate.  However,
if CMake is able to produce Visual Studio solutions and projects we might
get the best of both worlds, at the price of the additional complexity to
download and install CMake and generate the files - or maybe we could just
check-in the generated files?   I don't know CMake enough to really answer
this question.

>
> Thank you for your feedback!
>
>
> Cheers,
> Gregor
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20180306/8be2de3f/attachment.htm>