[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
horde-dev.
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.
/BAK/
--
Ben Klang
Alkaloid Networks LLC
ben at alkaloid.net
404.475.4850
http://projects.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
today,
which is a progress compared to last time :)
11:03:31 -!- liamr [n=liamr at welsh.staff.itd.umich.edu] has joined
#horde-board
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,
step
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
this.
11:09:02 <@bklang> Ohloh.net has a download service that, among other
things,
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
releases
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
control,
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
services
tend to hide?
11:11:11 < mrubinsk> although is there any info regarding
speed/bandwidth/accessability from various
locations?
11:11:35 -!- selsky [n=selsky at cpe-69-203-118-206.nyc.res.rr.com] has
joined
#horde-board
11:11:56 < cjh> https://www.ohloh.net/help/download_faq
11:12:33 < cjh> "built on a world-class, global storage and distribution
network"
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
it,
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
broke..."
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
up
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
version
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
possible
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
diverged
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
merged"
phase
11:22:21 < cjh> one possibility would be to declare Horde 3.9 (or
another
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
4.0
being?
11:22:53 < yunosh> nah, that sounds like too much additional work for
limited
benefit
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/
architecture
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
the
architectural changes we want
11:24:55 < mrubinsk> hm, might be too much work then, manual merges
etc...
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+
with
namespaces
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
months
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
cycle
11:27:58 < Shpoon> often times the delay has nothing to do with
stability
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
Horde's
future
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
packages
11:29:39 < cjh> then apps can be released as often as necessary,
requiring
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,
hiro/protagonist?
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
major
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/
more
flexibilty?
11:33:28 < liamr> maybe, maybe not. we'd want to stay current for
security
issues
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
likely
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
("skinning")
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
lifespan
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
potentially
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
the
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
advantage
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
then.
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
scheme
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
is
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
which
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
information
that isn't necessary and keeping only the bit that
makes it
clear.
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
specific
plan for further h3 releases, or how HEAD will work
11:47:50 <@bklang> ok, I should probably table the reamining to items
since
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
FRAMEWORK_3
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
open
issues?
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
keep
history
11:50:42 < cjh> whether we do it, although I think at this point
everyone
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
then
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
quickly
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
browsers
11:53:25 < yunosh> not being able to see patchsets/diffs with each
commit
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
fine
11:53:48 <@bklang> I actually agree with cjh on developing the chora
driver
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
choice
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
frontend
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
with
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
working
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
distributed
one)
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
think
11:59:22 < cjh> and we have a pretty wide codebase; support for
partial or
lightweight checkouts seems almost essential for
putting
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
imp
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
major
version, but given the earlier conversation
about the
possibility of still adding new features to H3/
FW_3,
wouldn't that make it difficult to backport
changes from
HEAD
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
regardless,
unfortunately.
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
closing
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 /
horde/git
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
library
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
think
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