On 10/24/06 2:08 PM, "John Peacock" <[EMAIL PROTECTED]> wrote:
> [WARNING - speaking only for myself and not for the project] > > Peter Eisch wrote: >> Was there a reason the loadcheck plug-in (March 2006) didn't get included in >> 0.32? What are the requirements for predicting what plug-ins are in a >> rollup? > > As a rule, I won't automatically add a plugin to the repository unless > it is something *I* want to run (and possibly support). If there seems > to be a very useful plugin that I won't/can't run (e.g. something to do > with exim or postfix), then I will only add it to the repository if > there seems to be a groundswell of support for the addition. The wiki > is that way ===> for everything else. > I see you as a gateway to the management of the project. If the project and your participation as a manager exists to only support you as a user, then you're not looking out for the project. > We started to create a contrib folder as a place to centrally store > outside developer supported plugins. I haven't checked in everything I > wanted to (see screed below about the refusal of ISO to add 10 hours to > the normal night/day cycle). > > In the above case, after finding the thread that included that plugin > (inline, but see below), I think I probably didn't bother because it > isn't all that useful (no offense). If your system load is 7 or higher, > you have a lot more problems brewing than worrying about e-mail being > delayed. > Where was the feed back, "I don't like your default value of '7' so I adjusted the value to be '1' as a default. Committed." ? Your opinion about how an 8-way system shows load is your opinion. It is also a configurable parameter left to the user to tune. As a project maintainer, you're not asked to necessarily have all the answers, only to be available for reviewing, suggesting and supporting the project. If you refuse a patch, you owe the community the minimum of an explanation -- especially since the one you cited, loadcheck, received some reasonable accolades on the list last March. Dare I say it was a groundswell of support? > I have a distinct corporate bias, where physical servers are cheap (but > the rackspace may be the actual limiting factor). All of our incoming > e-mail is handled by extremely low-powered Cobalt RaQ servers > (equivalent to P400's) and the only time I see loads above 1 is when I > stupidly forget to tell all of the servers about a new domain > (effectively mailbombing myself). And even then, qmail is so damned > efficient I can rack up multi-megabyte mail loops without so much as > breaking a load of 4. That's including scanning with two different > virus scanners, BTW. I don't follow what your point is, sorry. > >> I recall my logging plug-in patch never got reviewed (Nov 2004). I'm happy >> to see it in current code -- I even see comments in the current code akin to >> issues that I had. It's cute and I'm mostly over it. > > One convention that most lists have is that patches are accompanied by > [PATCH] in the subject line (even if the patch is submitted as part of a > larger thread, most mail clients will cope). In several cases > (including the ones you mention here), you have included a patch without > a distinctive subject, plus when they are attached (and not inline), > they come through like this: > > --B_3184488241_38414932 > Content-type: application/octet-stream; name="syslog.patch" > Content-disposition: attachment > Content-transfer-encoding: base64 > > LS0tIHFwc210cGQub3JpZy9saWIvUXBzbXRwZC9BdXRoLnBtICAgIDIwMDQtMDktMjMgMTE6 > MTQ6NTYuMDAwMDAwMDAwIC0wNTAwCisrKyBxcHNtdHBkL2xpYi9RcHNtdHBkL0F1dGgucG0g > MjAwNC0xMS0yOCAxMToyMjowNC4wMDAwMDAwMDAgLTA2MDAKQEAgLTI2MCw3ICsyNjAsNyBA > QCBzdWIgU0FTTCB7CiAgICAgCiAgICAgICAgICAgJHNlc3Npb24tPnJlc3BvbmQoMzM0LCBl > NjQoIlVzZXJuYW1lOiIpKTsKICAgICAgICAgICAkdXNlciA9IGRlY29kZV9iYXNlNjQoPD4p > OwotICAgICAgICAgICN3YXJuKCJEZWJ1ZzogVXNlcjogJyR1c2VyJyIpOworICAgICAgICAg > ... > > meaning I have to save the file and open it before I can even see what > is included (extra steps make it less likely that I will make the effort). > I have no idea what you're referring to here. The syslog diff was short, simple and in-line. I have no idea what "syslog.patch" is as I created no such file yesterday or today. If this is from some time ago, then I apologize for using pine. It is fair to refuse patches in-line. Still, it is nice to be able to review a patch in-line so as not having to save it and view it with an editor. Regardless, I had no feedback. Ignoring contributors for whatever reason is a disservice to the project. Would providing an URL to the patch be better? This can allow a universal interface to the source/patch. Let's try! >> I've run with my own branch of 0.28 with logging as a plug-in and such for >> about two years and I'm not really sure why I came back to the current. In >> other projects submitted patches typically a thumbs-up/down response with >> some reasonable critique. Granted I don't generate a large number of >> submissions, but I wonder how many other bits of goodness have also been >> passively overlooked in this project. > > If I had to, I could document all of the washing machines and chainsaws > I'm currently juggling, but frankly I'm afraid to face that list. I'm > able to do at least some Qpsmtpd hacking on work hours, since we rely on > it so much, but I've been swamped lately. I know that the other core > developers are similarly afflicted with ETOOMUCHTODO and ENOTENOUGHTIME. > I'm sorry if that is a lame excuse, but its the only one I've got. > Same here, time is scarce. It's frustrating to have to diff a release to understand what things have changed, which haven't and figure out what's missing. I've literally diff'd every plug-in in order to get to 0.32 and my experiences are reflected in my recent email. > You posted three patches today before your rant, one of which is an > unreadable (by humans) attachment with no useful description in the > e-mail. I hope you aren't offended that I haven't immediately applied > them to the branch, but I'm just getting back from Real Life(TM) events > of an unpleasant nature (funeral) and I don't know when I'll get caught > up. That's not your fault, however. I'm just asking you to understand > that things often fall through the cracks when part-time developers are > involved. Perhaps we should point people at an RT queue rather than > relying so much on the list... Where is there an RT system for qpsmtpd? I don't know anything about any ticket system. I do know of the wiki. This is typically a location where things are documented or described, not a place where implementations are considered or evaluated. The wiki would be great if people maintaining plug-ins on the wiki could have some sort of assurance that they'd be in future releases. Sorry be being a nag. This repeated experience frustrates the elegance I enjoy in qpsmtpd for handling email. peter
