I liked Konstantin's suggestion of a roadmap. As stated here, having a plan
for how features should be developed goes hand in hand with which features
should be developed in the first place.
I also liked the suggestion of making the core VM more amenable to different
languages. I like this because it will force some design concerns into one
direction or another. I also like it because it recognizes that these VMs,
whether V8 or LuaJIT, are becoming defecto "machines", and are likely to be at
the center of the next round of 'container' innovations.
Also, along the lines of 'vision', I say ditch the 'drop-in' compatibility with
Lua 5.1. We all know it's not a straight drop in replacement, so we should
just move on from that stance, as it will probably relax some of the
constraints that are currently in the system. Either that, or make a concerted
effort to remerge this work back to Lua mainline, and end the differences. My
vote would be for the former.
I'd love to nominate a few key contributors based on what I've observed on this
mailing list, and out in GitHub over the past couple of years. Perhaps that's
a good place to start in terms of figuring out who 'the voice at the top' might
As for CloudFlare, if you're paying, then you hire someone to deal with the
thankless job of dealing with pull requests. The community can review, but
someone needs to pull the trigger, and make the commits (after running myriad
test suites of course).
- Shaping clay is easier than digging it out of the ground.
Date: Tue, 18 Aug 2015 06:50:35 -0700
Subject: Re: LuaJIT project governance
We would appreciate the thoughts of people in this group on the best way to
manage the project.
Speaking as a non-expert it seems to me the biggest "design choice"for the
group is having some kind of plan for how major new features will be