On 12/10/2011 04:45 PM, Xavier Leroy wrote: > All right. Let me stop here and pray for constructive, non-knee-jerk > reactions.
I am not an active member of the OCaml community, but I'll try to suggest some (constructive I hope) solutions. > see very few people actually joining these efforts. For another example, > the core Caml development team sometimes asks for testing and opinions on > new directions (e.g. I on the x86-32bits-SSE2 code generator, or Jacques > Garrigue on GADT prototypes) and response rate is very low. It feels like > herding cats. > > 5- Before embarking on patching the core Caml distribution, it wouldn't hurt > to ask (privately) where the priorities are. > For instance, I don't see the > point for a linear-scan allocator (Benedikt Meurer) or more efficient > compilation of value let-rec (Fabrice le Fessant), but anyone who would come > up with a GHC-quality function inliner would be welcome like the Messiah. > Likewise, for many years I've been looking for developers to work on the > Windows port(s) of OCaml and never found any. Finally, at the latest OCaml > consortium meeting, the idea of splitting Camlp4 off the core distribution > was floated around; volunteers to take over its maintenance would be most > welcome. IMHO it would be useful if there was a single place that collects this information. It could be something as simple as a webpage (or a wiki). It'd contain a link to the relevant ML thread, and a (sort of) up-to-date status (for example: testing on platform X is adequate, but we still need testing on platform Y). - Testing Needed: URL of SVN branch/tag that needs to be tested, and list of platforms - New language feature feedback: URL of SVN branch/tag that implements it, and what kind of feedback is expected - Open Projects for improving the compiler (i.e. the GHC-quality inliner above) - Open Projects for improving the standard library - Low-Priority projects: i.e. things that were suggested by the community, but are not needed right now, perhaps with a one-line motivation (i.e. the regalloc you mention) - Roadmap for next OCaml version: a glimpse of what can be expected for the next major/minor version - Pings: link to ML thread that didn't receive enough feedback, and it would be important to get it soon. Or topics that go ignored for a long time (i.e. help with Windows port you mention above) People could check that from time to time, and see where they could help, and more importantly see where the core team needs help. It could be something as simple as a webpage (linked from caml.inria.fr) that contains a link to the relevant mailing list thread, or a wiki page that can only be edited by the core team. If maintaining that webpage would take up too much time, then perhaps someone from the community could volunteer to maintain it. The core team would only send an email with a specific subject tag to the regular ML, and post updated the same way (testing on platform X is adequate, we still need more on platform Y) Subject: [ Ping ] [ Testing Needed | Language feature feedback .... ] <.....> CC: communitymaintainer@.... > > 4- Yes, we obviously have problems with PR triaging, in part because Mantis > makes this task more bureaucratic than strictly necessary, but more > importantly because it is often hard to guess who cares about this or that > suggestion, or even what problem it is supposed to address. Volunteers > could greatly help by simply commenting on the PRs in Mantis, to express > support or disagreement, or to ask for clarifications. Would it help if people wrote small patches for the bugreports they care about (at least for bugreports that are not about the core parts of the compiler)? For example fixes/improvements to ocamlbuild, or I've just noticed a French message from ocamldoc yesterday, etc. Or does reviewing these patches take up almost as much time as writing it yourself? Best regards, --Edwin -- 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
