[erlang-questions] modular otp concerns

[Björn-Egil Dahlberg]

On 2014-02-18 14:30, Loïc Hoguin wrote:
> On 02/18/2014 12:48 PM, Tuncer Ayaz wrote:
>> I know that at least Bjoern-Egil has been investigating the 
>> possibility of
>> splitting up otp.git into sub repos, and before anything is set into
>> stone, I'd like to resolve one concern I have.
>
> I thought he was the only proponent of this in the OTP team?
>

Hi there!

The following is my take on this.

Ok, so a modular OTP has be talked about in a context of a package 
manager (PM). The recent revival PM discussions on this ML has me a bit 
worried. I feel it lacks focus, everybody has an idea of they want and 
starts coding. That is fine but OTP can't commit to any of it at this 
point and I'll try to iron out why. I don't have all the details in my 
head so bear with me.

If/when we split the OTP repository, and this split should be on the 
level where we have specific versions i.e. on application level. It has 
solve the issue of easy delivery of new patches and release on these 
specific applications. Some have voiced a concern that it will simply be 
to many repos and we should instead group them, i.e. Orber + cos* etc. I 
say fine, if so then those applications should have one version (and be 
a single application). One versioned entity per repository thank you.

For our customers within Ericsson, we have to be able to patch a 
specific application on a specific level (no surprise there), and the 
norm has been to build binary deliverables that is delivered in 
clearcase. Due to increasing growth of supported platforms it is now 
unsustainable to provide binary deliveries for all these platforms along 
with different build settings.

To support source patch-deliveries and to avoid a permutation explosion 
with tags in the main otp repo with releases and patches, we (or atlease 
I) would like to split the otp repository to a maintainable level. The 
application level is extraordinary good and a natural one. Application 
versions can be tagged directly in the application repo without 
specifying some globally defined patchlevel on the otp repo. A split has 
additional benefits such as decoupled release cycles and streamlining 
otp applications to look like any other application. We could also setup 
different maintainers for different, traditionally OTP only, 
applications on GitHub. This could ease development for those applications.

Applications needs to understand dependencies. I've already stated that 
we want src-deliveries and this is key. We have nifs and drivers that is 
platform dependent but even prebuilding beam-files might be problematic 
since we could have different (older) erlang runtimes trying to load too 
new code. This means we at least have two types of dependencies, a build 
dependency (or requirement) for building the application and a runtime 
dependency for running the application. I would like to specify these 
dependencies in the .app.src file and specify that such files needs to 
be interpretable before compiling or sedding them. Alternatively, having 
yet another file: a manifest file.

.. now i've been interrupted too many times writing this mail ..

What I would like to say is, OTP wants a package manager to make a split 
viable and we have to have some control of a PM to be able to use it for 
delivering patches within Ericsson. Certain requirements has to be met, 
for instance cross compilation has to work flawlessly, and we need to be 
able to specify private sources to private users, i.e. no central 
tracker. Otherwise we have to roll our own system. All of this will be 
discussed internally at OTP between 17.0 - 18.0, so the timing of a PM 
discussion on the list is a bit off. =)

// Björn-Egil