Re: [Caml-list] OCaml maintenance status / community fork (again)

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

On 2011/12/08, at 18:10, Benedikt Meurer wrote:

> Dear caml-list,
> 
> I'd like to get back to the original topic, which BTW had nothing to do with Web 2.0, documentation, books, teaching, Batteries, PR, or whatever other topics came up. Of course those are important topics too, but hijacking other threads won't help with either.
> 
> There were already a few useful comments on the topic, but no statement from the current INRIA officials. Opening up the development of OCaml is a great suggestion, for example. Personally I'd even suggest to disconnect OCaml and INRIA, with an independent team of core maintainers (with appropriate spare time and knowledge). INRIA would still contribute to OCaml, but no longer control OCaml.
> 
> And to respond to those who think that the current development process is a "good thing" and leads to stability: By no way. It leads to stagnation and ignorance (most probably). For example, have a look at PR/3746, a great example. It took almost 4 years(!) to update the ARM port to softfp (and EABI). At the time the issue was finally fixed, most ARM application boards were already shipping with VFP, so the port is lacking behind several years. And even after all that time, the ARM port is not implemented properly, i.e. it's of the IP for argument passing does not only cause trouble with position independent code, but is forbidden in general because IP is reserved for linker stubs, both static and dynamic. The relevant bug report PR/5404, which includes a backward compatible patch, is already waiting for a sign of life for 3 weeks now (maybe wait another 4 years to get the port fixed). And what about the ARMv7-a / armhf port? I almost got it working, but looking at the past !
> of the ARM port, I'm already pissed off by the fact that it will probably take ages for someone to even respond to the patch, not to mention that it will take forever to get it out to the users (well maybe Debian will include the patch for armhf, but that means the Debian developers have to do upstream work...).
> 
> Granted, ARM is not (yet) the main target platform, it's just to illustrate the inherent weakness of closed development combined with lack of time/interest. Sure there will always be areas where projects cannot keep up because of lack of knowledge/time, but it is unnecessarily frustrating and harmful for an open source project to lack behind in areas with active contributors with both knowledge and time. That's why I'd suggest to set OCaml free, either with the help of INRIA and by leaving INRIA behind if there's no other way to move on.
> 
> In either case, it'd be great if the official core team would at least take the time to comment on this issue.
> 
> best regards,
> Benedikt
> 
> PS: Please avoid hijacking this thread.

Dear Benedikt,

I do agree that the problem with ARM reflect some problem in the current development organization, but I don't think that you need to fork to solve it. (And note by the way that a real fork could be in contradiction with the QPL.)

Before attacking the current model, you should understand how it works, and why it actually works mostly well considering that OCaml, without being huge, is still a rather complex piece of software.
My understanding is that somebody is responsible for every line of code in the distribution.
So when a bug report comes, it is usually clear who should do the job, and generally this is done pretty fast.
Not always in the next 24 hours, but everybody tries no to be too late.
Considering other obligations this can mean a few weeks.
(When it is more than that, this may actually mean an oversight; there is a huge number of bug reports, so this can happen)
The main point here is that the person who fixes the problem usually is the most competent person available for this piece of code.
This seems a requisite for quality.

Another consequence of this approach is that usually patches are not applied directly.
When you know that you are going to be responsible for the code, you look carefully at a patch before applying it,
and often you find a better way to do it in the process :-)

Now, your specific problem occurs in a port that probably only few people in the core team even use.
If you look at the log, you will see that Xavier is maintaining it, in his spare time.
I cannot answer for him, but he might be more than willing to find somebody else to do this specific job,
as maintaining a port requires checking lots of information sources for a small number of lines of code.
This kind of code could be a good candidate for "outsourcing" as maintaining it requires more knowledge of the specific architecture than of the inner workings of OCaml.

However, this is not the case for most of the rest of OCaml.
As the problem is specific, the solution should probably be specific, and forking seems an overkill.
On the other hand, there is no restriction on cloning the repository and distributing patches in the meantime.
Lots of people are already doing that for their own reasons (I have done that in the past), and I don't think that having all of them working with the same repository would be useful.

Jacques Garrigue (personal viewpoint)