> Dear OCaml hackers, > > I'm very uneasy about the current opinions that are voiced on the > caml-list. I have good reasons to think I'm not the only one in that > situation, so please allow me to raise a few concerns about some recent > discussions. > > There's several subtopics in the "OCaml maintenance status / community > fork" that I'd like to discuss. > > = Improving the community = > > I think the main point of the discussion is to improve "the community". > If we really want to improve OCaml as a whole, then I think we can put > our efforts on better areas than patching the compiler.
ACK. Of course, improving the compiler is a topic of its own. I can fully understand Benedikt's frustration. > == Package management system == > > The thing that's most needed is, imho, a package manager that works. > Oasis-db looked very promising as far as I could tell, but Sylvain > doesn't have as much time as he used to do. Instead of hacking on our > pet projects (which is, I admit, very rewarding), maybe someone could > step up and make Oasis-db happen. We don't have a single, unified answer > to "what should I install to easily hack with OCaml?". What made Python, > Perl, Haskell successful is the package management systems. How much > longer are we going to shy away from this issue? Sure, it's much more > fun to hack on the compiler. Not as useful. We discussed this often enough. I think Oasis-db is a part of that, but not the answer to everything. It is more designed to package smaller libraries. If you want a more universal answer, you end up with something like GODI. Btw, some quite popular languages can live entirely without package management. What I mean: this makes life easier, but is not crucial to adaption. Users choose languages because of other criteria. > == Leaving our own corner of the web == > > The OCaml community likes to stay in its own corner of the web, in > isolation. We live on obscure web sites: who knows about ocamlforge > outside the OCaml community? Who knows about the caml hump? We could > host our projects on Sourceforge or on GitHub. We could get recognition > in the open-source world through our projects, we could be more social, > we could boost the language stats on ohloh, we could attract more > contributors (being a fervent user of GitHub, I must say I've attracted > a significant amount of contributors that way ; being on an obscure > forge, I'm certain it would've never happened). We stay away from that. > Why? Because GitHub is not open-source. The whole point of git is that > everyone, everywhere has a backup copy and that we don't care if GitHub > falls down. Nevermind. This may all be true for a single person. A group is recognized differently, though, especially by real social interaction (conferences, meetings etc.), by press coverage, and by company support. > GitHub Can't we stop talking about such very technical things? There are ocaml projects on GitHub, and ocaml popularity hasn't boosted because of this. > = What is this about ? = > > If it's about improving the general situation with OCaml and its > community (the title of this thread contains the word "community"), then > I believe hacking on the compiler is not the most effective way to > achieve that goal. We're hackers. We like to hack on things. And we > often fail to ask ourselves: is it really worth implementing? Submitting > patches is easy. Submitting quality patches that do solve a real problem > is harder. The ARM backend does need a cleanup, and the patch does solve > a stringent issue. That may not be the case for all patches. You will for sure see troll patches - people trying to get something into the compiler that should better not be solved there. I'm not sure whether a community process can sort this all out. However, I'm not against trying it, because there is a large class of undoubted problems (e.g. errors). > There is indeed a problem w.r.t external contributions. I agree that the > INRIA team could make it clearer what its stance on external > contributions is. I'd also like to hear this. Gerd > Maybe one solution would be to have a INRIA-endorsed > ocaml-next on github that everyone can fork, where we would merge really > outstanding features, before submitting them to INRIA, as you described. > I don't think it is such a good idea creating a real fork. Maybe some > sort of integration platform on GitHub would be the right solution to > the "patch review" problem. > > I'm not even sure what kind of patches you wish to see integrated. Can > you clarify that? > > = Conclusion = > > This is indeed a long rant, but I'd like to see us being more practical > and down-to-earth. I love OCaml. I think we can do better for the > language. > > Kind regards, > > jonathan > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- Gerd Stolpmann, Darmstadt, Germany [email protected] Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
