Attached is the IRC log from todays meeting. Thanks everyone for showing up!

-- leif

Conversation with #ts-weekly-dev at Thu 18 Nov 2010 03:03:03 AM MST on 
zw...@irc.freenode.net (irc)
(03:03:03 AM) #ts-weekly-dev: The topic for #ts-weekly-dev is: Next IRC meeting 
is Thursday 11/18 at 10am PST
(03:03:03 AM) #ts-weekly-dev: mode (+o zwoop) by ChanServ
(08:58:29 AM) amc [~...@c-98-212-133-59.hsd1.il.comcast.net] entered the room.
(08:58:46 AM) amc left the room ("Leaving").
(10:33:40 AM) jumby [~...@c-24-4-229-9.hsd1.ca.comcast.net] entered the room.
(10:33:40 AM) #ts-weekly-dev: mode (+o jumby) by ChanServ
(10:56:51 AM) postwait [~postw...@wifi.omniti.com] entered the room.
(11:00:04 AM) andrewhsu [~andre...@nat/yahoo/x-jkmaocuyuezdsqbw] entered the 
room.
(11:00:40 AM) amc [~...@c-98-212-133-59.hsd1.il.comcast.net] entered the room.
(11:02:44 AM) zwoop: is everyone "here" ?
(11:02:55 AM) jMCg [~h...@unaffiliated/jmcg] entered the room.
(11:03:00 AM) amc: Present.
(11:03:07 AM) jMCg is now known as igalic
(11:03:32 AM) zwoop: jplevyakg:  ?
(11:03:52 AM) zwoop: lets wait a few more minutes, then get started
(11:04:12 AM) amc: Any suggested topics?
(11:04:22 AM) zwoop: I sent out a brief agenda
(11:04:28 AM) zwoop: check your spam folder ;)
(11:04:54 AM) zwoop: let me paste it here
(11:05:51 AM) ming_zym [~...@nat/yahoo/x-iahqumjrczdwwfyz] entered the room.
(11:06:01 AM) amc: I found it. Too much email.
(11:06:07 AM) zwoop: ah, ok
(11:06:13 AM) mohan_zl [~mo...@121.0.29.226] entered the room.
(11:06:23 AM) zwoop: was hoping jplevyakg would get on
(11:06:50 AM) igalic: Yeah, I really was hoping we'd have a smart guy..
(11:06:53 AM) zwoop: lets start at 10:10am no matter what
(11:06:55 AM) qianshi [~chatzi...@114.251.86.0] entered the room.
(11:07:01 AM) zwoop: igalic: indeed
(11:07:05 AM) zwoop: well, we have amc
(11:07:20 AM) amc: That's what really matters.
(11:07:24 AM) zwoop: Did everyone see the agenda ?
(11:07:39 AM) zwoop: since andrewhsu is here, we should add on the IPv6 merge 
as well
(11:07:43 AM) zwoop: I'll add that to the end
(11:08:32 AM) postwait: my attention span is approaching its limit already.
(11:08:37 AM) zwoop: oh boy
(11:08:43 AM) zwoop: well, lets get started then
(11:09:04 AM) zwoop: item 1: Time for this meeting. Does this work for everyone 
?
(11:09:26 AM) zwoop: The proposal is that we'd do these meetings on a weekly 
basis, unless otherwise canceled (e.g. for holidays)
(11:09:26 AM) igalic: Mostly.
(11:09:30 AM) postwait: It's challenging. and hour earlier or two+ hours later 
would be best for me.
(11:09:42 AM) postwait: the day of the week doesn't matter so much.
(11:10:12 AM) igalic: That would be 9/8 PST, do these guys get up early?
(11:10:16 AM) zwoop: The weekday was sort of set by John Plevyak (jplevyakg) 
too bad he's not here
(11:10:37 AM) zwoop: I think 9am PST is the earliest we could expect the CA 
hippies to get up
(11:11:06 AM) zwoop: much later will make it hard for the europeans (and our 
friends in China)
(11:11:20 AM) zwoop: igalic: what time is it now for you ?
(11:11:24 AM) igalic: 19:11
(11:11:33 AM) zwoop: yeah, so seems unfair to go much later than this
(11:11:46 AM) postwait: ok
(11:11:52 AM) postwait: 9:30am PST?
(11:12:23 AM) zwoop: so, lets propose 9.30am PST either Thursday or Wednesday ? 
Anyone have a problem if we moved this to Wedneday (I'll have to check with 
jplevyakg too)
(11:12:34 AM) igalic: Nick said that 6 hours later would work for him, on 
Thursdays anyway. The other days he's more flexible. But also sober.
(11:12:43 AM) postwait: Thursday is better for me.
(11:12:59 AM) postwait: I have Wednesday lunch meetings... and this is lunch 
time.
(11:13:04 AM) zwoop: ah
(11:13:05 AM) igalic: I have a fixed appointment Wednesdays.
(11:13:07 AM) zwoop: Tuesday ?
(11:13:13 AM) postwait: fine
(11:13:30 AM) zwoop: so, 9.30am PST Tuesday or Thursday, depending on what John 
says ?
(11:13:33 AM) zwoop: Any objections ?
(11:13:56 AM) zwoop: done
(11:14:05 AM) zwoop: Item 2: Bylaws
(11:14:16 AM) zwoop: This got sort of stalled, with some input from pquerna and 
a few others
(11:14:23 AM) igalic: I'd go with Paul's suggestion and leave it default.
(11:14:26 AM) zwoop: should we just bench bylaws for now, and assume that we 
can resolve it ?
(11:15:01 AM) postwait: I'd prefer to leave them unaltered.
(11:15:03 AM) igalic: I don't really think there's much to resolve, it works 
out quite fine so far - or did you hit any resistance?
(11:15:11 AM) zwoop: nope, no resistance
(11:15:13 AM) amc: I would like to have the bylaws, just as a reference if 
nothing else.
(11:15:28 AM) zwoop: this came up because other projects having issues, and 
they didn't have bylaws describing how to resolve it
(11:16:29 AM) igalic: zwoop: which projects, what issues?
(11:17:03 AM) zwoop: maybe I should cancel the vote, and do a new vote with two 
options:
(11:17:03 AM) zwoop: [] Adopt our Bylaws as describe in the WIki page
(11:17:03 AM) zwoop: [] No project bylaws, i.e. only use the minimum bylaws 
dictated by the ASF
(11:17:21 AM) zwoop: igalic: Not sure it's appropriate to go into details here, 
since they haven't been aired on public lists
(11:17:30 AM) igalic: ACK.
(11:17:57 AM) zwoop: I see both pquernas point, and the idea of having the 
Bylaws there "just in case"
(11:18:08 AM) zwoop: if no one disagrees, let me rephrase the vote, and start 
it over ?
(11:18:25 AM) postwait: yes. I'll vote for the ASF bylaws. KISS.
(11:18:30 AM) igalic: +1
(11:18:33 AM) zwoop: :)
(11:18:42 AM) zwoop: (the vote will happen on email :)
(11:18:52 AM) postwait: indeed.
(11:18:53 AM) zwoop: any other thoughts on the bylaws, or move on ?
(11:19:03 AM) postwait: second moving on.
(11:19:10 AM) amc: Move on.
(11:19:20 AM) zwoop: Item 3: Bug triaging for v2.1.5 / v3.0
(11:19:25 AM) zwoop: we have a *lot* of bugs open
(11:19:40 AM) zwoop: I have two suggestions
(11:19:52 AM) zwoop: either we go through all bugs in IRC
(11:20:09 AM) zwoop: or, everyone goes in and triages the bugs as they think is 
appropriate (e..g move them, close them, assign them etc.)
(11:20:53 AM) zwoop: the goal right now has to be to make a rock solid, stable 
v3.0 release, v2.1.5 is the next step in that evolution, quite possible we'll 
need a v2.1.6 release as well
(11:21:33 AM) zwoop: any thoughts ?
(11:21:50 AM) amc: I can't imagine going through the bugs here will work out 
well.
(11:21:57 AM) postwait: agreed
(11:21:59 AM) zwoop: agreed
(11:22:13 AM) amc: The question is how to get people (like me) to go through 
the bugs.
(11:22:19 AM) zwoop: it means everyone have to step up to the plate and comment 
/ assign / move etc. on the bugs
(11:23:10 AM) zwoop: I personally have too many bugs assigned to me, so I'll 
probably release a few of those into the public
(11:24:07 AM) zwoop: silence :)
(11:24:12 AM) postwait: as always.
(11:24:32 AM) igalic: We're all looking at the bugs (for the first time in 
weeks)
(11:24:33 AM) zwoop: There are a few bugs that I think are more serious than 
others, I'll start off by increasing the severity on those
(11:24:35 AM) amc: I will go through the bugs this week before I leave.
(11:24:53 AM) zwoop: alright, as long as we all chip in and do a little, we can 
make progress
(11:25:02 AM) zwoop: the list just looks scary big right now for v2.1.5
(11:25:10 AM) zwoop: should I make a v2.1.6 release target, so we can move some 
there ?
(11:25:19 AM) amc: Yes.
(11:25:40 AM) amc: I can't see making significant API changes and not having a 
release after that for cleanup / fixes.
(11:25:42 AM) igalic: You can probably move most of the non critical bugs to 
2.1.6
(11:25:51 AM) zwoop: amc:  agreed
(11:26:04 AM) zwoop: which brings up item 4: releases
(11:26:11 AM) andrewhsu: what is the general timeline for 2.1.6 and 3.0?
(11:26:30 AM) andrewhsu: oops, spoke too soon?
(11:26:33 AM) zwoop: so, it sounds like we should aim for:
(11:26:33 AM) zwoop: v2.1.5; ~december
(11:26:33 AM) zwoop: v2.1.6: ~january
(11:26:33 AM) zwoop: v3.0: ?? (February) ?
(11:26:40 AM) zwoop: andrewhsu: excellent timing ;)
(11:27:03 AM) amc: Yeah, that sounds like a good baseline.
(11:27:15 AM) zwoop: I'm thinking a monthly "point" release until we get a 
stable trunk for v3.0
(11:27:32 AM) zwoop: which means, we have to convince everyone to upgrade to 
the latest unstable releases as soon as they are released, to get mileage
(11:28:11 AM) zwoop: everyone ok with these schedules ?
(11:28:26 AM) amc: +1
(11:28:39 AM) andrewhsu: so, v3.0 is movable depending on whether we have a 
2.1.7 in feb, 2.1.8 in mar, etc?
(11:28:48 AM) igalic: I'd say if something's horrendously broken, we can 
release inbetween.
(11:28:56 AM) postwait: schedule sounds good
(11:29:01 AM) zwoop: I think so, at this point, we don't have enough QA to sign 
up for a fixed release date for v3.0
(11:29:22 AM) andrewhsu: that's fine
(11:29:24 AM) zwoop: igalic: yeah of course, earlier releases is fine
(11:29:54 AM) andrewhsu: better to flex on the timeline if we lack on the 
resources in order to keep quality
(11:30:04 AM) zwoop: I would however like to see all API "breaking" changes in 
for v2.1.5 (which is my next topic)
(11:30:24 AM) zwoop: item 5: API changes
(11:30:45 AM) zwoop: We've already done a bunch, and I'd like to encourage 
everyone who's worked with the APIs to make changes (or file bugs) asap
(11:31:15 AM) zwoop: everyone should also be aware that all public APIs (with 
two exceptions for deprecated Stats APIs) are now prefixed with TS
(11:31:19 AM) postwait: to get a largely stable API for 2.1.5?
(11:31:25 AM) zwoop: yeah
(11:31:36 AM) amc: Another goal should be consistency. That makes the API much 
easier to use.
(11:31:48 AM) zwoop: it's still OK to make API changes after v2.1.5 (but before 
3.0), but the sooner we get them in as soon as possible
(11:31:52 AM) zwoop: amc: Agreed!
(11:32:06 AM) zwoop: There's one bug oustanding which deals with inconsistent 
return codes for example
(11:32:19 AM) andrewhsu: if api changes, should we bump minor rev num so we 
call it v2.2?
(11:32:21 AM) amc: Yes, I should take charge of that.
(11:32:23 AM) zwoop: and I've changed a few names already , and will change a 
few more
(11:32:42 AM) igalic: andrewhsu: no. 2.2 would suggest it's stable.
(11:32:59 AM) andrewhsu: oh yeah, thats right...odds and evens
(11:32:59 AM) zwoop: andrewhsu: well, I don't know if we care within the 
"unstable" release (I don't think we promise anything within an unstable 
release), and the next stable release will be v3.0
(11:33:16 AM) zwoop: v2.2 is "canned" :)
(11:33:38 AM) andrewhsu: ok
(11:33:52 AM) zwoop: so, please take into considreation that API changes should 
have priority when assigning / moving / targeting the bugs during triage
(11:34:50 AM) zwoop: as far as I'm concerned though, it's free for all on 
changing APIs, but, we obviously don't want to make a massive change that risks 
making everything completely unstable (e.g. changing the APIs from C to C++ 
would be a bad idea)
(11:35:03 AM) amc: Dang!
(11:35:13 AM) zwoop: lol
(11:35:20 AM) zwoop: any other thoughts / concerns about APIs ?
(11:35:28 AM) amc: I would definitely like to shift more of them to always 
return a status code and any return parameters as in/out style.
(11:35:41 AM) amc: Like your pivate data API changers.
(11:35:48 AM) zwoop: yes
(11:36:14 AM) amc: It can be a bit more of a pain but it would be very nice to 
have every call in that style.
(11:36:20 AM) zwoop: I totally agreed
(11:36:40 AM) amc: Cool.
(11:36:44 AM) zwoop: I was pondering on that myself when looking at the private 
data APIs, I didn't do it quite consistently
(11:36:55 AM) zwoop: but, if we agree to make such a change, we should make it 
100% consistent
(11:36:59 AM) zwoop: I'm +1 on that
(11:37:02 AM) amc: Anyone else?
(11:37:15 AM) zwoop: amc: Can you make sure to file  bug on it ?
(11:37:19 AM) amc: OK.
(11:38:00 AM) zwoop: It does look a little awkward in apis returning POD types 
(like int), but there's something to be said about consistency
(11:38:33 AM) amc: Yes, it's a tradeoff, but well worth it IMHO.
(11:38:35 AM) zwoop: which is why I'm changin the getter setters to always be 
FooGet() and FooSet()
(11:38:45 AM) zwoop: and not like it was FooSetBar() and FooGetBar()
(11:38:58 AM) zwoop: (almost all APIs follows the Set() and Get() style
(11:39:04 AM) zwoop: alright, cool
(11:39:07 AM) zwoop: progress :)
(11:39:07 AM) amc: You can always put your own wrappers on the base API if you 
care enough.
(11:39:12 AM) zwoop: yep
(11:39:26 AM) zwoop: move on ?
(11:39:46 AM) zwoop: Item 6 Documentation
(11:40:05 AM) zwoop: it's a shame mlibbey isn't here, but we need to figure out 
what to do with docs, in particular the SDK docs
(11:40:13 AM) amc: I like Doxygen a lot.
(11:40:22 AM) zwoop: (since they are mostly rendered useless right now)
(11:40:37 AM) amc: There are large projects (such as QT) which use that.
(11:40:37 AM) zwoop: amc: Doxygen for the SDK docs too ?
(11:40:50 AM) igalic: zwoop: does your awk/sed/perl script work for the docs 
too?
(11:41:03 AM) zwoop: igalic: I'd imagine so
(11:41:09 AM) amc: For SDK reference.
(11:41:11 AM) postwait: Doxygen makes good sense for API docs.
(11:41:15 AM) bvierra [~bvie...@netblock-208-127-255-129.dslextreme.com] 
entered the room.
(11:41:18 AM) zwoop: with the exception of INKStat and INKCoupleStat
(11:41:24 AM) amc: But you could create header files which aren't compiled for 
"white paper" type of stuff.
(11:41:33 AM) zwoop: if we want to do a "script" change, we can hack up a 
better perl script
(11:41:42 AM) amc: I've done that internally, for the Doxygen "main page" text.
(11:41:57 AM) zwoop: can you include images etc. in the Doxygen "markup" ?
(11:42:02 AM) zwoop: and what about all the code examples ?
(11:42:17 AM) amc: You can use raw HTML in Doxygen, so technically yes to 
images.
(11:42:28 AM) amc: For code examples, I find @code @endcode to work well.
(11:42:51 AM) igalic: amc: wouldn't that mean that the documentation would be 
maintained in the source code files?
(11:43:08 AM) zwoop: The thing that concerns me though, is that a good 50% at 
least of the current SDK docs aren't tied to a specific API (i.e. they are 
describing hwo things works )
(11:43:08 AM) amc: Yes.
(11:43:29 AM) amc: You could split reference / general and use Doxygen for the 
reference.
(11:43:31 AM) zwoop: we'd just put that in some "dummy" include files ?
(11:43:56 AM) igalic: That sounds scray to maintain..
(11:44:09 AM) amc: The question is, how easily can you cross reference from the 
general to the reference? If the examples uses the method "getStuff", it's very 
nice if that's a link to the reference for getStuff.
(11:44:10 AM) zwoop: if we do that, why not just rip out the "reference" part 
from the SDK, and replace that with the Doxygen generated docs?
(11:44:27 AM) igalic: Especially the raw HTML thing, it's what I was trying to 
get away from with the CMS, because if you need to describe how things work, 
you don't do that in HTML, you just write stuff.
(11:44:33 AM) zwoop: The SDK is roughly 200 pages of "text" and the rest is 
reference
(11:44:56 AM) amc: I am find with having Doxygen only for the reference, and 
something else for the general text.
(11:44:59 AM) igalic: I'm +1 to put the reference in doxygen, but not the 
"text".
(11:45:06 AM) amc: s/find/fine/
(11:45:30 AM) zwoop: the win to me having Doxygen for the reference part is 
that the developer can more easily update that on the fly, while the "fluffy" 
text gets maintained by the docs expert in some more manageable form
(11:45:54 AM) amc: Works for me.
(11:46:12 AM) zwoop: igalic: Can you write up a proposal how we would proceed 
with this?
(11:46:19 AM) amc: Although I think the cross reference issue needs to be 
addressed.
(11:46:31 AM) zwoop: Yes
(11:46:45 AM) igalic: amc: from docs to doxygen or vice versa or both?
(11:46:57 AM) zwoop: my concern is that for a v3.0 release to happen, we 
absolutely must have an updated SDK docs, and preferably (but less important) 
an updated Admin Guide
(11:47:06 AM) amc: From docs to doxygen. So that examples in the general text 
can link directly to the method in the reference.
(11:47:35 AM) andrewhsu: do we have a doxygen generation output up on 
apache.org?
(11:47:41 AM) zwoop: andrewhsu: yes
(11:48:12 AM) zwoop: http://ci.apache.org/projects/trafficserver/trunk/doxygen/
(11:48:30 AM) igalic: We could hack something up where you write, say  
{{doxygen:someFancyClass}} and that generates a link to the current doxygen 
thingy -- if anyhow possible.
(11:49:01 AM) amc: The code would be simple (I have some I can donate) it's the 
build process that's harder.
(11:49:31 AM) amc: That is, if you guys are OK with post-posting with Perl.
(11:49:45 AM) igalic: Perl is fine. Infra loves Perl.
(11:50:15 AM) zwoop: igalic: Make sure you get mlibbey involved in any proposal 
too
(11:50:40 AM) igalic: zwoop: yeah. I was hoping I would catchin him this week, 
before the meeting.
(11:50:55 AM) zwoop: you ok with taking lead on this for now ?
(11:50:58 AM) amc: I'll get a write up on my Perl code for that this week. It's 
basically a WikiVar style processor which lets you hook arbitrary Perl 
functions to the WikiVar uses.
(11:51:02 AM) zwoop: (it's a high priority IMO)
(11:51:56 AM) zwoop: we're almost out of time
(11:52:03 AM) igalic: zwoop: I am. So, the basic idea is:
(11:52:46 AM) igalic: Separate Reference from Fluff, put Reference in Doxygen. 
Link from Fluff to Doxygen via amc's Perl.
(11:53:00 AM) zwoop: seems reasonable
(11:53:09 AM) amc: Seems like a fine base plan.
(11:53:26 AM) zwoop: anything else on docs ?
(11:54:00 AM) zwoop: if not, there's only one "item" suggested for the open 
discussions
(11:54:01 AM) zwoop: IPv6
(11:54:09 AM) igalic: Oh, yeah: first step would be to sed them. That's all.
(11:54:15 AM) zwoop: andrewhsu: want to explain briefly what your plan is ?
(11:55:08 AM) andrewhsu: i havent touched it in several weeks so i'll rebase 
with latest code on trunk, and get a merge working between now and thanksgiving 
weekend
(11:55:33 AM) zwoop: this means we'd get it landed before v2.1.5 release
(11:55:35 AM) zwoop: right ?
(11:55:50 AM) andrewhsu: i'll drop it on trunk in one commit on thanksgiving 
time so i have spare time during that holiday to respond to any issues
(11:56:07 AM) zwoop: sounds good to me, anyone see a problem with this ?
(11:56:12 AM) igalic: How massive is the change?
(11:56:39 AM) andrewhsu: hang on, i'll get a approx line count from the branch 
point
(11:58:54 AM) andrewhsu: my estimate is patch will between 1500 and 2500 lines
(11:59:08 AM) andrewhsu: medium sized
(11:59:18 AM) jplevyakg: fyi Tues is good for me
(11:59:29 AM) zwoop: Excellent
(11:59:37 AM) zwoop: tenatively, Tuesdays 9.30am PST
(11:59:45 AM) jasong_at_apache 
[~jasong...@pool-108-16-62-204.phlapa.fios.verizon.net] entered the room.
(12:00:02 PM) zwoop: I actually have to jet, for another meeting, feel free to 
continue the IPv6 discussions (and anything else). Thanks everyone for joining 
in, I'll send out an email with the time for the next meeting as soon as I have 
it. The logs from this meeting will be posted to dev@ as well.
(12:00:16 PM) jasong_at_apache: doh i missed it
(12:00:31 PM) igalic: zwoop: also, the new vote.
(12:00:55 PM) andrewhsu: are there any pending commits that look to touch the 
socket code that i should be aware of in order to address during the ipv6 merge 
back to trunk?
(12:01:32 PM) amc: Potentially the WCCP branch, but I'll fix that on my end.
(12:01:48 PM) andrewhsu: ok
(12:01:54 PM) amc: I am desparately trying to get that to a comittable stage 
but not quite there yet.
(12:03:53 PM) igalic: Now that zwoop's gone we have, once again, silence.
(12:04:19 PM) jasong_at_apache: what came of the cms topic?
(12:04:37 PM) igalic: jasong_at_apache: we haven't touched it, mostly because 
Miles isn't here.
(12:04:51 PM) jasong_at_apache: gotcha
(12:05:11 PM) amc: I think we're done without zwoop.
(12:05:32 PM) igalic: jasong_at_apache: I've experimented with the CMS, and got 
the admin guide to a point where it's editable by normal humans, but the SDK 
docs are an order of magnitude more nasty in that regard.
(12:05:56 PM) jasong_at_apache: they've been that way forever :-P
(12:05:57 PM) igalic: One last thing, regarding Bugs from me:
(12:06:35 PM) jasong_at_apache: if anyone cares, i'll be putting out a fedora 
14 ec2 release shortly as soon as I can test it with load
(12:06:39 PM) igalic: This: https://issues.apache.org/jira/browse/TS-201 seems 
reasonable. If we adopt something like that, anyone can roll a new release
(12:07:18 PM) jasong_at_apache: looks like a great idea
(12:08:45 PM) amc: I don't know enough to comment usefully.
(12:08:47 PM) jasong_at_apache: ok i guess thats it lol
(12:09:28 PM) amc: Move to adjourn.
(12:09:49 PM) jasong_at_apache: +1 (sounded like everyone said what they wanted)
(12:10:03 PM) amc: Any objections?
(12:11:16 PM) amc: OK, I will usurp authority and declare the meeting closed.
(12:11:28 PM) amc: Thank you all for attending.
(12:11:36 PM) postwait: adios
(12:11:41 PM) postwait left the room.
(12:11:47 PM) amc left the room ("Leaving").
(12:12:00 PM) ming_zym left the room.
(12:12:02 PM) jasong_at_apache left the room.
(12:12:05 PM) igalic: o/~
(12:12:06 PM) igalic left the room.
(12:12:28 PM) mohan_zl left the room.
(12:16:44 PM) bcall [~ad...@71-215-142-203.ptld.qwest.net] entered the room.

Reply via email to