> > On Dec 12, 2011, at 11:21 , Xavier Leroy wrote: > >> - It complicates the lives of OCaml users, packagers, and 3rd-party >> library developers: what version should they use? what will be the >> basis for the packagers's distribution-specific patches? what >> happens if a library is compatible with one version but not the >> other? what if the community effort runs out of steam in a few years? > > If we can adopt the eglibc model, then the community thing will be the > version shipped by distributions, i.e. the community thing is the OCaml > for distributions/packagers, not an alternative to the official version. > That way we do no longer need to maintain specific patches / versions for > Debian, Red Hat, MacPorts, etc. This ensures that versions are compatible > across different distributions (because they do no longer need to maintain > their own set of patches).
Most distribution patches are really distribution-specific. I don't think that there will be any savings. IMHO, you have to convince the distributions whether they want to ship a community version of ocaml or keep the original version. > I think of the community thing as: > > (a) A single place for patches, while waiting for the next official OCaml > release. IF the community version is just a place for testing new patches this would be for sure a good thing. The ocaml distributions could ship this in special "testing" repositories. This way the patches would see broader testing before the inclusion into the core repo. There would be certainly some users who are willing to accept the additional risks of using a testing distro. IF this is just meant for smuggling in patches the core team does not like, I don't see the value of it. The community should not work against them. > (b) A common ground for experimenting with new features. As you already > noted, feedback and adoption for experimental stuff hidden within the SVN > repository wasn't all that great, so maybe we can change it this way (esp. > since it would be coordinated with the distributions/packagers to some > degree). I think the problem is that you can only easily build core ocaml this way, but you normally need more packages for testing (e.g. run your program). GODI has support for building ocaml from any SVN branch, but there is close to zero documentation how this works. >> - It means additional efforts with some duplication. The >> synchronization between the "community" and the "reference" code >> bases will take work. From the core team's standpoint, that's about >> as much work as dealing with individual suggestions and >> contributions. At the same time, the community team will spend >> non-negligible time organizing and administering itself, at least >> initially. Xavier, I would not see this as negatively (but I am also not fully convinced). If the community makes good suggestions, it could save a lot of development work. Granted, the time needed for communication will be higher - e.g. for setting quality standards, for explaining future directions etc, but in total this could nevertheless be a win. The biggest plus could be to attract new members for the core team, and to generally increase the expertise about ocaml internals in the community. Of course, if the community does not care about quality etc., and just includes everything, there is no win. Gerd > The community team (namely the packagers in this case) already spend this > time, as already noted by others (i.e. Stephane). And even if that's the > same effort for the core team (I doubt that, since if nothing else, you'll > at least have a single tested patch set to review, instead of a bunch of > independent, incompatible, and probably untested patches), then there's at > least the win for the community. > > I shouldn't have used the term "fork" initially, this is misleading. Don't > get me wrong. Don't think of my proposal as a "OpenBSD vs. NetBSD" thing > with a whole new project. > >>> Why not accept a model similar to i.e. the NetBSD project, with a >>> lot of committers (experts in their own areas) and 2-3 people to >>> keep an eye on the overall direction? >> >> Except for the "lot of committers" part, this is pretty much how the >> core Caml team has been working, and there is definitely room for more >> contributors. As I mentioned earlier, there are a number of areas >> where we're lacking manpower, e.g. Windows-related stuff and tools >> such as the debugger or Camlp4, but many other areas of the system >> would benefit from more contributors too. Smaller contributions >> are most welcome as well, such as commenting on the PRs, testing >> changes, new features and release candidates, PR triaging, helping to >> identify the top little things to be resolved by the next release, >> etc. >> >> That's a much more low-key approach, but one that is more likely to >> succeed. Volunteers are welcome to contact us as [email protected]. > > I can help with the low-level compiler and runtime stuff, others have > already expressed their intention to help with Camlp4, etc. You'll receive > an email. > >> - Xavier Leroy > > > Benedikt > > > > -- > 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
