14:01:01 <quaid> #startmeeting
14:01:01 <ovirtbot> Meeting started Tue Jul 24 14:01:01 2012 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:01 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:10 <quaid> #meetingname oVirt Infrastructure weekly meeting
14:01:10 <ovirtbot> The meeting name has been set to 'ovirt_infrastructure_weekly_meeting'
14:01:20 <quaid> #topic roll call & agenda check
14:01:38 * mburns here
14:01:59 * quaid is here
14:02:09 <ovirtbot> 14[[07Category:Infrastructure14]]4 !10 02http://wiki.ovirt.org/w/index.php?diff=3951&oldid=3889&rcid=4047 5* 03Ekohl 5* (+0) 10Correct user page link
14:02:14 * ewoud here
14:02:22 <eedri> ewoud, i added loop to ignorel ist
14:02:31 <ewoud> eedri: cool
14:02:52 <quaid> http://wiki.ovirt.org/wiki/Infrastructure_team_meetings#2012-07-24
14:03:15 <quaid> Agenda
14:03:17 <quaid> Repo layout for the upcoming 3.1 release - rmiddle proposal Jenkins backups and code review - eedri Jenkins drive space issue. Jenkins migration from EC2 - status Push on ovirt-engine RPMs sync to ovirt.org - status Enabling Gerrit patches - everyone vs. limited All other business
14:03:51 <quaid> * Repo layout for the upcoming 3.1 release - rmiddle proposal
14:03:51 <quaid> * Jenkins backups and code review - eedri
14:03:51 <quaid> * Jenkins drive space issue.
14:03:51 <quaid> * Jenkins migration from EC2 - status
14:03:51 <quaid> * Push on ovirt-engine RPMs sync to ovirt.org - status
14:03:54 <quaid> * Enabling Gerrit patches - everyone vs. limited
14:03:57 <quaid> * All other business
14:03:59 <ewoud> I'd like to add puppet to the agenda
14:04:03 <quaid> ok
14:04:18 <eedri> i also have an update on parallel jobs
14:04:51 <ovirtbot> 14[[07Infrastructure team meetings14]]4 !10 02http://wiki.ovirt.org/w/index.php?diff=3952&oldid=3948&rcid=4048 5* 03Quaid 5* (+41) 10/* 2012-07-24 */ adding new agenda items from ewoud
14:05:08 <quaid> ok, first item
14:05:18 <quaid> #topic Repo layout proposal for 3.1 release
14:05:33 <eedri> i will start with updated status
14:05:48 <quaid> thx
14:06:14 <eedri> i reviewd current rpm jobs on jenkins for projects: ovirt-engine,cli,sdk,log-collector and vdsm
14:06:31 <eedri> we can add more projects if it is needed
14:06:44 <eedri> each job now creates both binary and src rpms
14:06:52 <mburns> eedri: node rpms are created as well already
14:06:59 <mburns> they're not explicit -rpm jobs
14:07:08 <eedri> mburns, right, forgot about that since it wasn't in 'rpm' view tab
14:07:17 <eedri> mburns, i'll add them as well
14:07:22 <mburns> eedri: if you want it split, i can do that...
14:07:42 <eedri> mburns, well.. let's see what is the best option and decide
14:08:02 <eedri> i've taken robert suggestion for directory structure and for now each job put all rpms under:
14:08:27 <eedri> rpms/3.1/nightly/fedora/17/[binary | src]
14:08:36 <mburns> eedri: point of splitting is so that we can consume the src tarball for multiple distros
14:09:00 <mburns> eedri: hmm, that's different than where i'm putting them
14:09:00 <eedri> mburns, ok, so in that case it sounds like we need to split it
14:09:22 <mburns> eedri:  no plan at the moment to add any other distros for node though
14:09:52 <eedri> i'm contemplating with myself... how much effort we should put in making jenkins jobs generic
14:09:59 <eedri> to work on all version/ distros
14:10:09 <eedri> or add new jobs per distro/ver as we progress
14:10:19 <mburns> eedri: IMO, we should:
14:10:26 <mburns> 1.  have a job that builds src rpm
14:10:29 <eedri> we can always 'refactor' jobs in the future and more demand comes
14:10:41 <mburns> 2.  separate jobs for each distro needed that builds packages based on src rpms
14:10:52 <mburns> err...
14:10:58 <mburns> s/src rpms/src tarballs
14:11:34 <eedri> mburns, why split the job for src and binary?
14:11:59 <eedri> mburns, it will duplicate much more jobs to maintain, why cant there be one job per distro to build both binary & src rpms
14:12:14 <mburns> eedri: src tarball in #1, src rpm and x86_64 rpms in #2
14:12:37 <eedri> mburns, ok, which projects requires tarball? other than ovirt-node
14:12:46 <ewoud> I agree with the split in the long term, but right now there is no distro support for non-rpm distros
14:12:51 <mburns> and when we get to debian packages, have another job that takes src tarball from #1 and builds .deb packages
14:13:17 <mburns> eedri: we're supposed to be posting .tar.gz or .tar.bz2 in src directory already, iiuc
14:13:37 <mburns> if we're not, then we need to do that
14:13:46 <eedri> mburns, for every project?
14:13:50 <mburns> eedri: yes
14:13:53 <eedri> mburns, along side src rpms?
14:13:56 <mburns> yes
14:14:14 <mburns> src rpms are really only applicable to rpm based distros
14:14:21 <eedri> #action add jobs to create .tar.gz or .tar.bz2 per project in ovirt
14:14:25 <mburns> and are useless for people who want to package for debian, etc...
14:14:56 <eedri> ok, my idea was that each of these rpm jobs will create and deploy the rpms to a common dir
14:15:14 <eedri> e.g. rpms/3.1/nightly/fedora/17
14:15:47 <eedri> then the job collecting it will copy the same dir structure from all jobs
14:15:53 <ewoud> I think we should have {src,rpms,deb}/{3.1,3.2,stable}/<specifics> in the long run
14:16:04 <ewoud> where stable is a symlink to 3.2
14:16:17 <mburns> eedri: that seems like we're moving a common task into multiple jobs
14:16:23 <ewoud> under specifics we should have whatever format the distro prefers
14:16:32 <mburns> ewoud: agreed
14:16:36 <eedri> mburns, i don't think so
14:16:54 <eedri> mburns, the nightly task of copying and publishing the rpms to ovirt.org repos is one task
14:17:06 <ewoud> RobertM: not here? think you added it to the agenda
14:17:10 <eedri> mburns, but each project should built its own rpms/tar independently
14:17:24 <quaid> it sounds as if we have more discussion to do
14:17:24 <eedri> mburns, so that people can still download rpms per commit from jenkins
14:17:25 <fabiand> mh, into what state do I set a bug if it is fixed by a patch from a different bug? modified?
14:17:29 <mburns> eedri: correct, build is separate, but why force directory structure on the build job
14:17:29 <quaid> are we going to be able to reach a consensus here?
14:17:36 <RobertM> Sorry was off reading up on log rotate
14:17:47 <eedri> mburns, ah.. just for convience, not a hard demand
14:18:08 <mburns> fabiand: yes, but send me the bz numbers as well, i want to look first
14:18:15 <eedri> mburns, how would the nightly job will  know where to copy the files from?
14:18:26 <fabiand> mburns, ok, 831668
14:18:48 <eedri> mburns, let's say we'll make it generic one day and it will work on multiple jobs
14:18:57 <mburns> eedri: *.src.rpm  *.tar.gz *.tar.bz2 into src
14:19:23 <eedri> mburns, we're planning on putting all rpms in a single flat dir?
14:19:43 <mburns> then based on the %dist tag, put in fedora/17
14:19:56 <ewoud> mburns: I'd say .src.rpm should be under rpms, src should just be .tar.(gz|bz2|xz)
14:20:05 <mburns> ewoud: sure
14:20:31 <mburns> eedri: after running rpmbuild, look at the directory structure
14:20:43 <eedri> mburns, it depends on the project
14:20:53 <eedri> mburns, some put it under rpmtop, some under rpmbuild
14:20:56 <mburns> eedri: hmm
14:21:09 <mburns> eedri: ok, well, each rpm build exposes the rpms as artifacts
14:21:12 <eedri> some separate src and some dont
14:21:33 <mburns> so just process all the artifacts
14:21:43 <mburns> the copy artifacts plugin has an option to flatten directories
14:21:51 <eedri> yea, i saw that
14:22:17 <mburns> so you can assume that it's a flat directory
14:22:24 <eedri> ok, so agreed main night job will copy all artifacts in src & rpm dirs
14:22:58 <ewoud> how about http://bpaste.net/show/36543/
14:22:59 <mburns> fabiand: close nextrelease with a comment pointing to the bug/patch that fixed it
14:23:03 <eedri> where src will contain *.tar(.gz|bz2)
14:23:24 <RobertM> Finally caught up.  I think we are off track some.  We are suppose to be talking about repo layouts not automating the process of getting .rpms from jenkins.  Can we deal with the topic of repo layouts since we have to deal with that today.
14:23:45 <ewoud> RobertM: +1 on focussing on repo layout, after that how they get there
14:23:47 <eedri> ewoud, exactly i want to close how the destination folder on ovirt.org will look like
14:24:09 <mburns> ack
14:24:21 <RobertM> eedri, I think your reply suggests the 2 of use agree pretty much on the finally layout.
14:24:23 <ewoud> +1/-1 on my proposal here?
14:24:58 <eedri> RobertM, there has been some suggestion here about diff layout for tar.gz files and src.rpm
14:25:00 <RobertM> ewoud, Can you please restate?
14:25:11 <ewoud> RobertM: http://bpaste.net/show/36543/ is the tree view
14:25:26 <mburns> i think we want to invert the 3.1/3.2/etc... with the rpm/src/etc...
14:25:46 <RobertM> -1
14:26:15 <RobertM> I agree with mburns it should be 3.1/[rpm|src|deb]/
14:27:02 <RobertM> I have no problem added in the extra layer of /rpm/ although I think it isn't needed
14:27:03 <ewoud> not sure, for gentoo it would be easy if src was just a flat directory with file names
14:27:17 * ewoud runs gentoo on his desktops
14:27:55 <ewoud> but you can mangle it without much difficulty
14:28:03 <quaid> information architecture wise, it seems to flow better to do [release number]/[format] aka 3.1/[rpm|src|deb]
14:28:04 <ewoud> so I'm fine either way
14:29:08 <RobertM> I am fine with 3.1/[rpm|src|deb]
14:29:26 <RobertM> I don't like rpm/3.1/...
14:30:03 <quaid> RobertM: agreed, doing rpm/3.1 says "we care more about the package format question before the version question"
14:30:04 <ewoud> http://bpaste.net/show/36546/
14:30:35 <ewoud> quaid: I personally think most people will care more about the package format anyway
14:31:08 <mburns> http://bpaste.net/show/bKqcBTNv4Svskjo8TJ3U/
14:31:13 <RobertM> ewoud, Only change I would make is nightly -> 3.2 (Right now.
14:31:23 <eedri> why isn't there a nightly subdir under the versions?
14:31:26 <mburns> RobertM: nack on nightly-> 3.2
14:31:29 <ewoud> RobertM: why? nightly could be master
14:31:33 <ewoud> and 3.2 the branch 3.2
14:32:05 <quaid> functionally nightly might be the same as a version
14:32:06 <mburns> 3.2 should be only populated when we have alpha/beta/rc/ga of 3.2
14:32:10 <quaid> but nightly *is* a version
14:32:15 <ewoud> I think the top levels should correspond to git branches
14:32:16 <mburns> nightly should be more like fedora rawhide
14:32:36 <RobertM> ok.  I see the point
14:33:39 <RobertM> Nightly gets it own tree.
14:33:50 <mgoldboi> mburns: though 3.1 is soon to be out, and 3.2 version patches will than come in?
14:34:02 <mgoldboi> versioning will be changed
14:34:10 <RobertM> +1 on http://bpaste.net/show/bKqcBTNv4Svskjo8TJ3U/
14:34:27 <mgoldboi> looking at rpms we have fedora18 around the corner as well
14:34:34 <mburns> mgoldboi: yes, but those will go in nightly only until we get official builds of engine for 3.2
14:34:35 <quaid> +1 on http://bpaste.net/show/bKqcBTNv4Svskjo8TJ3U/
14:34:40 <mburns> or of vdsm
14:34:57 <ewoud> +1
14:35:41 <ewoud> though not sure about el6, but that's a small detail we don't even have now
14:35:56 <eedri> should it be el6.3
14:36:08 <eedri> or el6/3
14:36:30 <mburns> ewoud: right, we don't have deb either
14:36:34 <RobertM> Well el6 should be called EL or RHEL with a 6 folder under it
14:36:58 <mburns> yes, EL with 6, 7, etc...
14:37:09 <mburns> was just trying to show how it can be filled out later
14:37:15 <ewoud> but this layout should be scalable enough
14:37:31 <mgoldboi> mburns: +1 for the base layout
14:37:35 <ewoud> I see no -1, so can we agree?
14:37:38 <RobertM> And it means existing installs and files will work once new releases come out.
14:37:40 <eedri> +1
14:37:42 <mburns> given this, though, there is one question
14:37:49 <eedri> for http://bpaste.net/show/bKqcBTNv4Svskjo8TJ3U/
14:37:57 <mburns> it only really works if there is a single srpm for el6, fc17, fc16, etc...
14:38:14 <eedri> right
14:38:21 <eedri> srpm should have the same subdirs as rpm
14:38:26 <ewoud> mburns: you're right, I placed srpm under the distro on the same level as noarch/x86_64
14:38:36 <eedri> just w/o the arch
14:38:59 <mburns> ok, so move srpm to same level as noarch/x86_64/etc
14:39:09 <eedri> +1
14:40:18 <RobertM> Under the /fedora/17/srpm ?
14:40:25 <eedri> RobertM, yes
14:40:37 <mburns> http://bpaste.net/show/QwiYrrY5jvXP22A12SBM/
14:40:42 <mburns> that should be final
14:41:24 <RobertM> I have no problem with that.  .srpm files seem to be version spefic.
14:41:28 <eedri> one more thing
14:41:38 <eedri> how do we keep history?
14:41:52 <eedri> does this layout should keep one version or many?
14:42:04 <mburns> eedri: always keep GA'd versions
14:42:25 <mburns> eedri: and *always* keep .tar.gz/.tar.bz2
14:42:26 <eedri> mburns, so each dir will contain X versions?
14:42:34 <ewoud> yes
14:42:48 <RobertM> That would be fine.
14:42:52 <mburns> eedri: otherwise, no need to keep RC/beta/nightlies
14:42:58 <eedri> mburns, ok ,we'll need to set up a cleaner with retention policy
14:43:05 <ewoud> this might take up some space, but if we get to that I think we can find some mirrors for it
14:43:54 <ewoud> I know the admins of ftp.nl.debian.org who also host a mozilla mirror who will gladly use up some more bandwidth
14:45:09 <ewoud> I think their current record is close to 8Gb/s and they'll get pie from the university if they reach it
14:45:15 <eedri> should there be a jenkins job to deploy stable (non nightly) rpms ? will it be done manually?
14:45:16 <RobertM> Part of the reason I wanted a few days worth of nightly's Goto love mirrors :)
14:45:41 <mburns> eedri: no, that should be done manually
14:45:43 <fabiand> mburns, thanks
14:46:02 <RobertM> mburns, I think they should be done in Jenkins but manually
14:46:09 <eedri> RobertM, +1 on that
14:46:35 <mburns> RobertM: so a locked down job that only a few people can use?
14:46:43 <RobertM> Then it doen't becomes mburns full time job to do new beta releases
14:47:01 <RobertM> mburns, Yes
14:47:01 * quaid looks at /topic & agenda & time left
14:47:15 <quaid> this has been a good discussion, but I wonder if we should wrap it up? Or ...?
14:47:19 <RobertM> I think we have 4 of 6 topics going on all at once.
14:47:24 <ewoud> quaid: +1 on wrapping
14:47:37 <mburns> RobertM: so essentially make koji style jobs that build the official rpms for release
14:47:38 <RobertM> Lets make the call on repo layout put that in the log then we can deal with Jenkins
14:47:45 <RobertM> mburns, Yes
14:47:46 <mburns> ack
14:48:03 <ewoud> I think we've discussed the repo layout and reached the conclusion
14:48:16 <ewoud> vote on http://bpaste.net/show/QwiYrrY5jvXP22A12SBM/ (pasted by mburns before)?
14:48:21 <ewoud> +1
14:48:33 <RobertM> Were is the action item?
14:48:40 * mburns wonders if it's bad form to nack his own proposal...
14:48:41 <mburns> +1
14:48:42 <RobertM> Where is the action item.
14:48:54 <eedri> the action item should be to create this stucture on ovirt.org
14:49:05 <RobertM> Also we need to move to the next item then
14:49:19 <eedri> and to run a script (locally/jenkins) to create a repo for the files in it
14:49:32 <eedri> at least for the nightly dir
14:49:35 <ewoud> I see no, -1, so we all agree on this layout?
14:49:41 <eedri> +1 for layout
14:49:46 <ewoud> if so we get #agree and #action from it ;)
14:50:06 <RobertM> Ok add an action item for me to put the new repo layout into place
14:50:25 <RobertM> +1 for rmiddle
14:50:37 <RobertM> and we can move on.
14:50:38 <quaid> #char ewoud eedri RobertM mburns
14:50:43 <quaid> #chair ewoud eedri RobertM mburns
14:50:43 <ovirtbot> Current chairs: RobertM eedri ewoud mburns quaid
14:50:47 <quaid> (so you can do #agreed)
14:51:00 <ovirtbot> 14[[07Repo layout14]]4 !N10 02http://wiki.ovirt.org/w/index.php?oldid=3953&rcid=4049 5* 03Ekohl 5* (+684) 10Created page with "<pre> . ├── 3.1 │   ├── deb │   ├── rpm │   │   ├── EL │   │   │   ├── 6 │   │   │   └── 7 │   │   └── fedora ..."
14:51:03 <quaid> #action RobertM to put new repo in place
14:51:10 <ewoud> #agree layout as on http://wiki.ovirt.org/wiki/Repo_layout
14:51:20 <quaid> ewoud: +d
14:51:39 <quaid> #agreed layout as on http://wiki.ovirt.org/wiki/Repo_layout
14:51:49 <quaid> did we reach any other decisions in that discussion?
14:51:57 <eedri> #agree  layout as on http://wiki.ovirt.org/wiki/Repo_layout
14:51:58 <quaid> or proposed decisions?
14:52:13 <eedri> quaid, there are still issues left for disscusion
14:52:31 <eedri> quaid, not sure we'll be able to cover them all
14:52:36 <ewoud> I think we should take how we get the files into the repo to the mailing list
14:52:39 <ewoud> given the time
14:52:48 <mburns> lets take jenkins stuff to the list
14:52:52 <RobertM> Next on agenda is backups of Jenkins?  Do you guys just want me to rsnapshot the /var/lib/jenkins folder nightly?
14:53:03 * eedri suggests using scp or artifact deployer jenkins plugins
14:53:11 <ewoud> eedri: mind writing a proposal on the mailinglist?
14:53:12 <quaid> #topic Jenkins backups
14:53:20 <eedri> ewoud, sure
14:53:36 <quaid> #action eedri to write a proposal on the list about how to get the files in to the repo
14:54:11 <eedri> RobertM, this folder contains all the buils, it can be a few dosens GB
14:54:21 <eedri> RobertM, rsnapshot knows how to calc diffs?
14:54:22 <RobertM> eedri, I have the space.
14:54:32 <eedri> RobertM, ok great
14:54:40 <RobertM> eedri, Yes.  It is based on rsync
14:54:53 * eedri suggests moving all code in jobs to jenkins git repo
14:55:32 <eedri> this will serve also as backup and make management and code review more simple
14:56:08 <ewoud> +1, afaik they're plain text files so git should be well suited
14:56:16 <RobertM> eedri, Do you know how to do that?  I don't see official support for that but I could be missing a plug-in
14:56:20 <eedri> ewoud, 99% of it is bash
14:56:24 <dneary> Hi all
14:56:28 <eedri> RobertM, already doing it
14:56:38 <eedri> RobertM, only way to scale in jenkins
14:56:39 <dneary> Sorry to disrupt... anyone know where I might get a hold of oschreib?
14:56:49 <eedri> dneary, he left
14:56:55 <mburns> hmm...
14:57:03 <mburns> there are plugins for svn (i haven't seen git)
14:57:09 <dneary> eedri, For the day, or left Red Hat?
14:57:10 <mburns> eedri: is there an auto-deploy?
14:57:11 <eedri> mburns, scm git
14:57:18 <eedri> mburns, multiple scm plugin
14:57:34 <eedri> mburns, what do you mean ? for backup?
14:57:51 <mburns> eedri: maybe i'm misunderstanding
14:57:52 <eedri> mburns, no, i mean we should treat jenkins code as we treat any other ovirt project
14:57:55 <mburns> where are changes made?
14:58:02 <mburns> in git first? or through jenkins?
14:58:05 <eedri> mburns, move all code into a git repo
14:58:27 <eedri> mburns, when you want to run it, you add the git repo to the job (via multiple scm plugin), alongside ovirt repo
14:58:36 <eedri> mburns, clone it to a subdir (i.e. jenkins)
14:58:43 <eedri> mburns, and use the code from the repo
14:58:55 <RobertM> Need to research multiple SCM plugin before he could vote.
14:59:06 * mburns not sure he likes this, actually
14:59:16 <mburns> i agree with backing up config
14:59:26 <eedri> mburns, let's say you have 10 similar jobs
14:59:41 <eedri> mburns, where you need exactly the same code , maybe with a slight change
14:59:50 * mgoldboi got to go
14:59:56 <RobertM> Lets table moving Jenkins management to git and move it to the list
14:59:59 <mburns> but not sure about having to commit stuff directly into git, get it approved and pushed, before it can be activated in jenkins
15:00:01 <eedri> mburns, isn't it more logical to use code from a git repo instead of just wirting it in the job?
15:00:20 <eedri> mburns, i would vote that each one of infra will have +2 for jenkins repo
15:00:34 <mburns> eedri: yes, and i've done that in the past, but the script is kept in ovirt-node-iso git repo, not in a generic jenkins repo
15:00:36 <RobertM> It sounds like we aren't clear on all the aspects yet so it is to soon to vote.
15:00:37 <eedri> mburns, and only if that change is critical or affects all jobs it will need a rebiew
15:01:00 <RobertM> Can I get a vote on backing up Jenkins to my location using rsync/rsnapshot?
15:01:02 <mburns> +1 on tabling this for now
15:01:05 <ewoud> eedri: would it be a repo per jenkins job or 1 global config?
15:01:06 <eedri> mburns, i dont have a problem with seperate jenkins folder/repos per project
15:01:07 <mburns> RobertM: ack on backing up
15:01:21 <ewoud> RobertM: should be the good short term solution
15:01:22 <eedri> ewoud, not pet job, maybe per ovirt project
15:01:32 <mburns> eedri: i meant that i have a jenkins.sh in the base ovirt-node repo
15:01:40 <mburns> and the build in jenkins just calls that script
15:01:44 <eedri> mburns, i don't like that method
15:01:53 <eedri> mburns, jenkins code shouldn't be part of the project repo
15:01:58 <eedri> mburns, it's infra
15:02:18 <mburns> eedri: i disagree to a certain extent, but let's table this for now
15:02:26 <eedri> mburns, ok
15:02:28 <RobertM> quaid, can you add an action item on me backing up the system using rsync for now and moving talk about managing jenkins using git to list.
15:02:36 <quaid> anyone can make an action
15:02:36 <eedri> +1 on backing up
15:02:58 <ewoud> #action RobertM backup /var/lib/jenkins using rsync
15:03:16 <eedri> RobertM, you should exclude /var/lib/jenkins/workspaces from that
15:03:16 <ewoud> next item or do people need to leave?
15:03:46 * mburns has another call, but don't block on me
15:03:49 <RobertM> eedri, Noted
15:03:53 <eedri> RobertM, might be good to backup /var/log/jenkins as well
15:04:48 <mburns> danken: dougsland:  fyi:  https://bugzilla.redhat.com/show_bug.cgi?id=842775
15:05:38 <RobertM> #topic enabling per patch builds on Jenkins
15:06:42 <ovirtbot> 14[[07Infrastructure team meetings14]]4 !10 02http://wiki.ovirt.org/w/index.php?diff=3954&oldid=3952&rcid=4050 5* 03Ekohl 5* (+0) 10Eedri added parallel jobs to the agenda
15:06:44 <eedri> this topic is blocked by the security issues we raised on list, did we agreed on the process of approving ?
15:06:50 <dneary> eedri, When you said "he left", did you mean for the day?
15:07:14 <eedri> dneary, i think he's in the gym.. might be back in an hour
15:08:07 <ewoud> eedri: I'm not sure what was agreed on the list, looking up now
15:10:07 <RobertM> Unless anyone has anything important I suggest we table to rest of the agenda and call the meeting over?
15:10:32 <ewoud> I'll prepare something for puppet on the mailing list
15:10:51 <eedri> RobertM, agree
15:10:54 <ewoud> #action ewoud prepare a puppet proposal on the mailing list for the next agenda
15:11:10 * quaid is running a phone meeting now, attention very split
15:11:49 <RobertM> quaid, Lets just end this sucker so am I.
15:12:19 <ewoud> I would like to propose that everyone who wants to add something to the agenda prepares the item a bit for a meeting
15:12:34 <ewoud> I'm fine with discussion a proposal on IRC, but meetings should be kept short imho
15:12:44 <mburns> agreed
15:12:56 <quaid> +1
15:13:27 <quaid> fwiw, anyone with chair can close, etc.
15:13:34 <quaid> closing in 30 seconds
15:13:37 <ewoud> #agreed new agenda items should be prepared by the proposer so we reach a conclusion faster
15:13:47 <ewoud> I'm done now :)
15:16:24 <dneary> eedri, Ah, right
15:16:43 <dneary> eedri, When you said "he left", I thought you might have meant "he left Red Hat"
15:17:17 <eedri> dneary, :) too dramatic
15:17:59 <ewoud> since quaid didn't do it yet
15:18:00 <ewoud> #close
15:18:13 <mburns> #endmeeting