[LLVMdev] LLVM maintainers, code reviews

[Chris Lattner]

On Nov 10, 2010, at 3:58 AM, Renato Golin wrote:

> On 10 November 2010 07:27, Chris Lattner <clattner at apple.com> wrote:
>> I'd like to do more similar ones in the future, and encourage other contributors to also write other blog entries in general.
> 
> Hi Chris,
> 
> After discussing these topics in the dev meeting, I also have some input.
> 
> First, blog posts are great for communicating changes and maybe
> outlining design decisions, but these decisions change over time, and
> the posts become obsolete.

Right.  Jan was specifically asking about the "why things were decided and what the tradeoffs were", which is an inherently a "moment in time" sort of thing.  IMO, this is perfect for a blog post.  Blog posts have the advantage that they are explicitly dated.

> On the other hand, HTML documents, while
> good for release process, are hard to change and keep it up-to-date.

It's actually not any harder to change and keep up to date than anything else.  HTML pages have the advantage of showing up in a recursive grep of the sourcebase, and showing up in llvm-commits so they fall into the peer review process.

> As I said before, I'm looking for a (or writing a new) script to
> convert from the Wiki to LLVM-HTML style, and I think we should use
> the Wiki more often to keep not only the documents up-to-date, but
> also the design decisions, libraries and how-tos.

I personally really dislike the wiki.  It is more difficult to keep up to date, isn't organized well, and has no inherent power over HTML.  If you're liking the Wiki because you don't have commit access to the LLVM repo (making it harder to update the docs there) then we should grant you commit access.

I see the wiki as mainly useful for people collaboratively sketching out very early stuff.  I personally never look at the wiki and have no idea if anything on there is up to date or useful.  Looking now, I see a lot of stuff that should be folded into (for example) CodeGenerator.html after getting reviewed.

>> I personally think that there are a several key aspects of our development process that contribute to ensuring that LLVM maintains its high quality over time:
>> 
>> 1) peer review (review after commit is enough if people are willing to revert and if people actually do read the patches and speak up).
> 
> This process can take months to apply and generally impact on the
> productivity of the team that sent the patch in the first place. We
> had a few cases where the patch was never looked upon until someone
> hit the same problem and happened to find it in the llvm-commit list.

If noone responds after a week, please ping the patch.  One major issue with a distributed group of reviewers is that everyone assumes that someone else will look at it.  Pinging helps with this.

>> 3) components that are not on-by-default can be held to lower standards while they are being implemented.  If they work out and it seems like a good idea to turn them on by default, they should be given a really hard once-over.
>> 4) continuous refactoring and improvement of the code base
>> 5) being willing to throw away old stuff that no one is using or maintaining, or replace things that are broken and terrible.
> 
> IMHO, these are the three key points that are maintaining the high
> quality of LLVM and should be kept forever. As much as I disliked
> having the union type removed, it was a good design decision.
> 
> The same should go for back-ends. It's good to have a long list of
> supported back-ends, but if they start hampering the evolution of the
> rest, they should be turned off by default or even moved to a separate
> patch/project outside the main distribution.

Yes, I completely agree. The itanium and msil backends got axed not too long ago :)

> In a nutshell, the design decisions should be communicated more
> effectively, and a Wiki is a great place to start. Peer reviewers
> should communicate via the Wiki, so patchers could learn and plan
> before the next iteration and reduce the cost for everybody.

I agree, I just don't think the wiki is the right forum for it :)

-Chris