Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-25 Thread David Chisnall
On 25 Feb 2014, at 07:52, Baptiste Daroussin b...@freebsd.org wrote:

 On Tue, Feb 25, 2014 at 05:22:22PM +1100, Peter Jeremy wrote:
 On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin b...@freebsd.org wrote:
 On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
 I'd also query the reason for including Debian-specific code in the
 FreeBSD base.
 
 Where have you seen debian specific code?
 
 /usr/src/contrib/dma/debian - as far as I can tell, this directory is
 Debion specific.  I thought we stripped out irrelevant code from third
 party imports but looking wider, there is similarly irrelevant code in
 a variety of other contrib imports.  I'll withdraw that objection.
 
 -- 
 Peter Jeremy
 
 Have you already looked at how contrib works? who cares FYI you can also find
 some win32 specific code in there, debian packaging code, rpm spec files etc.

For the libc++ imports, we strip out the support directory, which contains 
Solaris and Win32-specific stuff.  If we end up with a support/freebsd, then 
we'll bring that in, but not support/solaris and support/win32.  That stuff is 
in the vendor branch, but it just seems polite not to make people who check out 
head get files that are never used when building FreeBSD in any configuration.

David

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-25 Thread Baptiste Daroussin
On Tue, Feb 25, 2014 at 08:49:47AM +, David Chisnall wrote:
 On 25 Feb 2014, at 07:52, Baptiste Daroussin b...@freebsd.org wrote:
 
  On Tue, Feb 25, 2014 at 05:22:22PM +1100, Peter Jeremy wrote:
  On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin b...@freebsd.org wrote:
  On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
  I'd also query the reason for including Debian-specific code in the
  FreeBSD base.
  
  Where have you seen debian specific code?
  
  /usr/src/contrib/dma/debian - as far as I can tell, this directory is
  Debion specific.  I thought we stripped out irrelevant code from third
  party imports but looking wider, there is similarly irrelevant code in
  a variety of other contrib imports.  I'll withdraw that objection.
  
  -- 
  Peter Jeremy
  
  Have you already looked at how contrib works? who cares FYI you can also 
  find
  some win32 specific code in there, debian packaging code, rpm spec files 
  etc.
 
 For the libc++ imports, we strip out the support directory, which contains 
 Solaris and Win32-specific stuff.  If we end up with a support/freebsd, then 
 we'll bring that in, but not support/solaris and support/win32.  That stuff 
 is in the vendor branch, but it just seems polite not to make people who 
 check out head get files that are never used when building FreeBSD in any 
 configuration.
 
 David

Last time I asked about those (iirc when importing byacc) I have been told that
as long as they are not huge (aka take long to checkout) we do not care about
them anymore and that simplifies mergeing from vendor.

regards,
Bapt


pgppx2fjQwf0h.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-25 Thread Warner Losh

On Feb 24, 2014, at 11:52 PM, Baptiste Daroussin b...@freebsd.org wrote:

 On Tue, Feb 25, 2014 at 05:22:22PM +1100, Peter Jeremy wrote:
 On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin b...@freebsd.org wrote:
 On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
 I'd also query the reason for including Debian-specific code in the
 FreeBSD base.
 
 Where have you seen debian specific code?
 
 /usr/src/contrib/dma/debian - as far as I can tell, this directory is
 Debion specific.  I thought we stripped out irrelevant code from third
 party imports but looking wider, there is similarly irrelevant code in
 a variety of other contrib imports.  I'll withdraw that objection.
 
 -- 
 Peter Jeremy
 
 Have you already looked at how contrib works? who cares FYI you can also find
 some win32 specific code in there, debian packaging code, rpm spec files etc.

Historically we import everything into the vendor branch, but then only import 
the FreeBSD
specific stuff into src/contrib. Sure, there are some mistakes in this, but the 
mistakes don’t
prove the point.

Warner

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-25 Thread Ed Maste
On 25 February 2014 03:49, David Chisnall thera...@freebsd.org wrote:

 For the libc++ imports, we strip out the support directory, which contains 
 Solaris and Win32-specific stuff.  If we end up with a support/freebsd, then 
 we'll bring that in, but not support/solaris and support/win32.  That stuff 
 is in the vendor branch, but it just seems polite not to make people who 
 check out head get files that are never used when building FreeBSD in any 
 configuration.

And, this is the process documented in the subversion primer in the
committers guide:

 Unlike in CVS where only the needed parts were imported into the vendor tree 
 to avoid bloating the main tree, Subversion is able to store a full 
 distribution in the vendor tree. So, import everything, but merge only what 
 is required.

We should probably drop the Unlike in CVS bit, as differences vs.
the process used in 2008 become increasingly less relevant.  Some
additional advice or examples on how to merge only what is required
will be useful too -- for instance, identifying and excluding files
added since the last vendor import that are not desired in HEAD.

That said, for the LLDB imports to date I stripped the tree before the
import to vendor/.  When I do another import after the current work is
merged to HEAD I'll import everything in vendor/, and take notes as I
do the merge to HEAD in order to update the committer's guide.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-24 Thread Peter Jeremy
On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin b...@freebsd.org wrote:
On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
 I'd also query the reason for including Debian-specific code in the
 FreeBSD base.

Where have you seen debian specific code?

/usr/src/contrib/dma/debian - as far as I can tell, this directory is
Debion specific.  I thought we stripped out irrelevant code from third
party imports but looking wider, there is similarly irrelevant code in
a variety of other contrib imports.  I'll withdraw that objection.

-- 
Peter Jeremy


pgpV04w7lNV4M.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-24 Thread Baptiste Daroussin
On Tue, Feb 25, 2014 at 05:22:22PM +1100, Peter Jeremy wrote:
 On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin b...@freebsd.org wrote:
 On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
  I'd also query the reason for including Debian-specific code in the
  FreeBSD base.
 
 Where have you seen debian specific code?
 
 /usr/src/contrib/dma/debian - as far as I can tell, this directory is
 Debion specific.  I thought we stripped out irrelevant code from third
 party imports but looking wider, there is similarly irrelevant code in
 a variety of other contrib imports.  I'll withdraw that objection.
 
 -- 
 Peter Jeremy

Have you already looked at how contrib works? who cares FYI you can also find
some win32 specific code in there, debian packaging code, rpm spec files etc.

regards,
Bapt


pgpvwQ64M00z1.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-22 Thread Peter Jeremy
On 2014-Feb-21 07:26:49 +, Baptiste Daroussin b...@freebsd.org wrote:
Log:
  Import Dragonfly Mail Agent into base system

I would like to suggest that 'dma' is a _really_ bad name for any
utility.  As has been mentioned, 'DMA' has had a well-entrenched
meaning for decades and overloading to also refer to a MTA is not
going to end well.

I'd also query the reason for including Debian-specific code in the
FreeBSD base.

-- 
Peter Jeremy


pgpmzMVf62Z1f.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-22 Thread Baptiste Daroussin
On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
 On 2014-Feb-21 07:26:49 +, Baptiste Daroussin b...@freebsd.org wrote:
 Log:
   Import Dragonfly Mail Agent into base system
 
 I would like to suggest that 'dma' is a _really_ bad name for any
 utility.  As has been mentioned, 'DMA' has had a well-entrenched
 meaning for decades and overloading to also refer to a MTA is not
 going to end well.
 
 I'd also query the reason for including Debian-specific code in the
 FreeBSD base.
 
 -- 
 Peter Jeremy

Where have you seen debian specific code?

regards,
Bapt


pgp39N1WRIox4.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-22 Thread Baptiste Daroussin
On Fri, Feb 21, 2014 at 10:31:07AM -0700, Ian Lepore wrote:
 On Fri, 2014-02-21 at 07:26 +, Baptiste Daroussin wrote:
  Author: bapt
  Date: Fri Feb 21 07:26:49 2014
  New Revision: 262282
  URL: http://svnweb.freebsd.org/changeset/base/262282
  
  Log:
Import Dragonfly Mail Agent into base system

It is a small and lightweight Mail Transport Agent.
It accepts mails from locally installed Mail User Agents (MUA) and 
  delivers the
mails either locally or to a remote destination. Remote delivery includes
several features like TLS/SSL support, SMTP authentication and NULLCLIENT.

Make dma conditional to new WITHOUT_DMA option and make it respect 
  WITHOUT_MAIL

Reviewed by:  peter
Discussed with:   emaste, bz, peter
  
 
 This seems to be causing redundant redeclaration of yylval tinderbox
 failures.

Already fixed, few hours after the import
 
 Also, IMO, WITHOUT_DMA is a horrible build option name.  DMA has a
 pretty universally understood meaning in computing, and anyone seeing
 that as a build option is likely to assume that meaning (and freak out a
 bit) rather than looking in a manpage for an alternative meaning.  How
 about WITHOUT_DMAGENT?
 
Good idea, done

regards,
Bapt


pgpWkRYPCY7w3.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-22 Thread Nikolai Lifanov

On 2014-02-22 07:14, Baptiste Daroussin wrote:

On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
On 2014-Feb-21 07:26:49 +, Baptiste Daroussin b...@freebsd.org 
wrote:

Log:
  Import Dragonfly Mail Agent into base system

I would like to suggest that 'dma' is a _really_ bad name for any
utility.  As has been mentioned, 'DMA' has had a well-entrenched
meaning for decades and overloading to also refer to a MTA is not
going to end well.

I'd also query the reason for including Debian-specific code in the
FreeBSD base.

--
Peter Jeremy


Where have you seen debian specific code?

regards,
Bapt


It's the whole /head/contrib/dma/debian directory. Debian project is 
considering replacing Sendmail with DMA, and this contains deb package 
glue for dma and dma-migrate (Debian-specific transition plug).


It can probably just be svn rm-ed from FreeBSD src but kept in the 
vendor import.


- Nikolai Lifanov
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Steve Kargl
On Fri, Feb 21, 2014 at 07:26:49AM +, Baptiste Daroussin wrote:
 Author: bapt
 Date: Fri Feb 21 07:26:49 2014
 New Revision: 262282
 URL: http://svnweb.freebsd.org/changeset/base/262282
 
 Log:
   Import Dragonfly Mail Agent into base system
   
   It is a small and lightweight Mail Transport Agent.
   It accepts mails from locally installed Mail User Agents (MUA) and delivers 
 the
   mails either locally or to a remote destination. Remote delivery includes
   several features like TLS/SSL support, SMTP authentication and NULLCLIENT.
   
   Make dma conditional to new WITHOUT_DMA option and make it respect 
 WITHOUT_MAIL
   
   Reviewed by:peter
   Discussed with: emaste, bz, peter

Why?  There is /usr/ports/mail/dma.

-- 
steve
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Baptiste Daroussin
On Fri, Feb 21, 2014 at 08:01:44AM -0800, Steve Kargl wrote:
 On Fri, Feb 21, 2014 at 07:26:49AM +, Baptiste Daroussin wrote:
  Author: bapt
  Date: Fri Feb 21 07:26:49 2014
  New Revision: 262282
  URL: http://svnweb.freebsd.org/changeset/base/262282
  
  Log:
Import Dragonfly Mail Agent into base system

It is a small and lightweight Mail Transport Agent.
It accepts mails from locally installed Mail User Agents (MUA) and 
  delivers the
mails either locally or to a remote destination. Remote delivery includes
several features like TLS/SSL support, SMTP authentication and NULLCLIENT.

Make dma conditional to new WITHOUT_DMA option and make it respect 
  WITHOUT_MAIL

Reviewed by:  peter
Discussed with:   emaste, bz, peter
 
 Why?  There is /usr/ports/mail/dma.
 
Because there are lot of case where you do not need a full smtp server in base 
but just
be able to deliver locally and/or relay mails outside, dma is very good for that
purpose.

regards,
Bapt


pgpf81h9XF5dC.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Rui Paulo
On 21 Feb 2014, at 08:32, Baptiste Daroussin b...@freebsd.org wrote:

 On Fri, Feb 21, 2014 at 08:01:44AM -0800, Steve Kargl wrote:
 On Fri, Feb 21, 2014 at 07:26:49AM +, Baptiste Daroussin wrote:
 Author: bapt
 Date: Fri Feb 21 07:26:49 2014
 New Revision: 262282
 URL: http://svnweb.freebsd.org/changeset/base/262282
 
 Log:
  Import Dragonfly Mail Agent into base system
 
  It is a small and lightweight Mail Transport Agent.
  It accepts mails from locally installed Mail User Agents (MUA) and 
 delivers the
  mails either locally or to a remote destination. Remote delivery includes
  several features like TLS/SSL support, SMTP authentication and NULLCLIENT.
 
  Make dma conditional to new WITHOUT_DMA option and make it respect 
 WITHOUT_MAIL
 
  Reviewed by:   peter
  Discussed with:emaste, bz, peter
 
 Why?  There is /usr/ports/mail/dma.
 
 Because there are lot of case where you do not need a full smtp server in 
 base but just
 be able to deliver locally and/or relay mails outside, dma is very good for 
 that
 purpose.

I agree with this notion and to be honest the next step should be to remove 
sendmail from the base system.

--
Rui Paulo



___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Ian Lepore
On Fri, 2014-02-21 at 07:26 +, Baptiste Daroussin wrote:
 Author: bapt
 Date: Fri Feb 21 07:26:49 2014
 New Revision: 262282
 URL: http://svnweb.freebsd.org/changeset/base/262282
 
 Log:
   Import Dragonfly Mail Agent into base system
   
   It is a small and lightweight Mail Transport Agent.
   It accepts mails from locally installed Mail User Agents (MUA) and delivers 
 the
   mails either locally or to a remote destination. Remote delivery includes
   several features like TLS/SSL support, SMTP authentication and NULLCLIENT.
   
   Make dma conditional to new WITHOUT_DMA option and make it respect 
 WITHOUT_MAIL
   
   Reviewed by:peter
   Discussed with: emaste, bz, peter
 

This seems to be causing redundant redeclaration of yylval tinderbox
failures.

Also, IMO, WITHOUT_DMA is a horrible build option name.  DMA has a
pretty universally understood meaning in computing, and anyone seeing
that as a build option is likely to assume that meaning (and freak out a
bit) rather than looking in a manpage for an alternative meaning.  How
about WITHOUT_DMAGENT?

-- Ian


___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Steve Kargl
On Fri, Feb 21, 2014 at 05:32:18PM +0100, Baptiste Daroussin wrote:
 On Fri, Feb 21, 2014 at 08:01:44AM -0800, Steve Kargl wrote:
  On Fri, Feb 21, 2014 at 07:26:49AM +, Baptiste Daroussin wrote:
   Author: bapt
   Date: Fri Feb 21 07:26:49 2014
   New Revision: 262282
   URL: http://svnweb.freebsd.org/changeset/base/262282
   
   Log:
 Import Dragonfly Mail Agent into base system
 
  
  Why?  There is /usr/ports/mail/dma.
  
 Because there are lot of case where you do not need a full smtp
 server in base but just be able to deliver locally and/or relay
 mails outside, dma is very good for that purpose.

As there is already a full stmp server in base, your argument is
fairly weak.  Yes, I know there is now going to be a small, but
vocal group of people, demanding the removal of sendmail.  So,
let's remove both sendmail and dma, and then let the user choose
an agent from ports/mail.

-- 
steve
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Baptiste Daroussin
On Fri, Feb 21, 2014 at 09:32:04AM -0800, Steve Kargl wrote:
 On Fri, Feb 21, 2014 at 05:32:18PM +0100, Baptiste Daroussin wrote:
  On Fri, Feb 21, 2014 at 08:01:44AM -0800, Steve Kargl wrote:
   On Fri, Feb 21, 2014 at 07:26:49AM +, Baptiste Daroussin wrote:
Author: bapt
Date: Fri Feb 21 07:26:49 2014
New Revision: 262282
URL: http://svnweb.freebsd.org/changeset/base/262282

Log:
  Import Dragonfly Mail Agent into base system
  
   
   Why?  There is /usr/ports/mail/dma.
   
  Because there are lot of case where you do not need a full smtp
  server in base but just be able to deliver locally and/or relay
  mails outside, dma is very good for that purpose.
 
 As there is already a full stmp server in base, your argument is
 fairly weak.  Yes, I know there is now going to be a small, but
 vocal group of people, demanding the removal of sendmail.  So,
 let's remove both sendmail and dma, and then let the user choose
 an agent from ports/mail.
 
Some tools in the base system like cron do expect a working sendmail(1), so we 
need
a working sendmail(1) in base

regards,
Bapt


pgpy3Sqkc1own.pgp
Description: PGP signature


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Steve Kargl
On Fri, Feb 21, 2014 at 06:41:51PM +0100, Baptiste Daroussin wrote:
 On Fri, Feb 21, 2014 at 09:32:04AM -0800, Steve Kargl wrote:
  On Fri, Feb 21, 2014 at 05:32:18PM +0100, Baptiste Daroussin wrote:
   On Fri, Feb 21, 2014 at 08:01:44AM -0800, Steve Kargl wrote:
On Fri, Feb 21, 2014 at 07:26:49AM +, Baptiste Daroussin wrote:
 Author: bapt
 Date: Fri Feb 21 07:26:49 2014
 New Revision: 262282
 URL: http://svnweb.freebsd.org/changeset/base/262282
 
 Log:
   Import Dragonfly Mail Agent into base system

Why?  There is /usr/ports/mail/dma.

   Because there are lot of case where you do not need a full smtp
   server in base but just be able to deliver locally and/or relay
   mails outside, dma is very good for that purpose.
  
  As there is already a full stmp server in base, your argument is
  fairly weak.  Yes, I know there is now going to be a small, but
  vocal group of people, demanding the removal of sendmail.  So,
  let's remove both sendmail and dma, and then let the user choose
  an agent from ports/mail.
  
 Some tools in the base system like cron do expect a working
 sendmail(1), so we need a working sendmail(1) in base
 

That's easily fixed by adding MAILTO= to /etc/crontab.

-- 
Steve
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Benjamin Kaduk
On Fri, Feb 21, 2014 at 12:38 PM, Baptiste Daroussin b...@freebsd.orgwrote:

 On Fri, Feb 21, 2014 at 09:07:23AM -0800, Rui Paulo wrote:
  On 21 Feb 2014, at 08:32, Baptiste Daroussin b...@freebsd.org wrote:
 
   On Fri, Feb 21, 2014 at 08:01:44AM -0800, Steve Kargl wrote:
   Why?  There is /usr/ports/mail/dma.
  
   Because there are lot of case where you do not need a full smtp server
 in base but just
   be able to deliver locally and/or relay mails outside, dma is very
 good for that
   purpose.
 
  I agree with this notion and to be honest the next step should be to
 remove sendmail from the base system.
 
 I'm strongly support that idea.


Baptiste,

I appreciate that you've put a lot of thought and effort into this work,
and indeed you put in Herculean amounts of effort for the project for which
we should all be grateful.
In particular, the addition of dma is listed as having been discussed with
three other committers, and represents the potential for a very significant
change in the base system that we present to our users.  As such, I think
that it would be beneficial for all parties, if a summary of the reasoning
behind this decision could be presented to us.  A quick, single-sentence
reply does *not* serve this purpose; in fact it is actively working against
this purpose, by seeming to brush off the concerns of others without proper
consideration.

I understand that your time is precious.  So is the time of everyone on
this list, and a small investment in a well-written description of the
reasoning for this change should be able to prevent a long email thread
that would waste a lot of many peoples' time.  It would probably be best
for this description to go to -current, instead of the svn commit lists.

Thank you,

Ben
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil

2014-02-21 Thread Baptiste Daroussin
On Fri, Feb 21, 2014 at 12:56:29PM -0500, Benjamin Kaduk wrote:
 On Fri, Feb 21, 2014 at 12:38 PM, Baptiste Daroussin b...@freebsd.orgwrote:
 
  On Fri, Feb 21, 2014 at 09:07:23AM -0800, Rui Paulo wrote:
   On 21 Feb 2014, at 08:32, Baptiste Daroussin b...@freebsd.org wrote:
  
On Fri, Feb 21, 2014 at 08:01:44AM -0800, Steve Kargl wrote:
Why?  There is /usr/ports/mail/dma.
   
Because there are lot of case where you do not need a full smtp server
  in base but just
be able to deliver locally and/or relay mails outside, dma is very
  good for that
purpose.
  
   I agree with this notion and to be honest the next step should be to
  remove sendmail from the base system.
  
  I'm strongly support that idea.
 
 
 Baptiste,
 
 I appreciate that you've put a lot of thought and effort into this work,
 and indeed you put in Herculean amounts of effort for the project for which
 we should all be grateful.
 In particular, the addition of dma is listed as having been discussed with
 three other committers, and represents the potential for a very significant
 change in the base system that we present to our users.  As such, I think
 that it would be beneficial for all parties, if a summary of the reasoning
 behind this decision could be presented to us.  A quick, single-sentence
 reply does *not* serve this purpose; in fact it is actively working against
 this purpose, by seeming to brush off the concerns of others without proper
 consideration.
 
 I understand that your time is precious.  So is the time of everyone on
 this list, and a small investment in a well-written description of the
 reasoning for this change should be able to prevent a long email thread
 that would waste a lot of many peoples' time.  It would probably be best
 for this description to go to -current, instead of the svn commit lists.
 

You are right I ll prepare a mail describing all that to current@.

regards,
Bapt


pgpQA9jnFCBO9.pgp
Description: PGP signature