Re: LuaJIT project governance

  • From: Konstantin Osipov <kostja@xxxxxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Tue, 18 Aug 2015 16:41:26 +0300

* John Graham-Cumming <dmarc-noreply@xxxxxxxxxxxxx> [15/08/18 11:48]:

1. The test suite

Although we currently have the source code on Github we need the test suite
to be in a very robust state so that LuaJIT itself can evolve... safely. We
think the most important first step is getting the test suite in good
shape. We would like to hear from people who are specifically interested in
working on tests. Mike has said he'll help transition his test suite; who
wants to assist?

It should be the responsibility of every contributor to work on
the tests. Could you please describe more specifically what needs
to be done with the test suite? Maybe open source it first, and
then see what can be done?

We're using a lot of test automation in Tarantool, the automation
tool is a standalone repository and shared by other project
(http://github.com/tarantool/test-run). It let's you write unit
tests, functional tests, and performance tests.

I would expect LuaJIT begin with something similar - lots of OSS
project exercise a similar approach to testing. But then again, I
have no clue what the problem is with the current tests, so
perhaps this problem is already solved.

2. Deciding on a structure

Since we're moving away from having a single person in charge of the
project to a more distributed model we need to think about how to structure
it. In the past I transitioned an old project (POPFile) from being run by
me to a small team of the most dedicated volunteers. We would appreciate
the thoughts of people in this group on the best way to manage the project.

I think it should be possible for the transition phase to happen during the
next 1 or 2 months.

Full or nearly full time dedication can not last if it's not paid
for. The core team either needs to be financed, or it stops being
core.

Besides, it's still not clear what this team should do. If they
simply start accepting random patches from a "broader" community,
it's an almost guaranteed death by pollution.

It's necessary to define a roadmap and product vision first. Why
not enter Mike's own todo list into github issues and run a poll
to determine how community views their priority?

For example, Tarantool priorities/requests for LuaJIT would be (in this
order):

- never, ever, ever, crash, even when running out of memory
- address all available memory, if it requires new gc - ok

These are serious issues to us. But when they are fixed, some of
the less important but still very cool features could be worked
on:

- Lua compatibility
- extensibility. I.e. it should be easy (easier) to add support for another
language to the VM.

And of course further optimization of JIT, garbage collection,
allocation syncing it's important, but it's hard to judge on the
priorities here without seeing Mike's own roadmap and todo list.

--
http://tarantool.org - a NoSQL database in a Lua script

Other related posts: