trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shu Kit Chan <chanshu...@gmail.com>
Subject Re: experimental/lua vs experimental/ts_lua
Date Tue, 17 Dec 2013 16:59:57 GMT
Hi,

For months, I have been trying to look for better ways to write simple
plugins. And so the existing experimental/lua is a good starting point. But
upon further investigation, it is really experimental and with not much
features. I think it is more a skeleton code for us to add on. About a few
weeks back, i read a chinese blog post and learned about the
experimental/ts_lua plugin. It is a functional and rather complete plugin.
So i worked to get it added to the source tree.

1) I don't think we should keep both.
2) It will be hard to merge them, i think.
3) There is very little that experimental/lua can do that
experimental/ts_lua cannot. I am thinking of adding some more functionality
there in experimental/ts_lua before suggesting to retire experimental/lua
4) I was more hoping to put the code in experimental directory to stir
interests in discussions in the first place, thinking that "experimental"
may be a less intrusive place to try things out.
5) Perhaps we can have more guidelines related to plugins and experimental
plugins if we don't already have one. That may help. e.g. What's the
criteria to put stuff in experimental directory? What's the criteria to
promote it out of "experimental"? I read some discussions in these topics
but perhaps we can have a better guidelines.

Thanks. That's my two cents. I will be happy to help and contribute to whip
the whole situation in a better shape.

Kit


On Tue, Dec 17, 2013 at 8:31 AM, Leif Hedstrom <zwoop@apache.org> wrote:

> 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.
>
>
> Please discuss.
>
> — Leif
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message