[board] Minutes from October 2008 Meeting
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.
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
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
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
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
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
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
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
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
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,
former with security fixes
11:17:17 <@bklang> yunosh: ie. will there be a Horde 3.4? When does
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
11:18:05 < mrubinsk> ...and related to that, do the recent and
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
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
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
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
clients. and those don't want to wait for horde 4
need new features
11:21:38 < yunosh> but that shouldn't hold anyone off working on new
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
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
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
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
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
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
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
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 -
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
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
new, x.0 version
11:28:33 <@bklang> I agree with you about the long development cycle.
three possibilites: 1) more developers, 2) reduce
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
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
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
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,
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
do through the whole exercise since it takes
some time to
get any new release installed, tested, and
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
H3, I think it should be BC-breaking cleanup, PHP 5,
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,
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
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
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
having X.Y releases compatible, but it being okay to
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
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
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
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
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
just using the horde major version
11:42:44 < cjh> imp would be tricky here, since it's the only thing
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
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
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
users) usually don't
11:45:40 < cjh> so i'm suggesting something like horde 3.x goes with
mnemo h3.x, ingo h3.x, etc. just getting rid of the
that isn't necessary and keeping only the bit that
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
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
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
deal with, doing it now is as easy as it's ever going
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
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
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
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
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
11:54:25 <@bklang> the lack of one already availble should not drive
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
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
switching to a new VCS, but then to have to deal
losing another familiar, easy to use interface
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
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
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
especially if we keep history
11:59:10 < yunosh> that, and we have too much ancient cruft in our
11:59:22 < cjh> and we have a pretty wide codebase; support for
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
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
good (you still check out everything), but you don't
check out history for everything - space saving. kind
12:01:13 < mrubinsk> I'd love to have a "fresh start" with the next
version, but given the earlier conversation
possibility of still adding new features to H3/
wouldn't that make it difficult to backport
12:01:14 < cjh> I was only thinking about this on the train this
it's not fully baked
12:01:20 < yunosh> another argument for starting fresh is: we could
code as we php5/clean it up\ufeff, instead of
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
we should just create a structure and start adding to
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
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
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
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