Re: LuaJIT project governance
- From: "Vyacheslav Egorov" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "vegorov@xxxxxxxxxx" for DMARC)
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 18 Aug 2015 20:17:20 +0200
I don't believe a distributed self-governing team is going to work
for such kind of a project.
There are many notable compiler teams that work precisely this way,
look at LLVM for example - it is distributed and quite self-governed
with a well established contribution process[1] that defines what it
takes to commit a patch and what it means to *own* the code with
all associated powers and responsibilities. Of course many contributors
work on LLVM because it's their day job at big companies that rely on
LLVM as part of their infrastructure.
The main difference between LuaJIT and a project like LLVM is that we
don't have a naturally established ownership hierarchy - because Mike
being sole notable contributor is abruptly stepping back and we can't
simply take the second most active committer and say "Hey, you own it".
Instead we have to grow this ownership organically by consensus between
interested parties. We need to establish clear contribution guidelines.
- What does it take to land a patch?
- What are formal requirements (style, affected metrics, test-suite,
benchmarks)?
- Who is the gatekeeper(s)?
- What it takes to become a gatekeeper?
I don't think right now any single person except Mike would be ready to
just step ahead and say "I'm ultimately qualified to be a gatekeeper".
But I am sure we do have a group of people that can take this responsibility
jointly.
There are people on this list who did various work on LuaJIT over
the years. Some of us, ahm, *are* actually compiler engineers by trade.
I think we will not get anywhere by saying "it's so complicated and elegant" and
"we *need* a single dedicated person right away". Instead we should establish
formal contribution framework, figure out where we want to be and start moving.
[1]
http://llvm.org/docs/DeveloperPolicy.html
// Vyacheslav Egorov
On Tue, Aug 18, 2015 at 7:33 PM, Aleksey Demakov <ademakov@xxxxxxxxx> wrote:
On Tue, Aug 18, 2015 at 1:58 PM, John Graham-Cumming
<dmarc-noreply@xxxxxxxxxxxxx> wrote:
1. The test suite
Yes, it seems everybody recognises the utmost importance of
a test suite.
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.
Compilers take a lot of competence and dedication. It is a highly
specialised field. It takes a certain level of prowess in computer
science in order to read recent research papers. At the same time
ability to apply theoretical knowledge practically, writing highly
efficient code, deal with very complex and obscure bugs. And know
the source base from bottom up. And it's a full time involvement.
It is not going to work with occasional contributors making random
enhancements here and there.
Also having a community voting for one feature or another is not
going to work.
As in by now forgotten ESR's terms, bazaar is not going to work
with a compiler. Any compiler inherently is a cathedral. And the
worst kind of it. It requires very sound architecture, very strict
adherence to chosen design principles. Every change must be
thought out very thoroughly and its impact on the whole systems
and its individual parts must be measured and well understood.
All in all, to keep the project alive, it will be required to find a
replacement for Mike. Perhaps it might be two persons not one.
But these two persons will need to govern the project, contribute
most of the code, accept or reject patches, decide where to move
on. They will need to *own* the source base.
I don't believe a distributed self-governing team is going to work
for such kind of a project.
Regards,
Aleksey
Other related posts: