[prev in list] [next in list] [prev in thread] [next in thread]
List: opensmtpd-misc
Subject: Re: OpenSMTPD Extras and libasr
From: "Barbier, Jason" <jabarb () serversave ! us>
Date: 2014-11-21 18:48:15
Message-ID: CAFTNjvH00y4hDkOUtTcAf+qXPYrK7TbrYeQR9p05Yf0mLu7s4w () mail ! gmail ! com
[Download RAW message or body]
What about having a separate branch for your each wip item or a wip branch
with a ticket linked to the branch with a to do to make the items prod.
On Nov 21, 2014 10:13 AM, "Gilles Chehade" <gilles@poolp.org> wrote:
> On Thu, Nov 13, 2014 at 04:36:09PM +0100, Gilles Chehade wrote:
> > On Thu, Nov 13, 2014 at 03:59:19PM +0100, Emmanuel Vadot wrote:
> > >
> > > Hello list,
> > >
> > > Currently the build system for the extras (table, filters etc ...) is
> not really intelligent.
> > > It does not check is the required libs or interpreters in present on
> the machine and doesn't even use the correct path for the libs.
> > > This is a problem for user and packagers since now it's not possible
> to easily provide an OpenSMTPD package with mysql for example.
> > >
> > > After talking to gilles@ in private on IRC we tought on possibly
> make the following changes :
> > >
> > > 1) Each extras will provides it's own configure script
> > > 2) Each configure scripts will correctly check its dependancies
> > > 3) All extras will be shipped in a single archive
> > > 4) Maybe have just one branch in the git since OpenBSD doesn't ship
> with smtpd extras.
> > >
> > > For 1, it will simply keep the configure as simple as it need to be
> > >
> > > For 2, well ...
> > >
> > > For 3, I know that the FreeBSD ports infrastructures can handle this
> correctly (having multiple ports that depends on one distfiles, the Qt
> ports for plugins does that). Is there some ports/packages infrastructure
> that can't ?
> > >
> >
> > To make it more clear, right now people tend to clone / fetch the entire
> > extras just to grab that one bit they need.
> >
> > The idea is to make each extra individual so that while they are all in
> > the same repository, one can package a specific extra for his system so
> > ultimately you can: pkg_add opensmtpd-filter-dkim, ...
> >
> > [...]
> >
> > At the moment, extras are not correctly integrated, it took us quite some
> > effort to split them out of the smtpd tree but we have not yet worked on
> > how to "easily" plug them.
> >
> > What I suggested with regard to the "just one branch" idea, is the
> > following:
> >
> > smtpd is developed on OpenBSD and "fixed" for portability using the
> > compat glue, so we need two branches to avoid the compat glue ending
> > in the openbsd tree where it's not needed.
> >
> > -extras are different: they are developped on different systems by
> > non-openbsd developers, they can have any dependencies and are supposed
> > to be the same code on OpenBSD and other systems are they communicate
> > with smtpd through a common API.
> >
> > therefore my idea was to drop the master/portable difference for extras
> > and have a single branch for both.
> >
>
> ok, so work has officially started in this area.
>
> Tonight I will focus on merging the portable and master branch together,
> then later the autotools glue will be added appropriately.
>
> One idea stepped in my mind and I would like to know what you guys think
> about it:
>
> There is currently no separation between extras that are considered prod
> ready and extras that are considered work in progress. Also, some of the
> extras which are considered prod ready are undocumented which isn't good
> and not to our standards.
>
> I suggest that we add a wip/ directory in -extras with the same layout
> and while we accept all contributions to wip/, only those documented and
> production ready gets moved out of wip/
>
> what do you think ?
>
>
> --
> Gilles Chehade
>
> https://www.poolp.org @poolpOrg
>
> --
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscribe@opensmtpd.org
>
>
[Attachment #3 (text/html)]
<p dir="ltr">What about having a separate branch for your each wip item or a wip \
branch with a ticket linked to the branch with a to do to make the items prod. </p> \
<div class="gmail_quote">On Nov 21, 2014 10:13 AM, "Gilles Chehade" <<a \
href="mailto:gilles@poolp.org">gilles@poolp.org</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 13, 2014 at 04:36:09PM \
+0100, Gilles Chehade wrote:<br> > On Thu, Nov 13, 2014 at 03:59:19PM +0100, \
Emmanuel Vadot wrote:<br> > ><br>
> > Hello list,<br>
> ><br>
> > Currently the build system for the extras (table, filters etc ...) is not \
really intelligent.<br> > > It does not check is the required libs or \
interpreters in present on the machine and doesn't even use the correct path for \
the libs.<br> > > This is a problem for user and packagers since now it's \
not possible to easily provide an OpenSMTPD package with mysql for example.<br> > \
><br> > > After talking to gilles@ in private on IRC we tought on possibly \
make the following changes :<br> > ><br>
> > 1) Each extras will provides it's own configure script<br>
> > 2) Each configure scripts will correctly check its dependancies<br>
> > 3) All extras will be shipped in a single archive<br>
> > 4) Maybe have just one branch in the git since OpenBSD doesn't ship \
with smtpd extras.<br> > ><br>
> > For 1, it will simply keep the configure as simple as it need to be<br>
> ><br>
> > For 2, well ...<br>
> ><br>
> > For 3, I know that the FreeBSD ports infrastructures can handle this \
correctly (having multiple ports that depends on one distfiles, the Qt ports for \
plugins does that). Is there some ports/packages infrastructure that can't ?<br> \
> ><br> ><br>
> To make it more clear, right now people tend to clone / fetch the entire<br>
> extras just to grab that one bit they need.<br>
><br>
> The idea is to make each extra individual so that while they are all in<br>
> the same repository, one can package a specific extra for his system so<br>
> ultimately you can: pkg_add opensmtpd-filter-dkim, ...<br>
><br>
> [...]<br>
><br>
> At the moment, extras are not correctly integrated, it took us quite some<br>
> effort to split them out of the smtpd tree but we have not yet worked on<br>
> how to "easily" plug them.<br>
><br>
> What I suggested with regard to the "just one branch" idea, is the<br>
> following:<br>
><br>
> smtpd is developed on OpenBSD and "fixed" for portability using \
the<br> > compat glue, so we need two branches to avoid the compat glue ending<br>
> in the openbsd tree where it's not needed.<br>
><br>
> -extras are different: they are developped on different systems by<br>
> non-openbsd developers, they can have any dependencies and are supposed<br>
> to be the same code on OpenBSD and other systems are they communicate<br>
> with smtpd through a common API.<br>
><br>
> therefore my idea was to drop the master/portable difference for extras<br>
> and have a single branch for both.<br>
><br>
<br>
ok, so work has officially started in this area.<br>
<br>
Tonight I will focus on merging the portable and master branch together,<br>
then later the autotools glue will be added appropriately.<br>
<br>
One idea stepped in my mind and I would like to know what you guys think<br>
about it:<br>
<br>
There is currently no separation between extras that are considered prod<br>
ready and extras that are considered work in progress. Also, some of the<br>
extras which are considered prod ready are undocumented which isn't good<br>
and not to our standards.<br>
<br>
I suggest that we add a wip/ directory in -extras with the same layout<br>
and while we accept all contributions to wip/, only those documented and<br>
production ready gets moved out of wip/<br>
<br>
what do you think ?<br>
<br>
<br>
--<br>
Gilles Chehade<br>
<br>
<a href="https://www.poolp.org" target="_blank">https://www.poolp.org</a> \
@poolpOrg<br> <br>
--<br>
You received this mail because you are subscribed to <a \
href="mailto:misc@opensmtpd.org">misc@opensmtpd.org</a><br> To unsubscribe, send a \
mail to: <a href="mailto:misc%2Bunsubscribe@opensmtpd.org">misc+unsubscribe@opensmtpd.org</a><br>
<br>
</blockquote></div>
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscribe@opensmtpd.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic