[board] Minutes from October 2008 Meeting

Ben Klang ben at alkaloid.net
Tue Oct 7 16:27:05 UTC 2008

Thanks to everyone who came out for the October 2008 Horde Board  
meeting.  This is an overview of the results from that meeting:

* Ohloh.net was proposed as a download service for future Horde  
releases.  Some concerns and questions were raised; the item is tabled  
until November to allow time for more research.

* Horde 3 lifecycle and Horde 4 development plans were discussed:
- A quick poll of non-developers in the room indicates that new  
applications requiring new versions of the framework is not a problem  
for most installations.
- Backward compatibility should be preserved throughout all releases  
for a given major version number.  If backward compatibility is broken  
it should only be done with a corresponding major version number bump.
- Refinements to the application version numbers was discussed.   
Should we keep the H3 appellation or renumber applications respective  
to the version of Horde for which they were intended?  More discussion  
on lists and in November.
- Horde 3.x will eventually move into bug- and security-fixes only.   
The exact timing is yet to be determined.
- The scope of changes in Horde 4.0 will be limited to allow for a  
shorter release cycle.  Ideally all major API changes should be  
implemented so that it is easy to maintain application compatibility  
throughout the life of Horde 4.x.
- All applications currently released as "stable" will be branched so  
future HEAD development will correspond to Horde 4.
- Horde 4.0 will require a minimum of PHP 5.2, possibly 5.3.
- The target for a release of Horde 4.0 should be approximately 6  
months from the beginning of development.

* Version Control:
- Git was tentatively selected to replace CVS
- Chuck will begin working on single repository to hold Horde sources
- A Chora driver will need to be written ASAP
- The new repository will be a fresh start.  Little or no attempt will  
be made to import history.  The existing CVS servers will remain  
online holding the Horde 3.x branches.
- The specifics of the Git repository layout are to be discussed on  

Wow, this is easily our most productive meeting yet!  Thanks again for  
all who attended and gave input.  Below is a transcript from the  
meeting.  See you all next on November 4th 2008.

Ben Klang
Alkaloid Networks LLC
ben at alkaloid.net

10:58:08 < kevinUofA> g'morning everybody!
10:58:31 < cjh> Hey Kevin
10:59:06 < mrubinsk> morning all
10:59:15 < wrobel> hi everybody
11:01:51 < yunosh> good afternoon everybody
11:02:07 < cjh> And from over here, good morning
11:02:29 < yunosh> looks like we have at least two non-developers here  
                    which is a progress compared to last time :)
11:03:31 -!- liamr [n=liamr at welsh.staff.itd.umich.edu] has joined  
11:03:33 < yunosh> are we wainting for someone, or can we start now?
11:03:39 < yunosh> ah, 3!
11:04:06 < yunosh> okay, let's wait two minutes for any late-comers
11:07:22 < yunosh> alright, here we go. welcome to the board meeting,  
                    right up, sit right down
11:07:43 < yunosh> bklang: will you do the conferencier again?
11:08:00 <@bklang> Sure, I can, but I have to drop off at 11:30
11:08:08 < yunosh> np
11:08:25 <@bklang> ok, first item: Ohloh.net hosting for downloads
11:08:40 <@bklang> I belive it was Chuck that suggested we consider  
11:09:02 <@bklang> Ohloh.net has a download service that, among other  
                    tracks downlaod statistics
11:09:20 -!- ShadowSpawn [n=marcus at horde/marcus] has joined #horde-board
11:09:25 <@bklang> it also has SFTP and HTTP mechanisms for automating  
                    of files
11:09:37 <@bklang> Does anyone have any comment or question about this?
11:09:48 < cjh> It's free, it doesn't seem like we'd give up too much  
                 and it would probably remove the need for FTP  
mirrors, taking a
                 bit of maintenance off of our hands.
11:10:10 < yunosh> how does it compare with sf.net's mdn system?
11:10:14 < mrubinsk> Sounds like a win-win to me...
11:11:00 < Shpoon> how stable is ohloh?  Meaning, is the service going  
to be
                    gone by next year?
11:11:05 < kevinUofA> Is there any fine print... ie "We own anything you
                       upload"... that sort of thing that these free  
                       tend to hide?
11:11:11 < mrubinsk> although is there any info regarding
                      speed/bandwidth/accessability from various  
11:11:35 -!- selsky [n=selsky at cpe-69-203-118-206.nyc.res.rr.com] has  
11:11:56 < cjh> https://www.ohloh.net/help/download_faq
11:12:33 < cjh> "built on a world-class, global storage and distribution
11:12:36 < cjh> nothing more specific than that.
11:12:45 < yunosh> that's a bit vague
11:12:45 < cjh> no fine print that anyone has noticed or blogged about.
11:13:07 < cjh> Okay, how about we table this and see who starts using  
                 maybe take a look at it in a few months
11:13:17 <@bklang> seems reasonable
11:13:19 < cjh> Right now FTP isn't a huge problem for us anyway; in  
the future
                 we might want to offload it.
11:13:26 < yunosh> good idea
11:13:35 <@bklang> it might fall into the category of "if it ain't  
11:14:07 < yunosh> well, it adds worlwide download stats compared to the
                    current solution
11:14:08 < Shpoon> this might be more useful if we were running into
                    download/usage limits on our distribution servers
11:14:16 < yunosh> so it's worth breaking the current situation
11:14:28 < cjh> K, we'll table it for now. Next?
11:14:30 <@bklang> ok, the second item on the agenda: Horde 3.3  
release cycle
                    and Horde 4.0 development plans
11:14:33 < yunosh> but there seem to be to many questions left
11:14:56 <@bklang> yunosh: I'll add it for next month's Board meeting  
to follow
11:15:04 <@bklang> give us time to research a bit more
11:15:32 < cjh> There are a couple of parts to this
11:15:35 < yunosh> ok.
11:15:40 < cjh> I see it roughly as:
11:15:48 < cjh> 1. current horde 3.3 releases and applications
11:15:57 < cjh> 2. any decision about switching version control systems
11:16:08 < cjh> 3. very rough roadmap for horde 4.0 and how that  
impacts HEAD
11:16:28 <@bklang> I have a related question:  Have we decided which  
                    will be the last in the 3.x family?  At what point  
does it
                    become security fixes only?
11:16:33 <@bklang> or bug + security fixes
11:16:39 < wrobel> same question here
11:16:48 < yunosh> i don't understand the questino
11:17:12 < yunosh> we always support one minor version with bug fixes,  
and the
                    former with security fixes
11:17:17 <@bklang> yunosh: ie. will there be a Horde 3.4?  When does  
the 3.x
                    branch become feature frozen so we can focus on H40
11:17:39 < yunosh> tough question
11:18:01 < yunosh> theoretically, we should start with 4.0 now and  
keep 3.3 for
                    bug fixes
11:18:05 < mrubinsk> ...and related to that, do the recent and  
upcoming 1.0
                      releases become "instantly" feature frozen?
11:18:23 < yunosh> but given the experience from the past, it's well  
                    that we see a 3.4
11:18:34 <@bklang> mrubinsk: I think at least Framework and Horde need  
to be
                    frozen.  The others, I don't feel as strongly about
11:19:34 < yunosh> i guess it depends on how much work it is to merge  
from a
                    Horde 4/PHP 5 HEAD to a stable Horde 3/PHP 4 branch
11:19:58 < Shpoon> Well, at least from an IMP point of view, I can  
tell you its
                    going to be pretty much impossible to release a  
3.4 with the
                    changes I am currently making
11:20:01 < yunosh> i bet we stop merging as soon as the two branches  
                    to a certain point
11:20:04 <@bklang> I think if we don't do that there will be a  
tendency to want
                    to write code that will be easily backported to PHP4
11:20:05 < cjh> i'd imagine that as soon as we start serious work on  
horde 4,
                 it will diverge drastically
11:20:21 < Shpoon> sorry - meant IMP 4.4
11:21:13 < yunosh> i personally may be an exception, since i have to  
deal with
                    clients. and those don't want to wait for horde 4  
but still
                    need new features
11:21:38 < yunosh> but that shouldn't hold anyone off working on new  
stuff in
                    HEAD and forget about merging
11:22:19 < Shpoon> We might still be in the "small improvements can be  
11:22:21 < cjh> one possibility would be to declare Horde 3.9 (or  
                 appropriate version number) a BC-breaking, PHP 5  
Horde 3.x  -
                 but one that doesn't dramatically reorganize everything
11:22:40 < cjh> i.e, the registry api would stay similar, most apis  
would be
                 the same
11:22:45 <@bklang> cjh: what do you see the difference between 3.9 and  
11:22:53 < yunosh> nah, that sounds like too much additional work for  
11:23:20 < cjh> yunosh: the benefit is it gives us an incremental base  
that can
                 be released in less than a year
11:23:29 < cjh> keeps our release cycle going
11:23:55 < cjh> bklang: I see 4.0 being the PHP 5 changes along with the
                 cleanup from the BCBreakingIssues page, plus a  
selected set of
                 architectural changes
11:24:14 < yunosh> i still don't think it's worthwhile
11:24:14 < mrubinsk> I think I agree with cjh - make it PHP5, but  
otherwise BC
11:24:25 < cjh> mrubinsk: i'm not saying strict BC
11:24:47 < cjh> just not a ton of time spent on new features/ 
11:24:49 <@bklang> I'm more with yunosh on this.  I think it's a lot  
of work
                    that will preclude making meaningful progress with  
                    architectural changes we want
11:24:55 < mrubinsk> hm, might be too much work then, manual merges  
11:24:56 < Shpoon> As an aside (since it's not technically on the list  
for the
                    meeting): have we decided what PHP version to  
support for H4?
11:25:15 < cjh> Shpoon: 5.2+, and depending on timing, _possibly_ 5.3+  
11:25:39 < Shpoon> cjh: OK - just noticed your wiki post on intl stuff
                    yesterday, which is 5.3 stuff
11:25:55 < yunosh> intl is available for 5.2
11:26:19 < yunosh> (from pecl)
11:26:33 < selsky> o we have a rough idea how long it will take H4/IMP  
5 to
                    come out?
11:27:00 < yunosh> not at all
11:27:15 < yunosh> but from past experience better count in years than  
11:27:20 < cjh> none. that's one of the reasons behind my suggestion -  
to keep
                 it quicker.
11:27:48 < Shpoon> The one thing to keep in mind about our HEAD versions
                    (especially with apps):
11:27:50 < cjh> i think it would hurt us in terms of adoption and  
getting new
                 developers if we had another years-long development  
11:27:58 < Shpoon> often times the delay has nothing to do with  
11:28:06 < Shpoon> (delay in releasing HEAD)
11:28:24 < Shpoon> but that we want to settle on the API before  
releasing a
                    new, x.0 version
11:28:33 <@bklang> I agree with you about the long development cycle.   
I see
                    three possibilites: 1) more developers, 2) reduce  
the scope
                    of changes (at the risk of breaking BC?)  3) drop BC
                    guarantees until some to-be-determined point in  
11:29:08 < cjh> if we make ourselves use individual package  
requirements for
                 the framework, we can work around a lot of this
11:29:22 < Shpoon> I was just typing what cjh did
11:29:24 < cjh> push as much horde base functionality as possible into  
11:29:39 < cjh> then apps can be released as often as necessary,  
                 specific package versions
11:29:39 < yunosh> such a PHP5/3.9 release won't give much benefit for
                    users/admins, only upgrade hassle, so it will be  
hard to
                    sell it
11:29:44 < Shpoon> That is a crucial part of H4 - the framework packages
11:30:49 < yunosh> but what do our admins/user say? kevinUofA, liamr,
11:31:04 < yunosh> that's what we have the board for, after all :)
11:31:43 < liamr> we're already running php5 on our horde  
installation, so
                   requiring it for H4 won't be an issue for us
11:31:48 < kevinUofA> It doesn't much matter to us,  We don't do any  
                       upgrades to our systems until the summer anyway
11:32:04 < kevinUofA> but we already run PHP5 as well
11:32:36 < yunosh> the question is, would you even consider upgrading,  
if you
                    don't get more functionality/better adminstration/ 
11:33:28 < liamr> maybe, maybe not.  we'd want to stay current for  
11:33:38 < liamr> tho, we did run H4.0 way longer than we should have
11:34:18 < kevinUofA> if there's no advantage to upgrading then we  
                       wouldn't... there would have to be compelling  
reason to
                       do through the whole exercise since it takes  
some time to
                       get any new release installed, tested, and  
fully deployed
11:34:19 < yunosh> H4 doesn't exist yet. do you mean Horde 2?
11:34:25 < liamr> what we'd be most intested in, i think, is the ability
                   dramatically alter application appearance  
11:34:26 < liamr> er.
11:34:28 < liamr> sorry
11:34:31 < liamr> H3.0
11:34:38 < cjh> Here's a restatement of what I said:
11:35:18 < cjh> Whatever we call the next release that is not a BC  
version of
                 H3, I think it should be BC-breaking cleanup, PHP 5,  
and a
                 selected set of features - not everything we hope to do
11:35:51 < cjh> I think whatever we decide on for features should seem
                 reasonable to have it out in beta in about 6 months,  
though if
                 it takes a bit more in reality, that's fine
11:35:58 <@bklang> cjh: we want the H4 API to be livable through the  
                    of the Horde 4 releases right?
11:36:02 <@bklang> even if we add more functionality later
11:36:13 < cjh> and I think it should be followed by a few more  
                 bc-breaking major releases
11:37:05 < cjh> bklang: ideally yes
11:37:20 < mrubinsk> so in essence we are just breaking off some of  
the planned                      H4 changes to the H3 series?
11:37:48 < yunosh> nope. afaiu chuck, h4 will just not contain  
*everything* we
                    want to do
11:37:55 < cjh> liamr, kevinUofA, hiro, protagonist - how important is  
                 major version (3.x, etc.) compatibility to you?
11:38:35 < cjh> i.e., do you ever upgrade Horde and not the  
applications, or
                 vice versa?
11:38:39 < liamr> no
11:38:40 < liamr> we don't
11:38:43 < kevinUofA> it's not.
11:39:01 < kevinUofA> we have no problem rebuilding when there's an  
                       to doing so
11:39:18 < cjh> Well that's good to know.
11:39:43 < cjh> that indicates to me that we might want to go to a  
policy of
                 having X.Y releases compatible, but it being okay to  
break BC
                 between X.1 and X.2
11:39:57 < yunosh> i guess we should simply break bc much more often  
11:40:16 <@bklang> I still feel like we need to increment the major  
version if
                    we break BC
11:40:17 < yunosh> no, we should stick with the bc breaking versioning  
11:40:19 < cjh> so, we'd have a strict Horde 4.0 series where all 4.0  
apps are
                 compatible with each other
11:40:40 < cjh> hmm, that seems like it might just lead to version #  
bloat to me
11:40:46 < cjh> but it's just a number, so that's okay by me
11:40:49 < yunosh> i don't see a problem with that
11:40:51 <@bklang> perhaps, but it's less surprising
11:40:54 < cjh> heh, okay
11:41:01 <@bklang> Rule of Least Surprise
11:41:04 < yunosh> opensuse is at version 11 now :)
11:41:19 < cjh> true, i guess getting one of these releases out a year  
                 ambitious, so it won't go up _that_ quickly :)
11:41:19 <@bklang> ok should we move on?
11:41:22 < kevinUofA> as long as there's a way to get 3.x data into  
4.x then
                       there's no problem
11:41:39 < yunosh> kevinUofA: yes, sure
11:41:42 < yunosh> bklang: yes
11:41:47 < cjh> one more suggestion...
11:42:12 < cjh> i think we should standardize on application version  
numbers in
                 a way that makes it even more clear than the H3 stuff  
                 horde version an app works with
11:42:22 <@bklang> I agree with that
11:42:33 < cjh> maybe even dropping the major version # for the  
application and
                 just using the horde major version
11:42:44 < cjh> imp would be tricky here, since it's the only thing  
with a
                 higher version # than horde
11:42:46 <@bklang> which is fine for everything out right now except IMP
11:42:49 < cjh> but we can come up with something i'm sure
11:43:00 < yunosh> what speaks against the Hn?
11:43:10 < yunosh> we only added it for exactly that purpose
11:43:11 < cjh> yunosh: because we still basically use IMP 4.3, etc.
11:43:25 <@bklang> and there's no such thing as IMP H2 4.3 or IMP H4 4.3
11:43:46 < yunosh> no, but i don't see the problem
11:44:04 < yunosh> we'll have IMP H4 (5.0)
11:44:04 < cjh> yunosh: horde 3.x goes with imp 4.x, mnemo 2.x, ingo  
1.x, etc.
11:44:20 < yunosh> yes, that's why we added H3 to the version numbers
11:44:36 < hiro> sorry to jump in late here...  the version  
incompatibility is
                  not a problem for me.  We upgrade everything at once
11:44:42 < cjh> right, but what bklang said
11:45:01 < cjh> you have to type the whole thing out, and in practice  
we (and
                 users) usually don't
11:45:40 < cjh> so i'm suggesting something like horde 3.x goes with  
imp h3.x,
                 mnemo h3.x, ingo h3.x, etc. just getting rid of the  
                 that isn't necessary and keeping only the bit that  
makes it
11:45:43 < cjh> hiro: thanks
11:46:29 < cjh> Seems like we should argue this out over the next  
month or so
                 on list or whatever. Let's move on for now?
11:46:37 <@bklang> ok next up: SQL Shares performance
11:46:41 < yunosh> ah, ok. well, that's a nice idea, though i'm not  
sure it
                    worth changing our versioning scheme yet again,  
after only a
                    single majore release
11:46:53 < yunosh> k
11:47:03 < cjh> hold on...
11:47:25 < cjh> we still haven't talked about version control and a  
                 plan for further h3 releases, or how HEAD will work
11:47:50 <@bklang> ok, I should probably table the reamining to items  
                    we're going to run over
11:47:55 <@bklang> I'll re-add them for next month
11:48:04 <@bklang> err, remaining two items
11:48:10 < cjh> that's fine. i think mapping out releases and a VCS  
decision is
                 more important
11:48:27 < yunosh> i think first of all, we should branch all apps  
that we want
                    to release for horde 3.3
11:48:40 <@bklang> I agree with yunosh there
11:48:45 < cjh> i agree
11:48:50 < mrubinsk> +1
11:48:58 < yunosh> all horde 3 releases will be cut from CVS and  
11:49:18 < yunosh> that makes us free to decide about CVS HEAD / VCS
11:50:09 < yunosh> regarding the move to git or whatever, what are the  
11:50:34 <@bklang> we haven't picked the system to use yet
11:50:38 < yunosh> for me personally: a chora driver, and whether to  
11:50:42 < cjh> whether we do it, although I think at this point  
                 except maybe Jan is in agreement that we should
11:51:12 < yunosh> i'm fine with doing it :)
11:51:22 < cjh> cool
11:51:40 < cjh> i think from the standpoint of our tools and what we  
have to
                 deal with, doing it now is as easy as it's ever going  
to get
11:51:47 < cjh> and doing it before h4 really starts is important to me
11:51:50 < yunosh> i will miss my cvs-fu though :)
11:52:11 < cjh> i also think that we should pick something, do it, and  
                 worry about stuff like chora, because switching will  
make sure
                 we have motivation to write a good chora driver asap
11:52:19 < cjh> instead of just delaying it
11:52:28 < yunosh> i don't agree there
11:52:41 < yunosh> chora is crucial for the development process imo
11:53:01 < cjh> but we're talking about horde 4 dev process. we'll have
                 something, and we'll get at least a basic chora  
driver up
11:53:06 < mrubinsk> I"m with yunosh
11:53:19 < cjh> we've waited a long time on this, i don't want to give  
us _any_
                 reason to delay further
11:53:20 < mrubinsk> especially given the (lack of) available git   
11:53:25 < yunosh> not being able to see patchsets/diffs with each  
                    message would violate the many-eyes-concept
11:53:29 < Shpoon> can't we use the gitweb code as a temporary fix
11:53:32 < hiro> the history is somewhat important to me, although if  
you kept
                  the cvs around as an archive record, that would be  
11:53:48 <@bklang> I actually agree with cjh on developing the chora  
11:53:58 < yunosh> hiro: the latter we do in *any* case
11:54:15 < hiro> great  :)
11:54:16 < yunosh> i use history a lot too, but there are some good  
reasons to
                    start fresh
11:54:25 <@bklang> the lack of one already availble should not drive  
our VCS
11:54:45 < yunosh> bklang: not the choice, but the timing
11:54:56 < mrubinsk> no, I agree on the choice of VCS, it's *when* we  
move to
                      it that I'm questioning...
11:55:16 < wrobel> I'd be fine with gitweb but there should definitely  
be a web
11:56:21 < mrubinsk> I think it will be challenging enough for (some  
of) us
                      switching to a new VCS, but then to have to deal  
                      losing another familiar, easy to use interface  
would just
                      add to the pain...
11:56:56 < yunosh> i agree
11:57:06 <@bklang> well either way we need to prioritize getting Chora  
11:57:31 < cjh> okay, sounds like there's consensus here; let's just  
not hold
                 up on having the chora support *perfect*
11:57:46 < yunosh> sure
11:57:47 < mrubinsk> I'm fine with that...as long as there is  
*something* :)
11:57:48 < wrobel> sure
11:58:04 < cjh> Okay, so that leaves:
11:58:17 < cjh> - which DVCS (I think it's decided that we want a  
11:58:24 < cjh> - how to organize the repository and what to import
11:58:41 <@bklang> in an ideal world I'd like to keep all the history
11:58:48 <@bklang> but it's been a real challenge to import CVS into Git
11:58:54 < cjh> I've been thinking we might want to take another look at
                 bazaar, because of its support for lightweight  
checkouts -
                 especially if we keep history
11:59:10 < yunosh> that, and we have too much ancient cruft in our  
history, i
11:59:22 < cjh> and we have a pretty wide codebase; support for  
partial or
                 lightweight checkouts seems almost essential for  
                 everything into a single repository
11:59:46 < cjh> and i think we have a pretty compelling desire to have  
a single
                 repo, instead of separate areas for horde, apps, etc.
11:59:51 < yunosh> what is this? (partial/lightweight checkouts)
11:59:55 < cjh> we do have an awful lot of cruft
12:00:22 < cjh> a partial checkout is like cvs co imp - just check out  
                 instead of everything
12:01:00 < cjh> lightweight is a checkout without the history, which  
isn't as
                 good (you still check out everything), but you don't  
have to
                 check out history for everything - space saving. kind  
of like
                 cvs export
12:01:13 < mrubinsk> I'd love to have a "fresh start" with the next  
                      version, but given the earlier conversation  
about the
                      possibility of still adding new features to H3/ 
                      wouldn't that make it difficult to backport  
changes from
12:01:14 < cjh> I was only thinking about this on the train this  
morning, so
                 it's not fully baked
12:01:20 < yunosh> another argument for starting fresh is: we could  
add the
                    code as we php5/clean it up\ufeff, instead of  
importing the
                    current state
12:01:29 < cjh> mrubinsk: yes, but that's going to be difficult  
12:01:37 < cjh> yunosh: yeah, that's a possibility
12:01:58 < cjh> I think if we're starting fresh this isn't so much of  
an issue.
                 we should just create a structure and start adding to  
it, and
                 without 10 years of cruft, git should be fine
12:02:11 < mrubinsk> cjh: yea, true :)
12:02:24 <@bklang> time check: it's past 12, so we should make some  
                    statements and cover anything that's left
12:02:47 < cjh> off-the-cuff proposal: start fresh with Git. repo  
layout to be
                 determined offline
12:03:33 < yunosh> sounds good. though no vote from me on the actual VCS
12:03:47 < yunosh> but git sounds most promising to me so far
12:04:24 < mrubinsk> cjh: sounds good to me
12:05:07 < cjh> Alright then. I'll merge the various git repos in / 
                 and start adding the PHP 5 libs to it. we'll talk  
about the
                 specific structure on-list
12:05:18 < cjh> and obviously we'll start on a git driver for the VC  
12:07:20 < hiro> gotta run, should have been at work a while ago!
12:07:30 < cjh> :) seeya hiro
12:07:36 < cjh> thanks for stopping in
12:07:43 < cjh> Sounds like we're decided then?
12:07:46 <@bklang> anything else Chuck?
12:07:50 < yunosh> i think so
12:07:59 < cjh> Alright. Well that's momentous. :)
12:08:10 < cjh> certainly one of our more decisive board meetings. I  
                 that's good.
12:08:12 < mrubinsk> :)
12:08:32 < yunosh> thanks everybody for joining
12:08:40 < cjh> Thanks all!
12:08:46 < cjh> bklang: will you post the minutes?
12:08:51 <@bklang> sure
12:09:24 < cjh> thanks
12:10:06 < yunosh> have a nice day/evening everyone
12:11:16 < kevinUofA> ciao everyone!  See you next month
12:11:34 < mrubinsk> Nice "seeing" everyone, take care.

More information about the board mailing list