Time and Location
Thursday, 2007-08-30 in #adium-devl
| PDT | MDT | CDT | EDT | CEST |
| 6 PM | 7 PM | 8 PM | 9 PM | 3 AM |
Agenda
- Buildbot - Colin
- In the log, I talk about Buildbot a bit. Feel free to email me with any questions -Colin
- Crucible v. Reviewboard - Colin
- Note: We decided on Reviewboard, since it does what we need. I'll email thomas to see about getting it set up. -Colin
- Growl 1.1 coming out shortly - Chris - I will not be at the meeting, Growl 1.1 is coming out soon, just a heads up.
- Parental Controls - Alan
- Alan was a no-show. :(
Log
18:02 < edr1084> people ready to get this show on the road?
18:04 < edr1084> The_Tick had something come up at work so he won't be joining us
18:05 < jas8522> Oui
18:05 < edr1084> cbarrett: I believe the first item is yours if you'd like to get
things started
18:07 < jas8522> :|
18:07 < edr1084> I have a feeling that tonight is going to be a bust since not many
seem to be here...
18:07 < jas8522> it appears so
18:07 < Newtylicious_> I'm here!
18:08 -!- Newtylicious_ is now known as Newtylicious
18:08 < jas8522> new and improved, without an underscore!
18:08 < edr1084> cbarrett_work: around?
18:09 < TownCrier> adiumtrac: Ticket #7741 (defect closed): Command + _____ keyboard
shortcuts don't all work
<http://trac.adiumx.com/ticket/7741#comment:3>
18:10 < edr1084> well there's no alan either, so bullets #2 and #3 have nothing to go
with them...
18:10 < edr1084> hrmm
18:10 < edr1084> anyone who IS here have anything to discuss?
18:11 < cbarrett_work> kind of.
18:11 < cbarrett_work> Alright
18:11 < cbarrett_work> So
18:11 < cbarrett_work> 1.
18:12 < cbarrett_work> I'm assuming 1 is talking about Buildbot?
18:12 < cbarrett_work> Waiting for the machine to come in so I can start installing
and configuring that.
18:12 < edr1084> yup
18:12 < cbarrett_work> Anyone have any questions about it?
18:12 < cbarrett_work> I can answer them.
18:12 < edr1084> can you give a brief overview of how it will work?
18:13 < cbarrett_work> sure
18:13 * durin42 staggers in from his number theory homework
18:13 < TownCrier> adiumtrac: AdiumMeetings/2007-08-30 edited by cbarrett
<http://trac.adiumx.com/wiki/AdiumMeetings/2007-08-30>
18:13 < CIA-29> evands * r20836 /trunk/appcast-beta.xml:
18:13 < CIA-29> 1.1.2b2 appcast
18:13 < CIA-29> <http://trac.adiumx.com/changeset/20836>
18:13 -!- gwillen [n=gwillen@pool-141-158-89-228.pitt.east.verizon.net] has joined
#adium-devl
18:14 < cbarrett_work> Every time you commit (acutually it waits 30s to batch things
or if you forget a file or whatnot -- that lenght of time is
configurable)
18:14 < cbarrett_work> buildbot does things.
18:14 < cbarrett_work> Normally, you have it check out the source (or update its copy)
and do a build.
18:14 < cbarrett_work> There's a master/slave relationship there, so the build master
can be a linux machine or whatever
18:15 < cbarrett_work> the builder then does the steps (in this case checkout, clean,
build)
18:15 < cbarrett_work> sends that information back to the master
18:16 < cbarrett_work> which then puts something in a database or updates a webpage or
whatever, and you get a nice looking page telling you if your
commit built or not.
18:16 < edr1084> so say evan gets REALLY bored and averages a commit every other
minute for an hour? it's going to be rebuilding every 30 sec?
18:16 < hal2k> shouldn't it build once per day only?
18:16 < cbarrett_work> No
18:16 < durin42> I would hope the delay is configurable
18:16 < durin42> hal2k: no way
18:16 < cbarrett_work> 18:14 < cbarrett_work> Every time you commit (acutually it
waits 30s to batch things or if you forget a file or whatnot
-- that lenght of time is configurable)
18:17 < cbarrett_work> :P
18:17 < cbarrett_work> anyway
18:17 < cbarrett_work> hold on.
18:17 < durin42> if it built more often than once a day
18:17 < cbarrett_work> shh
18:17 * durin42 stfu's and returns to homework for a moment
18:17 < hal2k> durin42: don't forget that a clean build of adium on a regular machine
takes about half an hour
18:17 < cbarrett_work> hal2k: Right, hold on.
18:17 < cbarrett_work> Just please wait until I'm done OK?
18:18 -!- gwillen [n=gwillen@pool-141-158-89-228.pitt.east.verizon.net] has quit
[Client Quit]
18:18 < cbarrett_work> You can also have it run tests. This way, a machine running
tests can pull the tests from a machine that just does builds
and run the tests there, allowing the builder to go back and do
another compile if necessary.
18:18 < cbarrett_work> All connections from the slave->master are outbound. no inbound
connections
18:19 < cbarrett_work> Makes it *very* easy to add machines that might be in odd
places (andre john mas's machine for example)
18:20 < cbarrett_work> Here's an example of a buildbot setup. This is the python
buildbot page for python trunk (what will become python 2.6)
18:20 < cbarrett_work> http://www.python.org/dev/buildbot/trunk/
18:21 < cbarrett_work> columns are individual machines. vertical axis is time, going
backwards into the past (so NOW is at the top)
18:21 < cbarrett_work> What does this gain us?
18:21 < cbarrett_work> The idea here is something called Continuous Integration.
18:21 < cbarrett_work> http://en.wikipedia.org/wiki/Continuous_Integration
18:22 < cbarrett_work> Basically, you want to make sure that your tests ("does the
source tree compile?" is a test)
18:22 < cbarrett_work> get run very often, so you can track down regressions very
quickly.
18:23 < cbarrett_work> It also helps that when you find the error or fault with
continuous integration, the developer has the code already in
their head -- they don't have to go re-learn and understand the
code again, it's all up there.
18:23 < cbarrett_work> The more tests we write, the bigger advantage we are going to
see from this.
18:23 < cbarrett_work> Anyway, I'm about done.
18:23 < cbarrett_work> Any questions?
18:24 < cbarrett_work> Oh one last thing: Buildbot is written in python, and SUPER
easy to hack / extend, so we can get it doing whatever we want.
18:25 < edr1084> so back to my question, if it's in the middle of a test and another
commit comes in, does it just queue them up and and run again when
it's done with it's current round?
18:25 < cbarrett_work> if there are more commits, it'll get whatever is latest.
18:25 < cbarrett_work> so if you commit r4, and it starts building
18:26 < cbarrett_work> and then commit r5, r6, r7 and r8 while it's building
18:26 < cbarrett_work> when it's done, it will pull r8 and build and test that.
18:26 < cbarrett_work> (rX meaning revision numbers)
18:26 < edr1084> alright, cool
18:27 < cbarrett_work> the point isn't to test each individual commit -- it's to make
sure that your tests run often enough that you can catch
regressions or problems as they happen.
18:28 < gbooker> so, if r8 fails the test, does it test r5, 6, and 7 to see which
broke it?
18:28 < cbarrett_work> no, that's up to you.
18:29 < cbarrett_work> You could probably write actions to do that
18:29 < gbooker> would be nice to know which broke it in such a case
18:29 < hal2k> moving adium from a hack-around project to one with a proper
development scheme won't be easy
18:29 < cbarrett_work> hal2k: Doesn't mean it's not worth it.
18:29 < gbooker> I think it is worth it
18:30 < hal2k> cbarrett_work: agreed
18:30 < gbooker> maybe we need an SoC project next year to write tests
18:30 < cbarrett_work> Mac-arena started that
18:30 < hal2k> we already had one this year I think?
18:30 < cbarrett_work> hal2k: it failed, the guy got an internship at apple
18:30 < gbooker> ah yes, forgot
18:30 < hal2k> ah :(
18:30 < hal2k> boo apple
18:30 < cbarrett_work> Peter did the initial legwork, it's now *super* easy to add
tests.
18:31 < cbarrett_work> I'd like to get up some documentation about how to use OCUnit
to write tests for Adium on the wiki.
18:31 < edr1084> cbarrett_work: so this is building for testing purposes, but will it
also give us the option of a real build which we could then download
and use for testing?
18:31 < gbooker> good to hear
18:31 < cbarrett_work> edr1084: It can also do that yes.
18:31 < hal2k> ofri wrote some framework for UI tests, too. I guess we have to
integrate that
18:32 < durin42> I don't know that ofri's framework actually does test UIs yet
18:32 < durin42> I can't recall
18:32 < durin42> I know it parallelized unit tests
18:33 < cbarrett_work> edr1084: We can also get this set up to produce our release
builds.
18:33 < edr1084> ah, nice
18:33 < cbarrett_work> edr1084: Instead of triggering when you commit, it can do it
when you ssh to a machine and kick something off, or watch a
specific file in the repo, or whatever.
18:33 < hal2k> durin42: I think ofri finished it
18:33 < cbarrett_work> then a different set of steps could occur
18:33 < edr1084> I was thinking along the lines of saving me compile time if I need to
get someone a non-deployment build for debug logging and such
18:34 < cbarrett_work> including making the DMG, uploading it to cachefly, putting the
changelog on the website
18:34 < cbarrett_work> updating beta.html
18:34 < cbarrett_work> etc
18:34 < edr1084> awesome
18:34 < cbarrett_work> it's just a python program using twisted to do networking
18:34 < cbarrett_work> the possiblities are literally limitless.
18:34 < durin42> cbarrett_work: build me skynet
18:34 < cbarrett_work> durin42: Simple Matter Of Programming
18:35 * durin42 scoffs that a self-aware program falls under SMOP
18:35 < The_Tick> 1 was not about buildbot
18:35 < The_Tick> and hi
18:35 < cbarrett_work> I had no idea what you were talking about then :)
18:35 < The_Tick> crucible versus chip's thing
18:35 < cbarrett_work> Oh.
18:35 < cbarrett_work> I've tried to get chip & david to talk
18:35 < cbarrett_work> but so far no connection
18:35 < durin42> chip's thing = reviewboard
18:36 < cbarrett_work> I don't know crucible at all, and I have not used ReviewBoard
for more than 5 miutes
18:36 < The_Tick> since you guys handle the patch approval/denial
18:36 < The_Tick> would you mind installing both
18:36 < The_Tick> and seeing which you like more?
18:36 < durin42> I'm rather competant with Django, FWIW, and that's what reviewBoard
is done with
18:36 < The_Tick> I'm not going to use the system much
18:36 < The_Tick> just setup and fix it if it breaks
18:36 < The_Tick> so up to you guys
18:36 < cbarrett_work> The_Tick: I think we want to go with ReviewBoard, personally.
18:37 < The_Tick> well, let's try it locally first
18:37 < The_Tick> since I don't have a box to try it on
18:37 < The_Tick> up at nr
18:37 < durin42> cbarrett_work: that's my feeling too
18:37 < durin42> I'm really cozy w/ python and django these days
18:37 < cbarrett_work> what's Crucible in?
18:37 < cbarrett_work> Java?
18:38 < cbarrett_work> Yeah
18:38 < durin42> it's not open source
18:38 < durin42> so we can't fix0r it
18:38 < cbarrett_work> yea
18:38 < cbarrett_work> We know Chip, durin42 can hack Django for sure, me and M-a both
grok python.
18:38 < edr1084> java ftl!
18:39 < durin42> I hate OSS zealotry more than most, but I'd be more comfortable with
a code review product I can hack on
18:39 < cbarrett_work> To avoid disappointment note that Crucible currently only works
with CVS, Subversion, and Perforce. Crucible also does not yet
support pre-commit reviews, that is, the code must already be
checked in to your repository to be included in a review.
18:39 < cbarrett_work> That's a no-go for us then.
18:39 < cbarrett_work> We need to be able to post patches on it
18:39 < durin42> I would expect that we could make reviewboard work with gvn
18:39 < The_Tick> grr, this router must die
18:39 < durin42> which could *really* clean up our review stuff
18:39 < The_Tick> my problem with reviewboard
18:40 < The_Tick> is if crucible does what we need
18:40 < durin42> even allow for RTC on stuff if we want, which I've desired for some
changes
18:40 < The_Tick> we shouldn't spend time hacking on reviewboard
18:40 < The_Tick> but we don't know which is better
18:40 < cbarrett_work> It doesn't -- it can't do reviews for code not in the tree.
18:40 < The_Tick> are you sure?
18:40 < cbarrett_work> To avoid disappointment note that Crucible currently only works
with CVS, Subversion, and Perforce. Crucible also does not yet
support pre-commit reviews, that is, the code must already be
checked in to your repository to be included in a review.
18:40 < cbarrett_work> that is, the code must already be checked in to your
repository to be included in a review.
18:40 -!- MachinaX^4 [n=karl@111.sub-75-208-25.myvzw.com] has joined #adium-devl
18:40 < The_Tick> does reviewboard do that?
18:40 < cbarrett_work> For sure.
18:41 < The_Tick> alright, is that the only thing we need it for?
18:41 < MachinaX^4> reviewboard do what?
18:41 < MachinaX^4> ooh, meetings and minutes
18:41 < cbarrett_work> pre-commit review
18:42 < cbarrett_work> Crucible does not do pre-commit review, RB does.
18:42 < The_Tick> I think it's the only thing we need it for
18:42 < The_Tick> but double checking
18:42 < cbarrett_work> http://code.google.com/p/reviewboard/wiki/UserBasics
18:42 < cbarrett_work> Review Board is designed for code review processes which occur
before a change is committed to version control. The general
workflow we designed it for is this:
18:42 < The_Tick> colin, stop
18:42 < The_Tick> is that the only thing we need it for?
18:42 < The_Tick> yes/no
18:42 < The_Tick> if yes, we're going reviewboard or nothing
18:42 < cbarrett_work> Um, it doesn't do anything else except make code review easier.
18:43 < The_Tick> then we're going with that over crucible
18:43 < The_Tick> problem solved
18:43 < MachinaX^4> is crucible also on google code?
18:43 < The_Tick> no
18:43 < cbarrett_work> MachinaX^4: No, it's closed source.
18:43 < The_Tick> MachinaX^4: please review the log
18:43 < cbarrett_work> The_Tick: he just joined
18:43 < MachinaX^4> I just got here
18:43 < The_Tick> when it's posted
18:43 < cbarrett_work> ah
18:43 < The_Tick> I know
18:43 < MachinaX^4> ah
18:43 < The_Tick> I have to eat in 2 minutes
18:43 < The_Tick> is there anything else needing me?
18:43 * MachinaX^4 goes to work on his little framework
18:44 < edr1084> The_Tick: just the growl note, but I think that speaks for itself
18:44 < The_Tick> aye
18:44 < edr1084> unless you've heard from alan
18:44 < cbarrett_work> oh *hot*
18:44 < The_Tick> localizations for 1.1 are deadlined for next wed
18:44 < The_Tick> after that, it's just finalizing release stuff
18:44 < cbarrett_work> there's a shellscript to post code for review.
18:44 < The_Tick> evan's been a huge help during the last 2 weeks with it
18:44 < The_Tick> edr1084: I have not
18:45 < The_Tick> but this meeting was a mess
18:45 < The_Tick> due to me
18:45 < durin42> cbarrett_work: I'm hoping to patch gvn to make it in-client, so you
could hit up gvn review and then it'd post it
18:45 < The_Tick> anyhow, we'll have a better one next week
18:45 < cbarrett_work> gvn?
18:45 < durin42> cbarrett_work: gvn.googlecode.com
18:45 < The_Tick> later guys :)
18:46 < cbarrett_work> durin42: hot!!
18:47 < durin42> I was stoked when I found out they'd open sourced it
18:47 < cbarrett_work> durin42: write up a blogpost/wiki page about how to use it.
18:47 < cbarrett_work> I'm very interested
18:47 < cbarrett_work> esp. with svn1.5 merging
18:48 < durin42> yeah
18:48 < durin42> gvn is a lot less useful without 1.5's merging
18:48 < durin42> IIRC it *needs* it
18:51 < cbarrett_work> okay posting the log
Past Meetings
The time machine is down for maintenance.
