On Jun 2, 2012, at 11:22 AM, Jared Johnson wrote: >>> Why hasn't your rejected idea been worked into qpsmtpd yet? >> >> Because I came to view qpsmtpd in a different way than many >> do (many view it as a service with useful plugins which they >> can deploy, use, and enjoy). Instead I view it more as a >> framework for rejecting/processing/handling mail that happens >> to come with some nice sample code. > > I'd lean toward agreeing with this take on things. It's difficult steer > changes to the core set of QP plugins because so many people need > different things. We've wound up creating a huge fork of all the plugins
Having a greatly divergent fork is exactly what I want to avoid. But I understand. It has taken me far more work to get changes committed than it has to make them. :-( > (and to some extent forked QP libs in support of these plugins), and > although we've submitted some of these changes back, many of them wouldn't > make sense for all of QP's intended audience. It might be *possible* to > fashion things to be flexible enough or with conservative enough defaults > that it would work for everyone, but unfortunately once we get things > working for ourselves we don't currently have the resources to work much > further on things. Again, that's where I don't want to be. With a fork so diverged that I no longer have the time or inclination to merge back. But this problem of having multiple developers implementing the same or similar features on the same project multiple times sure seems antithetical to "social coding." It suggests that something in the development model is not working well. > I idly wonder if it might be worthwhile to offer some sort of repository > of whole plugin frameworks that users and/or developers looking for idea > could pull in as a whole in order to use them together. I think what qpsmtpd needs is a development branch where developers can actually work on qpsmtpd. Matt
