Re: Conflicts between developers and policy
'From Bill Leach <[EMAIL PROTECTED]>' Manoj; The 'Social Contract' and the 'DFSG' are indeed goal statements. However, they are goal statements of a very imprecise nature. They are not 'working documents' they are rather more like 'lofty ideals'. Ideals that don't necessarily mean precisely the same things to different people EVEN when different people 'enthusiastically pledge their support' and make claims as to how these documents 'spell out' common goals. The various 'technical guidlines' indeed ARE the 'working documents' of the Debian goals. They deal with goal issues that are both explicit and IMPLICIT in the Debian project. I feel that this whole discussion has been fraught with 'missunderstanding'. My personal view of your position for example is that while you have at times made statements that 'sounded to me to be very autocratic' (and I am sure from some of the responses that you have received that they sounded that way to others as well); and yet overall the impression that I have is that you do NOT view the 'guidelines' as an 'inflexible straightjacket' upon developers. I further believe that the basis for your statements is two fold: 1) Never publicly 'belittle' the developer governing documents. [Probably because to do so would tend to give the impression that ignoring the conflicts and problems that such documents have and do attempt to address would ultimately be a disaster for the project] 2) 'Regulations' in the governing documents ARE NOT absolutes and just as is true for any other aspect of the project, they are subject to revision and (hopefully), improvement. a. It is highly unlikely that ANY one developer will know ALL of the reasons why a particular decision was made. b. It is even less likely that a single developer will know all of the potential impacts that would be caused by a change. c. Only by first rigorously attempting to comply with 'guidlelines', including seeking opinions of other developers and then still finding that existing policy is an impossible or at least unreasonable restriction will any meaningful improvement to the regulating documents occur. Thus, there is a hugh difference between a developer 'violating' policy AND filing a bug against the policy and one that quietly 'just does their own thing'. I personally would suggest that a developer be allowed to 'violate' policy after attempting to follow policy has failed but then be expected to be cooperative in 'hammering out' a new policy as well as changing the package (if required) to comply with the final decision. I doubt that it is a real good idea to become too specific and too detailed in policy. An obvious problem of course is in deciding what is 'too' and what is 'not enough'. It is probably almost as important to be sure that every requirement that is imposed is indeed necessary as well as to ensure that what is required is no more than is necessary. Since much of the policy has evolved, the 'reasons behind the reasons' may never have been addressed. Within a project like Debian there are many 'standards' that have to be set ONLY because chaos would ensue otherwise. My Brit friends continually remind me of the classic example. There is essentially nothing sacred about driving on the 'right' side of the road but evenyone on particular road had better agree on the 'standard'. On Sat, May 02, 1998 at 02:31:04PM -0500, Manoj Srivastava wrote: > Hi, > >>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes: > > Raul> The point is: we've got a wide variety of goals; debian-policy > Raul> is a fleshed-out statement of those goals. > > I think you are taking policy where it should not go. The > Social contract, the DFSG, and the ilk are a statement of our > goals, the constitution represents the rights and duties of the > entities in the project, and the Policy documents list the dos and > don't of designing and implementing debian packages. > > This is the first I have heard of our Policy documents being > goals, and I disagree. > > manoj > -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MDA's was: Yet another Linux distribution! :-)
'From Bill Leach <[EMAIL PROTECTED]>' Sendmail configuration is tough but it is also the best documented MTA bar none! The O'Reliey book alone on sendmail is 2 1/5" thick. Probably close to everything that has ever been done with mail has been done with sendmail (and possibly some things that can only be done with sendmail -- and NO I don't know of any examples personally). Exim is also a good MTA. It is easier to configure than sendmail, supposedly faster (though I don't consider that a concern for dailup use - the line itself is far too limiting for that to matter). Like the 'conventional' sendmail distribution though, the exim.deb appears to me to be almost hopelessly confusing and inadequate as far as the dailup user is concerned. And by 'dailup user' I mean a user that uses a typical personal account with an ISP and may or may not have a local area network. I will take a look at sendmail because of Manoj's remarks since the only significant disadvantage to sendmail that I could see is that it can be a real tough one to set up properly (if you are a continuously connected mail server then it is almost a 'snap' to set up using the conventional sendmail configuration). I don't consider myself to be stupid but the e-mail issue is really raising doubts... It should not require days of study of various documents, man pages, HOWTOs, example configuration files, etc. just to get an email system that: 1) Places a vaild (to the ISP) From header on all internet bound mail (no matter what the user's local network name might be). 2) Send all 'outbound' mail to a smarthost depending upon which ISP is in use. I realize that #1 is not really the MTA's 'responsibility' but it is the logical place for this to be accomplished since any place else in the 'chain' is not unique (ie: there are too many mail composing software packages, most (AFAIK) won't let you muck with the headers (and really shouldn't). #2 IS the responsibility of the MTA but AFAIK none were designed with the idea that you might have different 'smarthosts' as different times. -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
'From Bill Leach <[EMAIL PROTECTED]>' I think I'm confused too thought that is not such an unusual state latesly... Fetchmail IS POP (or IMAP and somthing else but definately NOT smtp) for __getting__ the mail. It IS also smtp for handing the mail to the machine that it is running on (though I guess that with the --mda procmail switch it probably uses pipes instead of port 25). Again, though I will willingly admit to not knowing lots of stuff but what ISPs _receive_ mail from a user without using smtp to do it (other than the completely proprietary systems such as AOL, Juno, etc.)? On Sat, May 02, 1998 at 11:59:39PM +0100, Mark Baker wrote: > On Sat, May 02, 1998 at 10:52:48PM +, Rev. Joseph Carter wrote: > > > > But this is aimed at dialup users! You don't want a send-only MTA, as > > > dialup > > > users presumably want to store their mail locally. > > > > Their mail isn't gonna get delivered by smtp > > No? I know several dialup ISPs that do provide SMTP, including one with > 170,000 customers. > > > unless maybe fetchmail delivers it by smtp. > > Exactly: surely everyone who uses an inferior ISP is going to run fetchmail > instead? So everyone wants to run an MTA locally. The alternative would be > to force people to use an MUA with POP built-in, which is far from ideal, > because that doesn't include some very nice MUAs, and requires you to go > online at the time you read your mail rather than setting up a cron job, > -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fetchmail/procmail was: Yet another Linux distribution! :-)
'From Bill Leach <[EMAIL PROTECTED]>' I don't think so Jason... Fetchmail is also pretty robust about mail handling but it expect whatever it 'hands a message too' to do something with the message. I won't even pretend to know the nature of the problems but I suspect that it deals with the idea that the MTA's all honor the "SIZE" message whereas I don't believe that Procmail does. Fetchmail's problem then is that once I has 'the ok' from Procmail to transfer the message, there is nothing that fetchmail can do if procmail later fails. Again, if I understand this correctly, exim, sendmail, smail, etc. still have a directory that they have spooled the 'to be delivered mail to' so that the mail is not lost whereas Procmail either delivers the message or it is lost since it did not come from a file on disk. I think that the fetchmail/procmail 'thing' is a case where neither program is designed for what is being done by the other. Fetchmail is designed to pass off mail to an MDA that checks that it should receive the mail and that it has sufficient disk space to store the mail BEFORE it tells fetchmail 'ok give it to me'. Procmail OTOH was designed to take mail that is presumably already stored on the system's HD and process that mail for delivery. BTW, the only program that has lost mail on my system has been Procmail (configuration error on my part of course but the mail was lost). Fetchmail has never lost a message, exim has never lost a message. I do still use Procmail however as it is a great program, you just have to be aware that if you tell it to do something impossible your mail or part of you mail ends up in /dev/null. > > On Sat, May 02, 1998 at 09:08:07PM -0600, Jason Gunthorpe wrote: > > > > On Sat, 2 May 1998, Raul Miller wrote: > > > > > Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > > > > You can configure fetchmail to run through procmail. > > > > > > Er, the fetchmail FAQ implies that if you use -mda procmail you can lose > > > mail to resource exhaustion. > > > > Then fetchmail is at fault, procmail will not drop your email if your disk > > is full, it will give an error code. > > > > Jason -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MDA's was: Yet another Linux distribution! :-)
'From Bill Leach <[EMAIL PROTECTED]>' I don't see why either but it sure has not been done. [snip] > I don't see why it shouldn't be possible to make configuration just > as easy for a dial-up case. We need to figure out what the typical dial-up > cases look like and integrate them into the configuration as well. > [snip] > >1) Places a vaild (to the ISP) From header on all internet bound mail > >(no matter what the user's local network name might be). > > > >2) Send all 'outbound' mail to a smarthost depending upon which ISP > >is in use. > > > >I realize that #1 is not really the MTA's 'responsibility' but it is the > >logical place for this to be accomplished since any place else in the > >'chain' is not unique (ie: there are too many mail composing software > >packages, most (AFAIK) won't let you muck with the headers (and really > >shouldn't). > > > >#2 IS the responsibility of the MTA but AFAIK none were designed with the > >idea that you might have different 'smarthosts' as different times. > > #1 is simple to do, though it probably needs a few variants, depeding on > whether the machine serves an entire domain or just a sigle account/email > address. > > #2 Might be doable using sendmail's smarthost "MX" feature (setting > the smarthost to a list of colon-separated hosts). With a bit of hacking > it shouldn't be hard to have it read it from a file on each delivery > attempt. > > Regards, > /Anders #1 may be simple to do (and I know that I did do it once) but if you notice, my from header is '[EMAIL PROTECTED]' and that name and user are unknown outside my own LAN. Now I will admit to having been guilty of not making notes about what I did when I managed to set that up properly before. Best I can tell, the configuration that I presently have for exim should 'nuke' that header and replace it -- but it obviously does not. AFAIK, #2 is NOT doable using any normal feature of sendmail, smail, or exim. These mailers are designed to be 'pretty damned smart' about figuring out what mail server to send to based upon the specifics of the particular message but have no concept of possibly different internet connections. > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fetchmail/procmail was: Yet another Linux distribution! :-)
'From Bill Leach <[EMAIL PROTECTED]>' On Sat, May 02, 1998 at 11:39:44PM -0600, Jason Gunthorpe wrote: > > On Sun, 3 May 1998 [EMAIL PROTECTED] wrote: > > > 'From Bill Leach <[EMAIL PROTECTED]>' > > > > I don't think so Jason... > > > > Fetchmail is also pretty robust about mail handling but it expect whatever > > it 'hands a message too' to do something with the message. > > > > I won't even pretend to know the nature of the problems but I suspect that > > it deals with the idea that the MTA's all honor the "SIZE" message whereas > > I don't believe that Procmail does. Fetchmail's problem then is that once > > I has 'the ok' from Procmail to transfer the message, there is nothing that > > fetchmail can do if procmail later fails. > > No, it should always check the return code of the subprocess (if it is > using procmail) before it erases the message from the server. If the > return code is bad it should never erase the message. We are probably wasting everyone's time now by not looking to see just what fetchmail/procmail interface actually is... As I understand it, the fetchmail/procmail interface is a kludge. Fetchmail is intended and designed to work with smtp for delivery. Procmail OTOH doesn't know anything about smtp. What sort of error code is procmail going to give to fetchmail and how is fetchmail to receive this code? -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fetchmail/procmail was: Yet another Linux distribution! :-)
'From Bill Leach <[EMAIL PROTECTED]>' On Mon, May 04, 1998 at 04:19:31AM +, Rev. Joseph Carter wrote: > On Sun, May 03, 1998 at 11:40:45PM -0400, [EMAIL PROTECTED] wrote: > > We are probably wasting everyone's time now by not looking to see just what > > fetchmail/procmail interface actually is... > > > > As I understand it, the fetchmail/procmail interface is a kludge. > > No, actually it's a pipe.. => Well yes, but a pipe IS a kludge to fetchmail Damn, missed :-) > > Fetchmail > > is intended and designed to work with smtp for delivery. Procmail OTOH > > doesn't know anything about smtp. What sort of error code is procmail > > going to give to fetchmail and how is fetchmail to receive this code? > > If procmail gives errors the message is not deleted from the POP server. > I've tested this (without meaning to) myself.. That is interesting. Then maybe the assertion that lost mail with a fetchmail/procmail combination is not true (ie: the reported loss was NOT do to the fetchmail/procmail interface) -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
