----- Original Message ----- > Hi all, > > First, I don’t want to stir up more stuff than necessary, but I think it’s > important that we figure out which directions we should take regarding the > Lua plugins. I feel this has been handled somewhat unprofessional, and > hence, I’d like to get the discussion going. We’ll undoubtedly have to deal > with this more frequently as we gain popularity :). > > Here’s the issue, IMO at least: We now have two competing Lua plugins in the > source tree. They share nothing afaik. Neither are well documented. I guess > more code is better than less code, but I think it’s an overall confusing > story for our users. Which of the two Lua plugins should they use? Which one > do we expect developers to contribute to? And which one (if any?) gets > promoted to being stable? How would we make such a decision? Do we make such > a decision?? > > I’d like to open up the discussion here, a few things to consider are > > 1. Do we keep both? > 2. Do we try to merge them? Is there value in merging the two code bases? > 3. Or do we simply retire one of them? > 4. How did we end up like this? Did our processes break at some stage where > we ended up with two plugins for the same feature? > 5. How do we avoid future duplication like this ? I know for example both > PageSpeed and SPDY are at risk of similar duplication. > 6. How do other organizations deal with this? I’m particularly curious as to > how HTTPD deals with it.
Another question we didn't put on this list: In how far is experimental/ts_lua compatible with Lua 5.2? From what I gather, the main "blocker" here is LuaJIT. ( http://luajit.org/extensions.html#lua52 ) > Please discuss. > > — Leif > > -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
