[17:01] *** niq joined #validator [17:02] Dodji: /me been playing with libcroco update (0.5) [17:03] niq: okay [17:03] I guess you found a lot problems ... [17:03] and saw a message on libcroco list saying something about locations [17:03] yeah [17:04] but wasn't sure if that meant we had line/column available in CVS yet? [17:04] *** scop joined #validator [17:04] hi [17:04] niq: not in CVS, but in GNU ARCH archive [17:04] hi scop [17:04] hmm, how would I get that? [17:05] 0.5: had to do some work to build it, but nothing unusual [17:05] niq: http://mail.gnome.org/archives/libcroco-list/2004-March/msg00011.html [17:06] niq: on unix ? [17:06] linux [17:06] hmmh, normally, if you have glib and libxml2, it should compile straight [17:06] oh, maybe you didn't have glib ... [17:07] It didn't find libxml2 - had to edit libcroco-config by hand [17:07] hmmh libcroco is shipped in a fair amount of distros and I haven't had any bug report like that ... [17:08] niq: could you filed that in bugzilla please ? [17:08] niq: bugzilla.gnome.org, product libcroco [17:08] bugz@ ? [17:08] aha [17:09] niq: you said 'it didn't find libxml2". what didn't find libxml2 ? [17:09] configure [17:10] libcroco 's configure doesn't use libcroco-config to find libxml2's path ... [17:10] I gave it the relevant paths [17:10] oh well [17:11] okay [17:11] to be honest, I have kinda forgot libcroco-config ... [17:11] because we use pkg-config instead [17:11] and the INCLUDES/etc go included just fine [17:12] maybe that's why I didn't get any bug report [17:12] but it didn't #define CROCO_HAVE_LIBXML2 [17:12] Dodji, it would be great if we had a .tgz of the sources you think we should look at. [17:12] *** niq agrees [17:12] hmmh [17:13] so you want regular snapshot releases ? [17:13] well.... [17:13] okay, I will try to do that. [17:14] does not have to be "regular" or "release", just something so I dont have to mess with GNU arch on win32... [17:14] oh, you use windows too .. [17:14] ahem [17:14] I see. [17:14] okay, I understand. [17:14] have we started yet? :) [17:14] I guess we have [17:15] yod, you chair this meeting, you decide :-) [17:15] *** niq just too lazy to do the learning curve for your system:-) [17:15] wow, wow, I need to wake up before taking any decision [17:16] but seriously, a few more minutes of discussion on the new dev version of libcroco is OK [17:16] and for the record, thanks Dodji [17:16] no problem :-) [17:17] agenda: http://www.w3.org/mid/7FB39589-86E0-11D8-8C89-000393A63FC8@w3.org [17:19] alright then, let's proceed to agenda item 1 - link checker [17:20] Link checker released last week (apr 2nd) without major trouble [17:21] then the htmlhelp thread [17:21] so congrats to Ville for that [17:21] thx :) [17:21] yes, that seems to be the main feedback - robots exclusion etc [17:21] and for those who weren't on IRC earlier today [17:22] scop: I don't know how the libs have changed [17:22] right. I'm glad there seemsd to be no _new_ issues introduced by the release. [17:22] there was an incident - either with check or checklink, someone pounding on w.v.o, and possibly on another host through w.v.o [17:23] but when I did this for link valet I abandoned RobotAgent and used WWW::RobotRules for it [17:23] niq: why not RobotUA? [17:23] so making sure that both checklink and check behave nicely seems to be a trendy concern [17:23] can't remember - too long ago [17:24] but something didn't work [17:24] ok. it seems to work ok for me here in initial tests, w/patched LWP 5.76 [17:24] OK, well, this was >4 years ago [17:25] I'll shut up about it:-) [17:25] anyway, the robot rules should be trivial, thoughts about the default delay? [17:25] scop: for the logvalidator, I've set up a 1-3s delay [17:25] 1s is generally enough, it seems [17:26] good, I'm thinking 1 sec, and the user can choose to increment that [17:26] but picky webmaster may not like any value of it anyway [17:27] sounds reasonable [17:27] any idea how soon we can start testing it? [17:27] I can get it committed today, but probably the docs and UI won't be quite "finished" [17:27] *** yod notes that Terje set up a nice auto-cvs-updating version of the markup validator on qa-dev [17:28] we could do the same, or similar, for checklink [17:28] scop: fast! [17:28] yep, it's a trivial change, but introduces "side effects" [17:29] *** niq doesn't recollect auto-cvs-updating sys ... did he post about it [17:29] like suddenly all the response codes for URIs denied looking like 200->403 [17:29] as if they would have been redirected [17:29] maybe he just mentioned it on IRC [17:29] niq: qa-dev.w3.org/wmvs/0.6/ [17:29] http://qa-dev.w3.org/wmvs/0.6/ [17:30] http://qa-dev.w3.org/wmvs/HEAD/ [17:30] scop: it's not 403 [17:30] Or is that RobotAgent's doing? [17:30] niq: yes [17:30] can you override that? [17:31] 403 sounds wrong: forbidden by robot rules is not HTTP-forbidden [17:31] right, not too clean. but RobotUA says "403 Forbidden by robots.txt", could use that (uglyish) [17:32] AFAICS there's no hook to be cleanly overridden [17:33] FWIW, I have if ( forbidden by robot rules ) set code to 1, class to non-http, and message to "forbidden by robot rules" [17:34] yes, we need something similar. currently missing that code classification [17:35] *** xover joined #validator [17:37] ok, one more thing about RobotUA: the constructor wants an email address [17:38] thinking about using $ENV{SERVER_ADMIN}, with fallback to the validator mailing list if not found [17:38] hmm, not sure about fallback to a public mailing-list [17:38] postmaster@localhost ? [17:39] no strong opinions about the fallback here [17:40] command line use is another thing; perhaps try $REPLYTO and/or gecos+hostname there? bad idea/privacy issues? [17:40] me neither, really, since www-validator has "archive approval" set, not too much risk of having anyone complaining they did not know it was publicly archived [17:40] scop: are you sure about RobotUA? [17:40] not set in stone, but that switch took like 5 minutes of coding [17:41] ok [17:41] $ENV{CHECKLINK_FROM}... [17:41] $CHECKLINK_FROM ok, but practically nobody will set it :( [17:42] well, as a user, I do not want to provide a mail address here... [17:44] *** scop nods [17:44] (I would neither want it to honor robots.txt, btw) [17:44] what is the address used for? [17:44] contact in case of trouble (robot gone mad, etc) [17:45] got it [17:45] From: header, innit? [17:45] yes [17:45] bjoern_: "I would neither want it to honor robots.txt" you mean checklink? [17:45] ...or appended to User-Agent in parens [17:45] yod, yes. [17:45] I used to think so [17:46] RFC 2616 has an example: [17:46] now I tend to think this would not be bad as an option ON by default [17:46] From: webmaster@w3.org [17:46] :-) [17:46] *** niq thinks an HTTP URL with contact info is better in these days of spam [17:46] *** yod suggests http://www.w3.org/Help/Webmaster :) [17:47] or, more seriously, http://validator.w3.org/docs/checklink.html maybe? [17:47] zigackly [17:47] grr, RobotUA "smart", requires '@' in $from. [17:47] HTTP requires a mail address, URIs are not allowed. [17:48] *sigh* ok [17:48] and re defaults, RFC 2616 says "The client SHOULD NOT send the From header field without the user's approval" [17:48] Checklink on v.w3.org can be configured to be a nice citizen; any "DOS" would be from someone running it elsewhere... i.e. referring to anything @w3.org is inappropriate. [17:48] the user = as in a human-driven UA [17:49] And, BTW, the incident Liam was referring to was _not_ sourced at v.w3.org; it was a local install. [17:49] as in "the request is being performed on behalf of the person given, who accepts responsibility for the method performed." [17:49] xover: you got more info from here off the list? [17:50] yod: Rephrase? (Liam emailed me off-list, yes) [17:50] s/from here/from him/ [17:50] maybe checklink should have a User-Agent like "W3C LinkChecker running on ..." [17:50] s/off the list/off-list/ [17:50] sorry [17:51] SOurce IP gives you that info. [17:51] right [17:52] yes, but that is not obvious to everyone [17:52] The fact of the matter is that anything we put in as a default has privacy and security issues. [17:52] A dummy value like "root@localhost" is about the best we can do. [17:53] unknown@server.invalid [17:53] yes, back to the postmaster@localhost suggestion [17:53] or rather fix that module to allow the omission [17:53] bjoern_: Right. [17:53] I think it's there deliberately. [17:54] the "fix" would be an easy one, just override new() without mandatory $from [17:54] we could query the user at installation [17:54] but that would break e.g. ppm which does not allow interaction, AFAICT. [17:55] querying on first run would be somewhat better [17:55] but may be troublesome with the CGI version [17:55] the good thing with checklink so far was that it never needed a config file [17:55] How about bailing out if the user has not provided an email address, or used a --really-awkward-and-messy-forced-emailless-run? [17:55] that addition would make one necessary [17:56] Encourage most users to provide their email, but allow those that don't want to to omit it (at the expense of some slight inconvenience). [17:57] +1, not too happy but that seems reasonable [17:57] And possibly add a shortcut to say "Guess my email" which would expand to <$USER@`hostname --fqdn`>. [17:58] From: W3C LinkChecker, see http://validator.w3.org/... [17:58] would be allowed too [17:58] or $ENV{REPLYTO}, that's the closest to a "standard" place for setting a mail address in the env [17:58] And, BTW, putting conveniences like this into ~/.checklinkrc to avoid having to type it all the time is an acceptable UI. [17:59] bjoern_: putting email anywhere risks spam flood [18:00] -and risks getting complaints re other peoples installations [18:00] we would get them anyway, From my be faked... [18:00] Those are par for the course if you 1) run the linkchecker against someone else's site, or 2) provide linkchecker as a public service. [18:00] yep [18:02] so, do we have any consensus on this matter? [18:02] I don't have a real opinion about it [18:02] *** xover looks at scop... [18:03] my .02e: SERVER_ADMIN in CGI mode, dunno about what's best for command line [18:03] as long as the user can be encouraged to give his own and that a few decent guess mechanisms are used before a default is give, I'm ok [18:03] *** niq thinks we should drop the need for it, since there isn't a satisfactory way to include it other than by *positive* action from a local admin [18:04] niq: we can give that a try, but I doubt LWP maintainers will ever listen to our arguments [18:04] hehe [18:05] that said, if we put a focus on spam and ask them to allow URIs, not just e-mail... [18:05] would that be enough? [18:05] *** niq has no strong view [18:06] any opinion? [18:06] If this goes into From then an URI is not permissible IIRC. [18:06] as bjoern said, RFC2616 "From" is a mail address [18:06] you're positive it's used as From ? [18:07] yes [18:07] What you can do is something like From: W3C LinkChecker, see http://validator.w3.org/... [18:07] yes, just browsed the code. but as said, new() can be trivially overridden if that's what we want [18:07] I would be in favor... [18:08] a full/proper solution would be to require it as part of the install process. But who wants to hack up an installer to enforce it? [18:09] i'd hate that. besides, on a multi user box it would not be sufficient [18:09] scop: if (! e-mail in config) override [18:09] would that work? [18:09] So second best is to encourage users to do it right, and omit From: if they don't [18:09] If we're running on v.w3.org, that address is whatever we want. If it's _not_ running on v.w3.org we do *not* want a default link to w3.org in there. [18:10] yod: yes, but there's the multi-user problem, would need per-user config [18:10] why not? [18:10] (xover) [18:10] Because it's not w3.org that is running it! [18:11] cf. Liam's problem; he's banning the w3 linkchecker because __someone_else__ nuked htmlhelp.com using a local install of it. [18:11] *** yod notes that w3.org receives a lot of spam complaints (not to mention being blacklisted) because of w3.org URIs in hTML spams [18:11] that would corroborate xover's concern [18:11] apache gets that too .... [18:12] And transparently giving out $ENV{SERVER_ADMIN} in CGI mode has privacy and security issues. [18:12] hmmm [18:12] It needs to be explicitly configured, or it needs to be a nonsense value. [18:12] well, if it does not send a From: all you have is the UA string which directly links to W3C [18:13] require it explicitly, and die with a 500 if not configured [18:13] - generate lots of 'bug' reports [18:14] so die with 500 and an error page explaining [18:14] the httpd.conf on my box has this to say about ServerAdmin [18:14] # ServerAdmin: Your address, where problems with the server should be [18:14] # e-mailed. This address appears on some server-generated pages, such [18:14] # as error documents. e.g. admin@your-domain.com [18:15] And a multi-homed box where Apache is listening only on the internal interface, but (deliberately) allows checklink out into the world? [18:16] I'm running just such a box BTW. And ServerAdmin is set to my closely guarded internal (work) email address. [18:16] then someone is responsibe for it [18:16] xover: there will always be very complicated cases... if the link checker makes it clear that the mail should be configured, then... [18:16] you would of course configure it with a valid public address [18:17] niq: Why? The httpd isn't available to the worl; only to the internal network. [18:17] " but (deliberately) allows checklink out into the world?" [18:17] Yes. And? [18:17] I suggest we discuss this on the mailing list then... [18:18] Silent information leakage is The cardinal sin software can commit; even before data loss. [18:19] mailing-list it is, if we're not reaching any consensus on what should be done if the address is not configured [18:19] Do we have any "quick fix" remedies that will somewhat alleviate this problem while we mull it over? [18:19] yep. No email addy [18:20] nothing - override the constructor [18:20] for the moment [18:20] ok [18:21] (we could have a @w3.org address with auto responder explaining the situation, btw, but lets move on for the moment) [18:21] yes, moving on [18:21] autoresponsers are evil [18:21] they'll respons to spam with forged From [18:21] next on the agenda - markup validator [18:21] =============================== [18:22] open bug roundup http://www.w3.org/mid/9EC2B50E-7C89-11D8-B1A3-000393A63FC8@w3.org [18:23] mid-term plan http://www.w3.org/mid/AE655DB6-82EA-11D8-914C-000A95E54002@w3.org [18:23] basically : I'd like your opinion on the plan... [18:23] moving on with what we have in CVS [18:23] ack that we have not fixed all the bugs [18:23] esp XHTML related ones [18:24] and start work on multi-parser [18:24] [[[ [18:24] and tweaking it to death to fix XML related [18:24] bugs may just take more effort than re-starting with a multi-parser [18:24] design. [18:24] ]]] [18:24] mod_validator :-) [18:25] *** yod confesses only a limited knowledge of mod_validator [18:25] multi-parser [18:25] *** xover gives niq The Look... [18:26] *** niq glares defiantly back [18:26] xover: give your opinion, instead, please :) [18:26] What is the status of HTML templates, etc? [18:26] yod: professional rivalry [18:26] bjoern_: HTML Templates are in alpha quality on HEAD. [18:27] bjoern_: AFAIK, alpha [18:27] ah there you go [18:27] http://dev.w3.org/cvsweb/validator/share/templates/en_US/ ? [18:27] bjoern_: ack [18:27] Well, if we are going to have a release this side of the millennium, it seems obvious fussy parsing will have to go. [18:28] HEAD check uses these? [18:28] Yes. [18:28] xover: indeed [18:28] Current HEAD: http://qa-dev.w3.org/wmvs/HEAD/ [18:28] and without an obvious solution for error/warning, we have a choice of removing it altogether or a LARGE warning [18:29] Current CVS: http://qa-dev.w3.org/wmvs/0.6/ [18:29] how difficult would it be ot merge this 060_branch? [18:29] (and of course non-default option) [18:29] (with) [18:29] (to) [18:29] bjoern_: Moderately. [18:30] What blocks updating :8001 currently? [18:30] We could conceivably do another beta with the less, uhm, "controversial" fussy parsing. [18:30] *** yod notes he'd rather we do anything not trivial *after* a release of 0.6.5 [18:30] with what runs on qa-dev? [18:31] bjoern_: fussy issue not solved, plus a bunch of bug reports from beta 1 not addressed [18:31] bjoern_: Just that we want "stable" point releases (in this case a beta) running on :8001, not CVS snapshots. [18:31] (well, and what yod said ;D) [18:31] I think multiple branches, beta releases, stable releases, product versions, etc. does not really help development... [18:32] OT: qa-dev IP changed? ssh whines. [18:32] Branches are what enabled the templating code to be developed in the first place. [18:32] bjoern_++ [18:32] scop: yes, MIT servers were all moved and re-routed [18:32] Stable releases avoid getting big chunks of br0ken all over v.w3.org and w-v. [18:33] *** yod notes that total absence of beta/etc caused some very courageous (and broken) releases of the css validator [18:33] I don't need dev.w3.org to maintain my experimental stuff, I have local svn reps for this... [18:33] and given the level of attention that w.v.o gets... [18:34] yod, not that I know of... [18:34] it gets attention? [18:34] niq: a bit [18:34] :-) [18:34] bjoern_: I recall at least a few days of crashes after a release [18:35] but if I misunderstood their importance, I stand corrected [18:35] well, I would not mind if :8001 misbehaves [18:35] in any case, the branches are not such a big success, and one of my questions actually was - what do we do with them [18:36] *** SHS` joined #validator [18:36] For Tidy, we just have HEAD and daily snapshots of the source (plus automated builds) [18:36] :8001 could go now that we have qa-dev though [18:36] I reiterate: Branches are what allowed the Templating system to be developed in the first place. [18:37] xover: they may benefit you, but they confuse the world [18:37] it's not branches' fault, it's the way we've been using them [18:37] are you using them as your primary dev? [18:37] niq: Yes. [18:38] aha [18:38] scop: Agreed. [18:38] I would be willing to sacrifice the convenience of dev.w3.org as a playground for more development... [18:38] scop: what would have been a better way of using them? [18:39] Actually, no. I'd go further... It's not even the way we use them; it's the way we've been managing the project. [18:39] xover++ [18:39] There should never have been new feature additions on the 0.6.0 branch. [18:40] (my fault all, BTW) [18:40] or mine, I'm supposed to "manage" [18:41] but blame is not the issue [18:41] the issue is to solve and move forward [18:41] And merging should have happened after every release, including making releases be smaller more frequent and less feature-rich (more manageable). [18:41] yod: you like herding cats? [18:42] niq: cats, no, I'm silly enough for developers, but not *that* silly [18:42] *** niq boggles [18:42] And HEAD has similar problems; it should have been kept as current _mainline_ bleeding edge, not waaaaay out there experiemental won't even pass perl -cw bleeding edge. [18:42] *** scop needs to go afk for 5ish mins [18:42] scop: OK [18:43] So how do we clean this mess up? [18:43] I suggest: [18:43] - polish 0.6.5 for a week [18:44] does anyone other than xover know the state of the branches? [18:44] - release 0.6.5 [18:44] - merge with head as much as possible, and start from here with a small(er) step approach [18:45] a mandatory limited time between releases could force us to not be too wild [18:45] but could prevent us from doing well needed arch changes [18:45] Hmmm. I think out schedules are too erratic to allow for time-based releases. [18:45] niq: I don't think anybody else has more than a vague understanding of it [18:45] *** niq determines to put mod_validator on qa-dev [18:46] But for the forseeable future, I think getting 0.6.5 out, merging onto HEAD, ... [18:46] xover: doesn't have to be strict, but ack that constraint [18:46] ... and then immediately _branching_ for a 0.7.0 release (!!!) ... [18:46] ... with a very shortly following 0.7.0 (public) alpha release on :8001 ... [18:47] where 0.7 = xover; HEAD = general? [18:47] ... and beeing strict about what one puts in in which branch. [18:47] *** yod worried about yet another branch if we don't have a good plan to manage it [18:48] yod: It's not Yet Another; 0.6 is merged (poof, gone) so it would just be HEAD and 0.7 ... [18:48] *** yod suggests xover sends mail to qa-dev@ with a plan for branches maybe? [18:48] ah got it [18:48] ... but this time the difference between branches is explicitly not allowed to get too far out of sync. [18:48] [[ 2 - invert... HEAD would be the current work (synced with 0.6branch - can we do that, technically? - or removing the 0.6 branch) and advanced development would be done in a specific branch [18:48] (self-quoting) [18:49] *** niq eyes glazed over [18:49] It can be done but it turns CVS's logic upside down so is a pain to work with. [18:49] how do we make sure we don't get too far? [18:49] Dicipline? [18:51] Another jey element to making that work, is doing radical stuff on a branch; one that will _not_ get found by users, and won't block releases in any way. [18:51] *** scop is back, and knows the 0_6_0 state pretty well [18:51] e.g. a logical next step in here is to make the backend of validator be modular (in the CPAN *.pm sense) ... [18:52] ... that would typically go on a VALIDATOR-UBER-BROKEN-DO-NOT-TOUCH branch. [18:52] xover: agreed [18:52] xover: do you mean "next step" after the merge? [18:52] So HEAD would be more or less == 0.7 branch, but with various minor feature additions. [18:52] scop: Yes. [18:53] So when 0.7.0 final is released, we can immediately branch 0.8.0 from HEAD, with all features in place (frozen), and do an alpha on :8001. [18:53] bjoern_: you've been silent. no opinion on the plan? [18:53] The modularization work stays on its branch until it's ready to be merged. [18:55] ok... [18:55] xover: any idea of a timeframe and work needed for the very 1st step [18:55] (i.e 0.6.5) [18:55] *** xover also would like to hear bjoern_'s opinion on this... [18:55] (give me a second) [18:56] yod: Timeframe is tricky, as always. I guess we could back out fussy parsing and do another Beta (low-key) fairly quickly. [18:57] I don't have much time this week I'm afraid [18:57] *** niq doesn't understand why fussy has to be a Big Deal [18:57] because fussy messes up with the sacro-saint concept of validation? [18:57] Because even min-tag requires a lot of work to get right still. [18:58] (mainly UI wise) [18:58] +what xover said [18:59] And the rest of the stuff has so many issues I can't really see any way to resolve it this decade right now. [18:59] xover, what is the plan re m12n? [18:59] but wouldn't "backing fussy out" be a matter of hc'ing that option to FALSE? [18:59] scop: More or less. I want to nuke the code too for reasons of maintainability, but basically yes. [19:00] xover: ok [19:00] bjoern_: Reimplement most of the subroutines into Perl modules and get them to a state where they can be released seperately. [19:00] FYI, I asked around (W3 Team) and the general feeling was that non_default should be sufficient, remove if we prefer [19:00] Then make "check" use those modules instead of inline code. [19:01] do we agree on a C++ wrapper for OpenSP? [19:01] Iff it can be made to work reliably and provide the features needed... Yes, I think? [19:01] scop? yod? [19:02] regarding m12n, I want to proceed with that in checklink as soon as the robot saga has a happy ending [19:02] there's probably some things we can share, like auth forwarding, module discovery, [...] [19:02] http://lists.w3.org/Archives/Public/public-qa-dev/2004Mar/0017.html [19:02] I think I have most of the code necessary to make this (::OpenSP.xs) happen... [19:02] BTW, C++ wrapper is: http://search.cpan.org/~link/SGML-Parser-OpenSP-0.01/ [19:02] (re fussy) [19:03] I could merge your code with mine [19:03] ( http://cvs.sourceforge.net/viewcvs.py/ieqabar/ieqabar/src/library/OpenSP.cxx ) [19:03] fine with me re- wrapper [19:03] (i.e., port that to .xs) [19:04] XS/wrapper sounds good to me [19:04] niq: re- sensible warning mode, "not for this release" seems to be xover's view [19:04] right/wrong? [19:04] bjoern_: I need to find somewhere sane to stick that code into CVS and get you write access. [19:05] scop: Yes, getting those things done is a priority for me. [19:05] I'd be fine with dev.w3.org /2004/ospwrapper or something... [19:06] bjoern_: Ok. Lets figure something out and get to it. :-) [19:06] yod: Did we cover everything? [19:07] xover: I'm checking that now [19:07] we did not address cataloguing/bugzilla#297 [19:07] bjoern_: BTW, the current code is more or less the limits of my abilities. You want to take charge then be my guest! :-) [19:07] oh, btw, have private apache2+modperl inst on qa-dev, if anyone wants to play [19:08] niq: URI? [19:08] TBD (setup) [19:08] ok [19:09] will mail list [19:10] re- this, some people in the Team ranted that SGML got things wrong, that cataloguing should really use URI, etc, etc [19:10] but nothing beyond that [19:10] I can take a look at this but I'm note sure what if anything (is posisble) to do about it. [19:11] well, I may not be the best person to summarize what they said, but since repeated invitations to discuss that in public list failed, you'll have to do with my badly misinterpreted report, sorry [19:12] yod: You're probably not misrepresenting it; I've heard that one before. [19:12] In any case, it's orthogonal to the issue at hand. [19:12] yep [19:12] probably, yes [19:13] As is Bug #297 BTW. [19:13] http://www.w3.org/Bugs/Public/show_bug.cgi?id=297 [19:13] is it? I thought it was, even if marginally, related [19:14] in any case I don't think we'll solve either #297 or the issue for 0.6.5 [19:14] agreed? [19:14] y [19:14] Agreed. Well, 297 may be a quick fix or it may be almost impossible (probably not in the middle). [19:15] yod, can we ACTION xover to document branch mess on public-qa-dev@? [19:15] s/mess/plan/, but yes [19:16] (what I want to know is what branches are there, purpose of the branch, what is in there, what is its status) [19:16] *** xover AI: Document current and planned CVS Branch layout. [19:16] *** yod happy with better documentation of current state, AND future [19:16] *** yod happy with idea of a warm bed, too ADJOURNED (2 hours)