RE: LuaJIT project governance

  • From: William Adams <william_a_adams@xxxxxxxxxxx>
  • To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
  • Date: Tue, 18 Aug 2015 17:14:32 +0000

Also, with respect to "TODO list", Mike Pall is currently entering a bunch of
stuff into the issues tracker in the GitHub repository. From what I can tell,
that's a first cut at a 'roadmap' of sorts.
It might be a good practice to knock of some of the low lying fruit (OSX build
system), and then tackling some of the simpler feature enhancements as a means
for learning the codebase, and working out the details of build systems, test
automation, review, and the like. Gives us a chance to practice as a community.
-- William

===============================
- Shaping clay is easier than digging it out of the ground.

From: william_a_adams@xxxxxxxxxxx
To: luajit@xxxxxxxxxxxxx
Subject: RE: LuaJIT project governance
Date: Tue, 18 Aug 2015 17:05:14 +0000




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
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: