> I am to the point where I need to deploy. I was hoping that I could get my > changes merged into the main branch, but that appears impossible. I hate > the prospect of forking, but I see few alternatives. > > I hereby propose the creation of qpsmtpd-dev. > > The primary aim is merging the forks maintained by myself, Steve, Chris, > Jared, and others. I am willing to do much of the work to accomplish this. > I believe there is much to be gained by doing so, not the least of which > is saving others the pain of learning they are wasting their time trying > to improve QP in any way that doesn't fit with the unstated goals and > vision of the project. A secondary goal is to provide a development branch > of QP in which ideas can be rapidly tested, deployed, and when desired, > backported to the main branch.
I like the idea, although I'm not absolutely sure that it would accomplish everything it would mean to. A primary example to me would be the divergent methods used by various forks for supporting "per-recipient configuration". That thread demonstrates how each of our various methods made some sort of sense to the others, but were also completely unacceptable to the others for various reasons. The only solutions I can think of would be (1) maintain more than one 'aggressive development' fork, perhaps eventually letting the forks die that don't get used or hacked on much; (2) somehow support multiple options for how to accomplish the same thing, selected within the config; (3) pick a single option that is "blessed" by upstream -- forcing some to remain quite forked if the single option is not useful for them. At any rate, if a branch like this exists and someone else had the time and motivation to do the leg work of applying enhancements from the various forks to the core branch, I would most definitely ask my employers to put most of our codebase at your disposal to do this. Even if the result wasn't something we could use, and we had to remain forked... at least it would be useful to _someone_ :) -Jared