RE: LuaJIT project governance

  • From: Stefano <phd.st.p@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Tue, 18 Aug 2015 20:06:05 +0200

On 18 Aug 2015 18:06, "William Adams" <william_a_adams@xxxxxxxxxxx> wrote:


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.

Aside from the enormity of the task of abstracting LuaJIT to a more generic
VM, Mike has already explicitely opposed this suggestion.
Even though he is no longer leading the development I trust there are good
reasons for his judgement.


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 agree that the forward looking compatibility with Lua is going to be
problematic.
First of all because of the new number type in Lua 5.3 (btw, I personally
find the FFI based solution implemented in LuaJIT way preferable).

However, LuaJIT IS a drop in replacement for Lua 5.1. Dropping this would
mean giving up compatibility with all available existing Lua code for
little benefit.

Extending LuaJIT without breaking compatibility would be a good idea
instead (after all there is already LuaJIT-only code around due to the FFI).

Stefano


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 be.

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
From: demetri.spanos@xxxxxxxxx
To: luajit@xxxxxxxxxxxxx


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 approached.


Other related posts: