15:01:55 #startmeeting 15:01:55 Meeting started Wed Nov 13 15:01:55 2013 UTC. The chair is doron. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:02:08 * orc_orc looks on to the meeting 15:02:10 orc_orc: you became Yoda ? 15:02:19 * sbonazzo here 15:02:21 YamakasY: not now please -- meeting in progress 15:02:31 orc_orc: I just saw 15:02:38 * YamakasY half here 15:02:38 #topic ovirt weekly sync 15:03:13 * danken is here 15:04:12 * mburns here in the background 15:04:31 * sahina here 15:05:11 * jb_netapp here 15:05:52 * lvernia here 15:06:12 #topic Agenda and roll call 15:07:09 * jb_netapp here 15:07:36 Agenda: 15:07:39 3.3 update releases 15:07:41 3.4 planning 15:07:42 conferences and workshops 15:07:44 infra update 15:07:45 other topics 15:07:51 let's start 15:08:10 #info 3.3 update releases 15:08:32 doron: probably want to #info all the agenda items 15:08:37 then switch the topic to each one 15:09:01 mburns: thanks 15:09:24 #info 3.3 update releases 15:09:26 #info 3.4 planning 15:09:27 #info conferences and workshops 15:09:29 #info infra update 15:09:30 #info other topics 15:09:36 #topic 3.3 update releases 15:09:53 danken: would you like to share any 3.3 updates? 15:10:11 well, I am aware of a single blocker 15:10:25 Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI 15:10:29 or are there more? 15:10:32 danken: doron: actually we have 2 blockers and one proposed 15:10:40 Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI is in post 15:10:50 Bug 1029584 - create vm does not work with display protocol vnc and operating system linux 15:10:56 is a regression found this morning 15:11:17 this will need to rebuild ovirt-engine for including a missing patch 15:11:25 sbonazzo: thanks. Who's handling it? 15:11:32 is 1029584 a real blocker, sbonazzo? 15:11:46 1029885 has been proposed as blocker too 15:11:59 I mean, it's annoying, but is it a regression of ovirt-3.3.1? 15:12:24 danken: I think so. 15:12:51 sbonazzo: so you agree with marking it as a version blocker? 15:12:54 Bug 1029885 - cloud-init testcase does not work in engine 3.3.1 15:13:15 doron: yes I agree, and I think that also itamar will agree on that 15:13:16 i agree that create vm failing should be fixed, especially if it's a regression 15:14:12 #agreed 1029885 is a blocker. 15:14:16 what about the others? 15:14:28 is 1029584 a blocker? 15:14:41 the cloud-init issue is no regression according to https://bugzilla.redhat.com/show_bug.cgi?id=1029885#c2 15:14:47 doron: 1029584 is the vm not starting 15:14:53 1029885 --- not sure that is even ovirt related, looks like either environmental or cloud-init... 15:14:58 we simply require a too-new cloud-init 15:15:15 #agreed BZ 1029584 is a blocker. 15:15:36 about 1029885 I think we can postpone to 3.3.2 15:15:36 who's handling it on virt? 15:15:53 1022961 -- i would like to see that fixed, and it's in POST, but what's the status on getting it merged? 15:15:54 ack for postponing 1029885 15:16:01 doron: 1029584 is handled by Shahar Havivi 15:16:13 doron: Ofer and I will take care of the rebuild 15:16:28 mskrivanek: any inputs on 1029584? 15:17:36 I guess we'll have to take it offline to get a status update. 15:17:42 mburns: 1022961 is merged on master, posted under review on 3.3 but I don't think it will be an easy merge 15:18:06 sbonazzo: abaron does not want it in - the code is very ugly 15:18:11 #action doron to followup on 1029584 with mskrivanek 15:18:32 any other potential blockers? 15:19:15 mburns: I worked on that hack last week, and I do not see anyone else fixing the broken glusterSD in any better way soon. 15:19:39 doron: i don't think there is anything else for 3.3.1. 15:19:48 mburns: do we have a list of 3.3.x blockers to monitor? 15:19:50 doron: yes 15:19:57 so we should either convince abaron to take the code, or live with the regression. 15:19:59 doron: yes, sbonazzo has a tracker... 15:20:06 doron: we've trackre bug for 3.3.1 and 3.3.2 15:20:10 mskrivanek: we need feedback on 1029584 which is a blocker. 15:20:11 doron: it's pending backport to 3.3.1.1 or something like that. it's already fixed 15:20:17 3.3.1 : https://bugzilla.redhat.com/show_bug.cgi?id=1019391 15:20:22 danken: the question is whether we can live with this in 3.3.1 15:20:37 mburns: exactly. I think we cannot. 15:20:38 3.3.2 https://bugzilla.redhat.com/show_bug.cgi?id=1027349 15:20:49 mskrivanek: it's still in NEW 15:21:01 that's why I stepped into this quagmire in the first place... 15:21:30 danken: ok, then it's still a blocker and we can't release until it's fixed 15:21:41 doron: we don't have 3.3.1.1 branch yet and 3.3.1 is gone. once there is a new branch (ofer's doing it?) we'll backport existing fix which is in 3.3.2 already 15:21:52 mburns: abaron says that glustersd is half-broken anyway 15:21:54 3.3.1 is gone? 15:22:02 mskrivanek: it hasn't released yet... 15:22:10 mburns: even in ovirt-3.3.0, since it does not allow VMs with snapshots 15:22:11 mskrivanek: yes, ofer is doing it 15:22:22 mburns: I've been told the branch is gone so we have nowhere to backport it to ATM 15:22:28 mburns: 3.3.1 branch has been removed after 3.3.1 tagging 15:22:50 mburns: ofer is restoring a 3.3.1 branch and handle the tagging issue 15:22:53 sbonazzo: so how do we plan to build 3.3.1? 15:22:59 sbonazzo: ok, seems strange to remove the branch before the release is gone, but whatever... 15:23:30 doron: yes, we'll rebuild ovirt-engine just after the branch creation and patch backporting 15:23:35 danken: so you think we should at least try to fix the gluster issue in 3.3.1, but abaron doesn't 15:23:50 overall summary: 15:24:18 1029885 is a blocker, is fixed and is awaiting backport and rebuild of ovirt-engine 15:24:36 no 15:24:45 1029584 is a blocker, is fixed and is awaiting backport and rebuild of ovirt-engine 15:24:55 1029885 is not a blocker, needs to be moved to 3.3.2 15:25:14 mburns: yeah, I suppose you can some it up this way. 15:25:32 1022961 -- some consider it a blocker, some don't, patch is posted, but under disagreement 15:25:52 mburns: 1029885 added to 3.3.2 tracker 15:26:00 danken: is 1022961 a regression? 15:26:05 doron: yes 15:26:16 danken: so it sounds like a blocker. 15:26:20 an unintended collateral of the rebase we had 15:26:20 danken: how about this: we drop 1022961 from the blocking list so we can at least post engine and an updated vdsm 15:26:48 and we fix the gluster domain issue in an async update as soon as a fix is agreed on? 15:27:00 mburns: that would be a shame to release ovirt-3.3.1 without vdsm :-( 15:27:37 danken: we could release a vdsm that has the bug 15:27:58 iiuc, gluster domains work, they just use mount instead of libgfapi 15:28:45 mburns: that's not gluster domain at all... 15:29:03 it's gluster-fuse, which we had in 3.1, I believe 15:29:32 danken: so what do you suggest? 15:29:42 danken: so when can you have it fixed? 15:29:43 and it's gonna be non-fun to try to migrate a VM from 3.3.0 to 3.3.1 15:29:55 abaron: convince abaron to take the patch ;-) 15:30:16 abaron: ? 15:30:20 danken: is it true that we *need* the rebased vdsm with 3.3.1? 15:30:38 mburns: if that's true we have a serious bug! 15:30:49 engine-3.3.1 must work with vdsm-3.3.0 15:30:58 ok, good 15:31:03 though that's combination has not been tested thoroughly. 15:31:08 maybe itamar can help with the decision making. 15:31:24 danken: ? 15:31:38 but holding vdsm sounds the most reasonable choice 15:31:40 abaron: 1022961 seems to be a blocker 15:32:12 danken: reading history 15:32:25 abaron: according to danken no point of 3.3.1 without it. 15:32:40 doron: not exactly 15:32:53 doron: I said that it's bad to release vdsm without it 15:33:01 doron: unfortunately, that bug is currently saving our asses 15:33:35 abaron: I do not understand how. the bug is not on 3.3.0 15:33:47 abaron: having a regression as a life saver does not sound promising. 15:33:49 danken: we want the bug in 3.3.0 15:33:57 but it's not there. 15:34:03 abaron: how is it different between posixfs and libgfapi (other than snapshots not working)? 15:34:14 snapshots are not working 15:34:31 that's a no go 15:35:25 so current state: 3.3.0: uses libgfapi, but snapshots are broken 15:35:40 3.3.1: uses posix (which it shouldn't), and snapshots work 15:36:04 patch for 1022961 changes it back to using libgfapi, but would break snapshots again 15:36:10 abaron: danken: is that accurate? ^^ 15:36:21 mburns: yep 15:36:34 we can keep the bug unfixed 15:36:36 and the snapshot issue is a bug in libgfapi 15:36:50 but only if we block glusterSD in Engine 15:36:52 (or series of bugs) 15:37:28 danken: is there a problem with migration from libgfapi vm to posix vm? 15:37:34 or vice-versa? 15:37:34 It is unacceptable to make people THINK they start glusterSD, but use fues insteead 15:37:52 it would break future compat, when libgfapi is fixed. 15:38:05 mburns: yes, it would not work ;-) 15:38:11 whoever said that glusterSD is synonymous with libgfapi 15:38:13 ? 15:38:14 so, today, if someone has a glustersd configured 15:38:25 and they upgrade to 3.31 15:38:29 3.3.1 15:38:34 it would break 15:38:41 because the domain would switch to using fuse 15:38:49 mburns: indeed. 15:39:05 danken? 15:39:16 why and how would this affect migration? 15:39:34 so then i think we would have to fix this so that it uses libgfapi 15:39:36 abaron: the domxml uses a file path 15:39:45 even if snapshots don't work 15:39:53 instead of the gluster "network drive" parameters 15:39:58 snapshots not working are status quo 15:39:58 danken: however it was in source, that's how it will run in target 15:40:41 mburns: snapshots are much more basic than libgfapi 15:40:49 libgfapi is basics 15:40:52 sorry 15:40:55 snapshots is basics 15:40:58 we can basically release note that due to a bug in libgfapi, snapshots don't work on gluster domains 15:41:24 abaron: hmm, you may be right 15:41:27 mburns: we can do the same but state that libgfapi isn't in use 15:42:12 abaron: will that break people upgrading? 15:42:16 about migration not breaking. vdsm does not do anything on the destination, and the fuse mount should be there. 15:42:50 mburns: not that I'm aware of, but really needs testing 15:43:00 still, it takes the sting from the glusterSD feature 15:43:22 not to mention that we don't have a proper fix for this anyway (using libgfapi 15:43:32 danken: yes, but we can document that they'll get that ability later 15:43:38 when libgfapi is fixed 15:44:12 mburns: that looks like a handwavy date ... 15:44:14 I cannot see the context in https://bugzilla.redhat.com/show_bug.cgi?id=797961 as it is private, but it seems to have been lingering since 2012-02 -- it is also blocked by 1022961 as well as the oVirt 3.3.1 release in 1019391 15:44:19 and that is a while 15:45:02 orc_orc: fwiw, i'm pretty sure work is being done to fix the issue in libgfapi now 15:45:08 but i don't know details... 15:45:08 ;) 15:45:59 I see POST status on 1022961 ... perhaps there is a timeline to general release to reach out to get a 'read' on? 15:46:23 orc_orc: that's the debate above between danken and abaron 15:46:37 orc_orc: the post for that bug is very ugly 15:46:39 it's about whether that fix should be accepted or not 15:46:54 mbunrs: the fix as is should not be accepted period. 15:47:08 mburns: so how long can we delay 3.3.1? this will not converge in the near future. 15:47:23 mburns: I do not think we should 15:47:44 ok, so abaron and danken agree we shouldn't accept the fix 15:47:49 ovirt-3.3.0 did not really have glusterSD 15:47:59 danken: abaron: so release vdsm as is today with 3.3.1? 15:48:09 and converge on this issue for 3.3.2? 15:48:10 mburns: yes 15:48:21 doron: there is the agreement! 15:48:29 mburns: indeed so ;) 15:48:40 so let's move this bug to 3.3.2 15:48:43 danken: but put a big sign that there's no glusterSD 15:48:54 doron: could you add it to actions? 15:49:01 #agreed release vdsm as is today with 3.3.1 15:49:03 danken: what do you mean? 15:49:16 #action release vdsm as is today with 3.3.1 15:49:29 mburns: glusterSD was a promised feature for 3.3, but it's not there. 15:49:33 #action handle 1022961 for 3.3.2 15:49:50 danken: so what are we going to do in engine? 15:49:54 prevent people from using it? 15:49:59 mburns: no, a realease note 15:50:04 ok 15:50:09 a release note is doable 15:50:37 saying that the gluster storage domain uses fuse for the time being due to issues with libgfapi 15:50:41 #action add a release note for glusterS 15:50:45 danken: can you take care of moving the bug to the 3.3.2 tracker? 15:50:47 Hi all 15:50:59 hi dneary 15:51:01 dneary: hi 15:51:12 doron: ok, i think we can move on now 15:51:36 #topic 3.4 planning 15:51:42 sbonazzo: sure. 15:51:49 danken: thanks 15:52:01 who can update on 3.4 planning?? 15:52:09 sbonazzo: ? 15:52:40 * tontsa is pretty disappointed on gluster fapi decission 15:52:52 guys what about importing VM's, existing ones that are on an NFS share you just attached 15:52:56 doron: about 3.4.0 there is the spreadsheet posted by itamar on google docs 15:53:08 sbonazzo: I'm aware of it. 15:53:18 doron: it's linked on http://www.ovirt.org/OVirt_3.4_release-management 15:53:29 https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1dSMnZwMF9XWVE&usp=sharing#gid=0 15:53:40 tontsa: no one is happy about it :-( 15:53:52 doron: bug scrubing is still in progress but we've moved down from 366 bugs unscrubbed to 307 15:53:56 IIUC users should add their names to specific features 15:53:58 tontsa: do you have any other way out? 15:54:00 mburns: note that problem is not libgfapi per se but rather lack of support in libvirt for snapshots over libgfapi 15:54:14 doron: http://red.ht/17pazhH (unscrubbed bugs) 15:54:19 danken, prolly try to push it via rhev side 15:54:27 but meh.. 15:54:44 sbonazzo: I'm still trying to understand who is looking into features. 15:54:52 that is 3.4 features 15:55:19 tontsa: rhev is rhev. we're here to solve ovirt problems. 15:55:25 doron: there are a few features with devel owner set 15:55:47 is ovirt not still an rhev ripoff ? 15:55:59 YamakasY: ? 15:56:12 abaron: ovirt is rhev 15:56:20 sbonazzo: many of the features coming from users-ml are not handled. 15:56:22 about we need to fix ovirt bugs 15:56:32 YamakasY: if anything it's the other way around 15:56:35 doron: that is known 15:56:38 danken, yep.. but i need that feature or have to think goin some other way like ceph 15:56:48 dneary: any idea how to remind folks about it? 15:56:58 abaron: huh ? centos is also a ripoff from rhel 15:57:12 YamakasY: centos is repackaging of rhel srpm 15:57:27 abaron: yap 15:57:34 YamakasY: oVirt is not repackaging of rhev 15:57:40 abaron: how can rh sell an OSS > 15:57:41 ? 15:58:06 tontsa: I'm certain glusterSD is going to get there 15:58:12 ovirt is upstream to rhev, but rhev is much more cherry picked 15:58:14 but not for ovirt-3.3.1 :-( 15:58:22 doron, I don't right now have an "unanswered questions" filter/web page - that would be something noce to have, but mailing lists aren't set up for that 15:58:33 tontsa: that's true 15:58:51 YamakasY: I'm not sure what that has to do with oVirt or how that is relevant here 15:58:52 doron, I could do a simple MLStats report which has "unanswered emails" - emails that have not had at least one reply 15:59:13 dneary: I'm focusing now on features asked in users-ml, while no one steps forward to handle it for 3.4. 15:59:14 danken, yep.. it's just uncertain if we go with fuse whether we can upgrade to libgfapi later on 15:59:27 dneary: check https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1dSMnZwMF9XWVE&usp=sharing#gid=0 15:59:31 abaron: it's a normal way that rh created ent stuff on OSS so needs to release too OSC... 15:59:33 or will it be some arcane database manipulation and copying data 15:59:38 that's why CentOS exists 15:59:53 sbonazzo: mburns how long do we have to finalize 3.4 planning? 15:59:53 YamakasY: please wait a bit until after the meeting 16:00:13 orc_orc: yep, I mean... we have to look to rhev to see what we want 16:00:21 and what is doable 16:00:31 YamakasY: it does not sell the software, it sells support., QE, upgrade process... 16:00:46 doron: Code freeze: end of December 16:00:50 doron: the important dates are end of Decemeber for dev freeze 16:00:55 and end of january for release 16:01:04 danken: is it possible to download RHEV than ? 16:01:07 mburns: wow, and we still do not have all 3.4 in place. 16:01:16 tontsa: we have not tested this, but abaron convinced me that we can upgrade. 16:01:18 doron: yep :-/ 16:01:23 doron, Oh, right. 16:01:31 mburns: would be great, we can upgrade when we are finally in production than 16:01:51 YamakasY: I'm sure you can download the source. It's gpl/apache license. RH has to give it. 16:01:58 doron, What do you mean by "finalize" 3.4 planning? I would say you want to have a prioritised list of features already, and a cut-off date beyond which new features do'nt get started 16:02:03 mburns: any idea how to finalize 3.4 plans? 16:02:07 danken: source, but no "install from here" 16:02:19 dneary: we have the dates 16:02:22 danken, ok.. 16:02:39 dneary: Code freeze: end of December 16:02:58 we should by now have a defined scope for 3.4 16:03:01 YamakasY, oVirt is the base on which future RHEV releases will be built. RHEV has fewer new/in-progress features, and more bug fixes (at least, short term) - better integration with RHEL and more testing 16:03:10 doron: dneary: that sounds more like a feature freeze 16:03:11 doron, Yes, I agree 16:03:15 YamakasY: of course. Centos could build and ship it if they wanted. 16:03:39 mburns: I suggest we target next week to finalize 3.4 16:03:51 otherwise we won't make the dates. 16:03:59 sbonazzo, There are 2 different things: 1. "what features would we like to get done for the next release?" and 2. "what features are almost ready to ship?" 16:04:33 dneary: looking at fedora model, feature freeze will cutoff features not 100% completed 16:04:56 doron: yes, makes sense to finalize next week 16:05:00 (doron, what are the dates for 3.4?) 16:05:16 danken: why don't we do that and compare and take stuff out of it ? 16:05:19 danken: http://www.ovirt.org/OVirt_3.4_release-management 16:05:55 may I add a feature wish? I already did via ML, but it didn't get included into google docs and I have no write access to that 16:06:14 dneary: sbonazzo I'd like for next week to have all dev leads commiting on the list of 3.4 features. Pplus a reminder to users to step in. 16:06:27 itamar: ^^^^^ 16:06:35 SvenKieske: you can ask for write access on http://bit.ly/17qBn6F 16:06:39 We need every webadmin feature accessible via rest-api, that would be all, and bug fixes :) and a working cloud-init, but that should be in 3.3.2 at least :) 16:06:48 doron: +1 from me. 16:07:16 doron: +1 for me ( I'm still trying to have write access to the list for instance) 16:07:22 we had a queston in the channel about http://wiki.qemu.org/Features/LiveBlockMigration 16:07:36 #action get a commitment for next week from all dev leads on 3.4 scope. 16:08:09 #action dneary to rmiend users list and devel list on last chance to step in for 3.4 features. 16:08:16 moving on. 16:08:21 doron, OK - put it on me 16:08:35 dneary: just did ;) 16:08:41 #topic conferences and workshops 16:08:52 dneary: care to share some updateS? 16:09:50 one thing I'm aware of is LISA 13 16:10:39 #info LISA 13 https://www.usenix.org/conference/lisa13 was held last week. 16:11:00 itamar: dneary: upcoming events / updates? 16:11:02 doron, Yes 16:11:49 First, KVM Forum/oVirt summit in Edinburgh: awesome event, there was huge interest in the KVM management presentations in CloudOpen Europe. People don't have an oVirt problem, but they do have a KVM mgmt problem in these conferences 16:12:07 The management track in the KVM Forum did well - room was over half full every session I was at 16:12:20 I recorded 2 user stories for oVirt which I still need to write up and publish 16:12:33 dneary: note presentation by you as well, of course 16:12:43 did you get notes of 'todo' stuff as you wished 16:12:51 nice* 16:13:00 The oVirt sessions were lightly attended, but the audience was a good one. Not so many note takers, I think 16:13:19 dneary: do we have all slides in ovirt.org? 16:13:27 We will get slides & notes online this week. I'm just back from another conference (OpenStack Summit) so still behind 16:13:53 #action dneary to complete uploading kvm-forum slides to ovirt.org 16:14:12 dneary: Thanks. Any other updates? 16:14:15 doron, Not sure. I know that someone started that, but haven't checked if it was complete. Thanks to Karen Noel we also have videos of all of the sessions 16:14:29 Einav Cohen also represented oVirt at LISA 13 last week 16:14:48 She wrote a conference report which I will be sending on to the users list 16:15:13 #action dneary to share LIAS report in users-ml. 16:15:23 #action dneary to share LISA report in users-ml. 16:15:42 dneary: future plans? 16:15:45 She reported a lot of interest in RHEL and Red Hat, and decent interest in oVirt. Most people she spoke to were looking for a cheaper alternative to vSphere, some were lookinbg for KVM mgmt solution, and some were already oVirt users sharing the love 16:15:58 I take it nobody is at SUSECon at the moment 16:16:21 Future plans: We have requested a stand for FOSDEM, the call for papers is currently open for the virt & cloud devroom in FOSDEM (don't have the link handy right now) 16:16:45 dneary: something we should track? 16:16:48 We also are planning an oVirt board meeting in the coming weeks. I'll send an email to the board list about it 16:17:14 doron: Absolutely! I would like to see lots of proposals on oVirt topics for FOSDEM, it's an awesome conference 16:17:16 https://fosdem.org/2014/news/2013-09-17-call-for-participation-part-two/ ? 16:17:51 We have pushed back plans for an oVirt workshop around the start of the year for logistical & budget reasons. Will keep people posted. 16:17:58 dneary: please mail me the link and I'll send reminders to users and devel lists. 16:18:09 the FOSDEM deadline is pretty soon as I recall in November 16:18:11 SvenKieske, There is one specifically for virt & cloud 16:18:40 https://groups.google.com/forum/#!topic/fosdem14-virt-and-iaas-devroom/04y5YkyqzIo 16:18:54 Submission deadline is in 2 weeks 16:18:54 #info we're looking for people to submit papers for FOSDEM. 16:20:05 #info Submission deadline: Sunday, December 1st, 2013 https://groups.google.com/forum/#!topic/fosdem14-virt-and-iaas-devroom/04y5YkyqzIo 16:20:12 thanks dneary. 16:20:23 moving on. 16:20:39 #topic infra update 16:20:46 sbonazzo: can you help on this one? 16:21:36 ewoud: eedri_ ? 16:21:38 minues of weekly meeting were at: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-11-11-14.59.html 16:21:52 there was a rackspace machine access issue and a ticket pending 16:22:21 other than that it iws relatively uneventful 16:22:47 orc_orc: thanks 16:22:52 doron: a pleasure 16:23:13 orc_orc: can we follow up on the ticket you mentioned? 16:23:28 doron: I dno not know the number ... 16:23:39 looking for filer info 16:23:39 dcaro_: ping? 16:23:59 doron: pong 16:24:03 15:01:24 so we are still blocked on rackspace migration 16:24:18 dcaro_: any updates on this ticket? 16:24:21 15:06:05 I'm in the middle of writing it 16:24:32 yep, we are waiting for someone with admin roghts to give ok to the fw modifications 16:24:45 dcaro_: reading from last week: ACTION: dcaroest reply to rackspace ticket and ask them to fix the issue (knesenko, 15:07:52) 16:25:01 dcaro_: what should we chech next week? 16:25:22 (check) 16:25:31 I'll send an email fo jim strong asking for ack 16:25:49 #action followup with dcaro_ on rackspace ticket. 16:25:53 thanks dcaro_ 16:25:58 welcome :) 16:26:13 #topic other topics 16:26:32 anything else you wish to discuss / ask / etc ? 16:26:37 I have a general question if this is the right time 16:26:53 orc_orc: shoot 16:27:18 it is a more general 'beta -> release' process question: 16:27:22 This is my first run through watching the beta cycle for ovirt 16:27:27 http://www.ovirt.org/OVirt_3.3.1_release_notes indicates we are in a BETA phase 16:27:32 yet it was said: 10:22 < sbonazzo> mburns: 3.3.1 branch has been removed after 3.3.1 tagging 16:27:36 The question is: 16:27:47 how do fixes found during the beta time get applied and a freshened beta made available for testing against the old tree ? 16:28:14 is not the old branch still needed until it is released? 16:28:16 orc_orc: a new 3.3.1 should be created for the ovirt 3.3.1 release. 16:28:34 orc_orc: I believe it was mentioned that this branch should be re-created. 16:29:02 so .. the process inadvertently removed it prematurely? 16:29:23 orc_orc: ] mburns: ofer is restoring a 3.3.1 branch and handle the tagging issue 16:29:44 doron: yes ... but as a general thing, why remove it early? 16:29:46 orc_orc: and since we havee a tag we should be able to restore it. 16:30:02 orc_orc: sounds like a mistake to me. 16:30:20 * nod * 16:30:28 anything else? 16:30:42 going once.... 16:30:52 going twice.... 16:31:09 #endmeeting