Opinions on forking libstrophe

[Boothj5]

I've recently started looking into adding SSL certificate verification to libstrophe as this is a feature that should be available in profanity.

It's raised the question again of whether profanity should continue to depend on libstrophe or whether there is a better option.  The main reason being the amount of maintenance required on libstrophe to support different XML Parser and SSL implementations, and the Windows support that is not required by profanity.

The options I can think of are:

1) Continue with dependency on libstrophe:
Advantages

• Make use of bug fixes, enhancements to libstrophe
• Already accepted into a number of distributions (although only since profanity was accepted)
  

Disadvantages

• Having to maintain two XML parser implementations
• Having to maintain multiple SSL implementations
• Having to maintain Windows support
• Having to release libstrophe for new profanity releases

2) Fork libstrophe as a new library:
Advantages

• Choose and maintain one implementation for XML parsing (expat)
• Choose and maintain one implementation for SSL (openSSL)
• Remove Windows support
• Ability to pull bug fixes/enhancements from libstrophe
• The fork will be available to the community

Disadvantages

• Having to release the fork for new profanity releases
• Distribution package maintainers have already accepted libstrophe, the fork would now need to be accepted
• Users are forced to use the chosen dependency implementations (expat, openSSL)
  

3) Copy libstrophe into the profanity source tree and maintain with profanity:
Advantages

• Choose one implementation for XML parsing (expat)
• Choose one implementation for SSL (openSSL)
• Remove Windows support
• Becomes part of profanity, simpler releases
• New distribution package maintainers do not need to add libstrophe package

Disadvantages

• Harder to pull fixes/enhancements from libstrophe
• More dependencies for profanity (transitive dependencies of libstrophe)
• Users are forced to use the chosen dependency implementations (expat, openSSL)
  
• More code in profanity
• License complexities
• Changes no longer available to the community
  

Assuming that only supporting expat and openSSL is not a problem, my initial thought is that option 2 is probably the best option; fork and maintain a simpler version of libstrophe.

I'd be interested to hear the opinions of developers, package maintainers and users.

James.

[Boothj5]

After some feedback and discussion, I've decided to go for option 2) Fork libstrophe as a new library.

The fork can be found at libmesode.

The latest Profanity code in master will attempt to link with libmesode, and fall back to libstrophe if it cannot be found. Linking to libstrophe will eventually be removed once libmesode has been released and accepted into the various distros that already have libstrophe.

[pasis]

libmesode is in unofficial Gentoo overlay now. And profanity from the overlay can be built with either libmesode (has priority) or libstrophe. To try it out:

# add overlay 'stuff' or update it with -s
layman -a stuff
# add libmesode-9999 and profanity-9999 to package.keywords
# (need to do this only once)
echo =dev-libs/libmesode-9999 >> /etc/portage/package.keywords
echo =net-im/profanity-9999 >> /etc/portage/package.keywords
# install profanity (if libstrophe installed it will be used)
emerge =profanity-9999::stuff

On Tuesday, September 22, 2015 at 1:14:14 AM UTC+3, Boothj5 wrote:
> After some feedback and discussion, I've decided to go for option 2) Fork libstrophe as a new library.
>
> The fork can be found at libmesode.
>
> The latest Profanity code in master will attempt to link with libmesode, and fall back to libstrophe if it cannot be found. Linking to libstrophe will eventually be removed once libmesode has been released and accepted into the various distros that already have libstrophe.
>
> On Tuesday, September 15, 2015 at 12:47:44 AM UTC+1, Boothj5 wrote:
> I've recently started looking into adding SSL certificate verification to libstrophe as this is a feature that should be available in profanity.
>
> It's raised the question again of whether profanity should continue to depend on libstrophe or whether there is a better option.  The main reason being the amount of maintenance required on libstrophe to support different XML Parser and SSL implementations, and the Windows support that is not required by profanity.
>
> The options I can think of are:
>
> 1) Continue with dependency on libstrophe:
> Advantages

> Make use of bug fixes, enhancements to libstropheAlready accepted into a number of distributions (although only since profanity was accepted)
> Disadvantages
> Having to maintain two XML parser implementationsHaving to maintain multiple SSL implementationsHaving to maintain Windows supportHaving to release libstrophe for new profanity releases

> 2) Fork libstrophe as a new library:
> Advantages

> Choose and maintain one implementation for XML parsing (expat)Choose and maintain one implementation for SSL (openSSL)Remove Windows supportAbility to pull bug fixes/enhancements from libstropheThe fork will be available to the communityDisadvantages
> Having to release the fork for new profanity releasesDistribution package maintainers have already accepted libstrophe, the fork would now need to be acceptedUsers are forced to use the chosen dependency implementations (expat, openSSL)

>
> 3) Copy libstrophe into the profanity source tree and maintain with profanity:
> Advantages

> Choose one implementation for XML parsing (expat)Choose one implementation for SSL (openSSL)Remove Windows supportBecomes part of profanity, simpler releasesNew distribution package maintainers do not need to add libstrophe packageDisadvantages
> Harder to pull fixes/enhancements from libstropheMore dependencies for profanity (transitive dependencies of libstrophe)Users are forced to use the chosen dependency implementations (expat, openSSL)
> More code in profanityLicense complexitiesChanges no longer available to the community

> Assuming that only supporting expat and openSSL is not a problem, my initial thought is that option 2 is probably the best option; fork and maintain a simpler version of libstrophe.
>
> I'd be interested to hear the opinions of developers, package maintainers and users.
>
> James.

[incertia]

libmesode now has an upstream git package in the AUR, libmesode-git.