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" <[email protected]> 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 [email protected] > To unsubscribe, send a mail to: [email protected] > >
