15:01:05 <quaid> #startmeeting
15:01:05 <ovirtbot> Meeting started Wed Apr  4 15:01:05 2012 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:05 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:34 * mburns here
15:01:36 <quaid> #meetingname oVirt weekly sync
15:01:36 <ovirtbot> The meeting name has been set to 'ovirt_weekly_sync'
15:02:12 <ovirtbot> 14[[07Meetings14]]4 !10 02http://www.ovirt.org/w/index.php?diff=3032&oldid=3024&rcid=3115 5* 03Quaid 5* (+48) 10/* Weekly project sync meeting */ adding a meeting timing discussion to agenda
15:02:14 * oschreib here
15:03:07 * rharper is here
15:03:59 * sgordon_ is here
15:04:19 <quaid> #topic Agenda
15:04:28 <quaid> #link http://www.ovirt.org/wiki/Meetings#Weekly_project_sync_meeting
15:04:38 <quaid> Meeting timing - when in the day, every week?
15:04:38 <quaid> Release status check-in
15:04:38 <quaid> Growing Infrastructure team and resources
15:04:38 <quaid> Any roll-up reports from sub-projects?
15:04:38 <quaid> Links to meeting minutes and logs are sufficient
15:04:41 <quaid> Anything else?
15:05:08 <rharper> quaid: I'd like to discuss the dco email I sent to the board list
15:06:01 <quaid> ok
15:06:08 <quaid> let's start
15:06:15 <quaid> #topic Meeting timing
15:06:22 <quaid> so I remain confused
15:06:38 <quaid> it's like the meeting just moved itself :)
15:06:57 <quaid> I thought the trend was "stick with same time and follow US DST", then it moved
15:07:10 <quaid> so I was hoping for some insight if anyone has it
15:07:19 <quaid> before bringing it to arch@
15:07:30 <quaid> also, the suggestion is still out there to have a twice-a-month instead meeting, also good for the list
15:07:44 <mburns> quaid: seems it was created to follow UTC
15:07:54 <rharper> yeah, it moved on my cal as well
15:07:57 <mburns> need to remove and recreate the invite
15:08:05 <rharper> that's usually the best way
15:08:05 <oschreib> +1 mburns
15:08:55 <quaid> ah, I see
15:08:56 <oschreib> about the weekly timing - last meeting we had a lot to dicuesss, and I suspect we will have more things when we will get close to next release dates
15:09:06 <quaid> that's true
15:09:30 <oschreib> so lets keep it weekly. and do quick meetings when we can :)
15:09:33 <quaid> also, it can hurt momentum to switch from weekly and people don't know when is the meeting, compared to "every week at this time even if I don't show up"
15:09:39 <quaid> oschreib: +1
15:10:09 <quaid> ok, so I'll take up the "when is our real time, UTC or US DST" on the list and get it settled for the future
15:10:31 <quaid> ok, thanks for insight, we can move on ...
15:10:41 <mburns> quaid: regardless, i think we need to move 1 hr earlier for folks in Isreal
15:10:50 <quaid> mburns: +1 makes sense
15:10:50 <oschreib> mburns: +1
15:11:14 <mburns> so let's plan on 14:00 UTC next week
15:11:24 <oschreib> mburns: s/Isreal/Israel
15:11:39 <quaid> well, it's a fair point that we're the people who are here, at 1400 and 1500 :)
15:11:41 <mburns> and we can figure out before next DST change whether we follow US or UTC
15:11:53 <quaid> oschreib: always seemed very 'real' to me :)
15:11:58 <mburns> oschreib: sorry, type...
15:12:04 <quaid> mburns: +1
15:12:04 <oschreib> lol
15:12:08 <mburns> typo...
15:12:14 <rharper> heh
15:12:20 <quaid> #agreed Weekly meetings are a good thing, just make them quick if there isn't much to discuss
15:12:36 <quaid> #agreed Keep meetings at 1400 UTC starting 11 Apr
15:12:46 <quaid> rbergeron: can you help me with that invite? I think you owned it originally
15:12:53 <quaid> if you want to vaporize it and I'll start a new one, that's fine
15:13:07 <quaid> #action quaid and rbergeron to sort out the mass invite
15:13:28 <quaid> #agreed Decide on DST plans in 4 months when it comes around again ...
15:13:28 <mburns> quaid: maybe get some sort of calendar set up that people can import
15:13:36 <mburns> rather than an invite
15:13:55 <cdub> some folks have had trouble with the invite
15:14:02 <quaid> mburns: pilhuhn was working on that actually, we're looking at a Wordpress plugin or Google Calendar, as he's been working on a cool timeline widget to go alongside
15:14:33 <mburns> quaid: ok, sounds good
15:14:45 <quaid> #action quaid to circle with pilhuhn on an oVirt shared calendar, then get back to infra@ for approval
15:15:01 <quaid> ok, moving on ...
15:15:08 <quaid> #topic Release status
15:15:21 <oschreib> Nothing new
15:15:32 <oschreib> I just wanted to raise the upgrade issue
15:15:54 <ovirtbot> 14[[07Meetings14]]4 !10 02http://www.ovirt.org/w/index.php?diff=3033&oldid=3032&rcid=3116 5* 03Quaid 5* (+37) 10/* Weekly project sync meeting */ adding rharper's agenda item
15:16:02 <oschreib> We're changing couple of things in the spec file (so we can push it into Fedora)
15:16:07 <mburns> has anyone noted yet, that current HEAD of vdsm doesn't work on F16
15:16:16 <oschreib> mburns: indeed
15:16:21 <mburns> since it depends on libvirt that is only f17+
15:16:26 <rharper> heh, yes
15:16:32 <oschreib> mburns: they'll create a "hybrid repo"
15:16:44 <oschreib> that contains rpms from f17
15:16:46 <mburns> oschreib: i object...
15:17:11 <mburns> that should be discussed here at a minimum
15:17:13 <oschreib> fsimonce: ping
15:17:21 <mburns> and that's a big deal for ovirt-node as well
15:17:35 <rharper> I know I've brought this up before, but we really need capabilities; there's not reason to break the whole daemon and package for a specific feature; now, I don't think we can get caps working in the near term for the next release, but we should spend some time thinking about what that would look like for vdsm
15:17:39 <oschreib> mburns: I'm trying to reach vdsm guys
15:18:03 <mburns> i agree we should have some form of capabilities
15:18:13 <rharper> does any one if the feature that required the newer libvirt is on the 3.1 release list ?
15:18:17 <mburns> but a hybrid repo for now is not a valid solution, IMO
15:18:49 <fsimonce> oschreib, mtng
15:18:51 <READ10> mburns: does virt-preview not work?
15:20:06 <mburns> it's snapshotCreateXML function that's creating the dependency
15:20:41 <mburns> READ10: it might work, but if we want to do that, it's going to take work on the node side to make it work
15:21:04 <oschreib> mburns: I completely agree with your guys
15:21:20 <oschreib> we should raise it in arch@ mailing list
15:21:32 <rharper> mburns: ah, the VM snapshots
15:21:34 <oschreib> since no vdsm representative here
15:21:45 <abaron> oschreib: hold your horses
15:22:22 <oschreib> abaron: I'm in Israel, we have camels, not horses :-P
15:22:35 <rharper> mburns: VIR_DOMAIN_DESTROY_GRACEFUL from one of the commit messages
15:23:13 <abaron> rharper: vdsm relies on LVM upstream.  LVM has changed API thus vdsm needs to adapt.  vdsm can either support both old and new API or can break for older distros.  I don't see the relevance of capabilities here.
15:23:43 <abaron> rharper: supporting all versions is the libvirt way and it causes code bloat and problems
15:23:54 <abaron> rharper: vdsm works fine on rawhide
15:24:25 <sgordon_> that's lovely, but given everything else in ovirt.org is only being built on f16 still...
15:24:39 <abaron> sgordon_: regardless, we can have a build for fedora that works.
15:25:29 <rharper> abaron: we already do this in virtio and kvm, negotiating features and function based on what's present in the drivers.  determining the level of LVM and what api works with it and what doesn't is a way to address running newer code on the older.  but this is a longer term discussion
15:26:04 <mburns> personally, i'm fine if we decide that it's F17+ for 3.1 release
15:26:13 <mburns> but i think we need to make that call *now*
15:26:40 <oschreib> mburns: +1 on the F17 for 3.1
15:26:40 <abaron> mburns: +1
15:27:09 <abaron> rharper: I agree about that, but as you said, it's long term.  Feel free to start that discussion on the mailing list.
15:27:12 <mburns> f17 is beta or about to go beta, iirc
15:27:19 <quaid> fwiw, this sounds like a good topic for arch@ - not something we should decide in the vaccuum of a meeting
15:27:32 <oschreib> quaid: +1
15:27:36 <mburns> quaid: agreed, but with a deadline
15:27:50 <mburns> forcing f17 on node will take some work
15:28:02 <mburns> so i need to know asap if it's what i need to do
15:28:32 <rharper> abaron: yep, I need to spend some more time in the code so I can present a reasonable idea
15:28:44 <quaid> who will lead the discussion-to-decision on arch@?
15:29:19 <mburns> sounds like a release manager discussion... ;-)
15:29:24 <abaron> rharper: I'd suggest you get on the vdsm irc and discuss with federico and saggi as they will have some solid ideas to be sure and can help you through the code.
15:29:39 <oschreib> mburns: if you say so :)
15:29:40 <rharper> abaron: excellent suggestion; thanks
15:30:16 <mburns> i'll certainly chime in and be active in the discussion since it directly affects node
15:30:25 <oschreib> I'll send the mail in few minutes
15:30:36 <abaron> wrt the move to f17: there is no question that we will always have a cutoff point, so we should set the process for that in general
15:30:42 <abaron> oschreib: ^^^
15:31:01 <oschreib> abaron: I think we should set it per release
15:31:14 <quaid> #action oschreib to take VDSM-libvirt-F17 target discussion to arch@
15:31:52 <mburns> f17 has scheduled ga mid-may, so aligning to f17 for 3.1 release might make sense
15:32:29 <oschreib> I just hope we won't eat F17 beta bugs
15:32:39 <abaron> oschreib: I don't mean we should determine when that point is for all future releases, rather we know that such issues will always arise (no reason to think that 3.2 will run on F16, 4.0 on F17 etc)
15:32:55 <abaron> so we need to think if we can anticipate this and what the process is
15:33:15 <abaron> what the guarantees of each project are as well in this regard.
15:34:21 <quaid> ok, are we ready to move on?
15:34:59 <oschreib> I didn't finish to talk about upgrade
15:35:09 <oschreib> We're making some changes to the spec
15:35:35 <oschreib> so next version upgrade might not be perfect, and might require some manual changes.
15:36:55 <oschreib> any thoughts?
15:37:22 <mburns> oschreib: ideally, i think we'd avoid manual steps, but i think it's ok as long as we know what the steps are and document them clearly
15:37:37 <sgordon_> do we have an engine-upgrade to use this time around?
15:37:38 <mburns> and try to avoid anything manual in the future
15:37:43 <sgordon_> that can prompt with regards to any manual steps?
15:38:24 <oschreib> the issue is, engine-upgrade should run on every upgrade
15:38:40 <oschreib> and I'm trying to avoid a version specific code.
15:41:31 <quaid> oschreib: so this sounds like something to mention on arch@ as well
15:42:08 <oschreib> ok. I'll raise it after the feature freeze, when the setup/spec code will be "frozen"
15:42:09 <quaid> anything else here?
15:42:11 <oschreib> nope
15:42:43 <quaid> #action oschreib to bring spec file changes decision to arch@
15:42:56 <quaid> #action oschreib to make sure sgordon_ has manual steps for upgrade for release notes
15:43:09 <quaid> ok, moving on ...
15:43:21 <quaid> #topic Infrastructure team
15:43:35 <quaid> so I'm going to move this topic to next week as I'm not prepared with anything
15:43:51 <quaid> #action quaid to prepare thoughts about infra team for next meeting
15:44:13 <quaid> and I'm going to jump to rharper's topic
15:44:23 <quaid> (since the other item isn't defined yet)
15:44:34 <quaid> #topic DCO for all sub-projects
15:45:05 <quaid> rharper: so I'll admit I spent about 5 min trying to find what DCO is, so one suggestion I had was to expand a bit on the acronyms in the discussion.
15:45:14 <rharper> quaid: sorry for being cryptic
15:45:47 <quaid> np
15:46:14 <rharper> it's the Developer Certificate of Origin;
15:46:38 <rharper> the kernel adopted this a while back to help ensure the community was tracking the origin of the source code
15:46:56 <rharper> #info http://kerneltrap.org/files/Jeremy/DCO.txt
15:47:20 <quaid> ah
15:49:32 <quaid> rharper: so is it actually controversial, or we are just being lazy about implementing and following?
15:49:45 <rharper> quaid: AFAICT, it's just implementation
15:50:32 <rharper> I've not really heard of a community objecting to the use of DCO; and it's pretty simple.  Point the community to the DCO text so they can read it, and then asking them to include the Signed-off-by: in the commits
15:50:48 <rharper> and a maintainer to remind submitters that you need to include a Signed-off-by: tag before it can be committed to the repo
15:51:55 <oschreib> sounds good to me, but we need commitment from the different maintainers.
15:52:04 <oschreib> another topic for arch@
15:52:06 <oschreib> ?
15:52:07 * mburns has no issue
15:52:48 <quaid> yeah, we do need to settle it on the list
15:53:06 <quaid> #action rharper Settle DCO topic on arch@
15:53:13 <rharper> oschreib: ok, arch is better than @board ?
15:53:15 <rharper> quaid: ok
15:53:17 <quaid> #agreed We don't see any objection to using DCO
15:53:46 <quaid> it sounds like a developer concern to me, but if Board members think it needs to be raised there, they can move the discussion from arch@
15:54:06 <quaid> ok ...
15:54:11 <rharper> yep
15:54:17 <quaid> so, time for one more quick topic
15:54:40 <quaid> #topic Do we want some more formal information from sub-projects in the weekly sync?
15:55:01 <quaid> I guess what I was seeing is that we have multiple active sub-projects that have interlocking dependencies
15:55:27 <quaid> but we don't usually have someone from each sub-project here in this meeting to discuss
15:55:39 <quaid> is that a big deal at all?
15:55:43 <oschreib> once again, +1 from me
15:55:45 <oschreib> it's not
15:55:54 <oschreib> we should just "force" them to be here.
15:56:10 <oschreib> at least one representative from each component
15:56:18 <oschreib> or each "major" component
15:56:29 <quaid> yeah, that's what I was thinking
15:56:58 <quaid> I can bring it up on arch@, I just wanted to vet my thinking for sane/not-sane
15:56:59 <mburns> no objections from me
15:57:10 * mburns is here anyway
15:57:21 <quaid> #action quaid to pester arch@ to send a representative from each oVirt component project to the weekly sync
15:57:43 <quaid> #topic anything else?
15:58:16 <quaid> ok then!
15:58:30 * quaid closing in 5
15:58:31 <quaid> 5
15:58:32 <quaid> 4
15:58:32 <quaid> 3
15:58:33 <quaid> 2
15:58:35 <quaid> 1
15:58:38 <quaid> #endmeeting