15:02:21 <quaid> #startmeeting
15:02:21 <ovirtbot> Meeting started Wed Mar 14 15:02:21 2012 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:21 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:02:29 * quaid is writing the DST email
15:02:32 * mburns is here
15:02:34 <quaid> #topic roll call take 2
15:02:41 * mgoldboi here
15:02:44 * oschreib here
15:02:46 * sgordon here
15:03:01 * saggi here
15:03:23 <mgoldboi> quaid: do you know why there is no indication to the weekly meetings on http://www.ovirt.org/wiki/Meetings?
15:03:30 <oschreib> saggi is here? what happened?
15:03:32 <ovirtbot> 14[[07Features/DiskPermissions14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2796&oldid=2794&rcid=2878 5* 03Moti 5* (+12) 10/* New Action Groups for Disk Object Type */ 
15:03:57 <mgoldboi> quaid: last one appeared to happen on 2012-01-11
15:04:03 <quaid> mgoldboi:  d'oh!
15:04:04 <sgordon> mgoldboi, well there was none, then i caught it up at some point in january
15:04:09 <quaid> ah, the manual update of that, yeah
15:04:10 <saggi> oschreib: I don't know, everyone were doing it
15:04:27 <sgordon> whoever chairs should really add them each week
15:04:37 <sgordon> i recognise that last week that would have meant me and i didnt do it either :p
15:05:03 <ovirtbot> 14[[07Features/DiskPermissions14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2797&oldid=2796&rcid=2879 5* 03Moti 5* (+2) 10/* New Action Groups for Disk Object Type */ 
15:05:05 <quaid> right, I forget regularly, that's an old bad habit of mine
15:05:11 <oschreib> lol, sorry for not being here last week, but I saw you handled it well
15:05:31 <quaid> sgordon: thanks for covering last week, it really helped
15:07:28 <quaid> ok, on to ...
15:07:33 <quaid> #topic Agenda review
15:07:36 <quaid> I have this:
15:07:40 <mburns> geez, no quaid, oschreib or me last week?
15:07:53 <quaid> * DST update
15:07:53 <quaid> * Workshop update
15:07:53 <quaid> ** "Full"
15:07:53 <quaid> ** Final scheduling happening in arch@
15:07:53 <quaid> * Next release update
15:07:56 <quaid> * IRC channels discussion
15:07:58 <quaid> * Other topics?
15:08:01 <quaid> <eolist>
15:08:18 <quaid> if there is no reason to reorder that, we can add anything additional on the end of the agenda
15:08:45 <oschreib> fine by me.
15:10:20 <quaid> ok, moving on ...
15:10:24 <quaid> #topic DST update
15:10:30 <quaid> just because it came up this morning ...
15:10:46 <quaid> I sent email to arch@ to discuss this week what we want to do so it's clear for next week and forevermore-until-we-change-our-minds
15:11:08 <quaid> so for now, we don't have the meeting time pegged to DST-somewhere or UTC
15:11:22 <quaid> so, topic for list discussion, but anything to bring up here?
15:13:10 <quaid> ok, moving along ...
15:13:17 <quaid> #topic Workshop update
15:13:23 <quaid> My updates are:
15:14:13 <quaid> * We're pretty much full; jbrooks and I are getting out the latest acceptance emails, then going to find a way to properly say "full" everywhere - we're making sure we have enough to cover no-shows
15:14:46 <quaid> ** IBM folks in Beijing have been signing up people from all over, and ended up providing about 1/2 of the total attendance list, yay!
15:15:11 <quaid> * Final schedule discussion is on arch@, I think we are just about complete, so last chances for input
15:16:00 <oschreib> quaid: I think we can go, you're the only one talking. :)
15:17:44 <quaid> yep, sorry
15:17:51 <quaid> I'm fixing the meetings page at the same time, too
15:18:03 <quaid> while giving time for input before moving on ...
15:18:23 <quaid> #topic Next release update - process, criteria, etc.
15:18:43 <oschreib> Well, I wasn't here last week
15:18:53 <oschreib> and saw Moran and Steve handled couple of mails
15:18:56 <oschreib> thanks for that.
15:19:13 <oschreib> everyone is coding ATM
15:19:37 <mgoldboi> added some release criteria to http://www.ovirt.org/w/index.php?title=Second_Release&oldid=2795
15:19:47 <oschreib> mgoldboi: great
15:19:56 <mgoldboi> did anyone had the chance of going over it?
15:20:01 <oschreib> so it's looks fine now (and much better then first release)
15:20:43 <oschreib> mgoldboi: I did, looks fine to me
15:20:52 <mgoldboi> one thing i'm not clear on is what is the functional meaning of "SHOULD"s there
15:20:58 <oschreib> but I'm always in favor of raising the bar (at least in this stage)
15:21:07 <oschreib> mgoldboi: it means best effort
15:21:18 <oschreib> mgoldboi: I'll add couple of thing there.
15:21:33 <oschreib> like separating spec file for iso-uploader
15:21:40 <oschreib> and image-uploader
15:21:41 <mgoldboi> oschreib: and what happens if it doesn't pass it?
15:21:46 <oschreib> nothing :)
15:21:56 <mgoldboi> oschreib: so everything is best effort
15:22:05 <mgoldboi> we can add there our new features
15:22:09 <oschreib> in the SHOULD. yes
15:22:13 <oschreib> mgoldboi: yep.
15:22:23 <oschreib> mgoldboi: good suggestion.
15:22:25 <mgoldboi> hopefully it would work ;)
15:22:34 <sgordon> yeah
15:22:40 <oschreib> lets see if the community will respnd.
15:22:41 <sgordon> there was a bit of debate last time through
15:22:43 <oschreib> respnd*
15:22:44 <sgordon> we had UEFI as a should
15:22:53 <sgordon> but it was more like 'must unless it will take > 1 week extra'
15:23:34 <oschreib> well, that's the stuff we will encounter all the time
15:23:44 <oschreib> since we're (very) layered product.
15:23:46 <sgordon> so must is hard blockers, maybe we need to divide should into stuff that we would delay for / stuff that we wouldnt
15:24:07 <sgordon> or Must/ Should/ Aim
15:24:10 <sgordon> something like that
15:24:12 <oschreib> I think the release go/no go meeting will cover that stuff.
15:24:28 <sgordon> well again, i think the reason we are trying to get this nailed better earlier
15:24:31 <oschreib> there's no way to predict all open issues we will handle
15:24:35 <sgordon> is that we left it to the go / no go last time
15:24:43 <oschreib> true.
15:24:49 <sgordon> and people were confused because 'should' items were being treated as 'must' all of a sudden
15:25:33 <oschreib> the issue was that the release criteria wasn't defined well
15:25:34 <sgordon> i dont particularly care either way, ultimately it doesnt impact me much, but just highlighting why we are having the discussion earlier
15:26:01 <oschreib> and suddenly some guys said it super important.
15:26:22 <oschreib> even a MUST can move into a SHOULD if it will take a month to fix it.
15:26:30 <quaid> +1 to would/would not consider delaying for
15:26:44 <mgoldboi> i think most "Basic" topics are covered including host installation for ovirt-node/fedora
15:26:54 <mgoldboi> that's wasn't the case last release
15:27:55 <mgoldboi> and ofcourse if the influence will effect all of our users - even if the bug is in should we should prioritize it as must
15:28:20 <oschreib> anyway, I don't care so much. If one want's to clarify the criteria, I'm fine with it.
15:29:00 <oschreib> better criteria -> less work for me :)
15:29:16 <oschreib> that's about criteria.
15:29:28 <oschreib> I didn't see anything about the release process.
15:29:55 <sgordon> did we end up doing a mailing list vote on a release last time?
15:30:04 <sgordon> i know a lot of projects do that as a final sanity check
15:30:11 <sgordon> probably on board or arch in our case
15:30:20 <oschreib> I don't think we did that.
15:30:21 <quaid> you know, I don't thoink we did
15:30:25 <quaid> +1 to that idea though
15:30:28 <sgordon> i dont think we did either
15:30:32 <sgordon> but i think worth considering
15:30:45 <oschreib> how much +1 do we need?
15:30:49 <quaid> vote to arch@ with advisory to board@ the vote is happening over the next 24 hours
15:31:03 <quaid> oschreib: call it 3? and no -1?
15:31:09 <sgordon> yeah something like that
15:31:15 <quaid> of course, if you put it out for release, that's a +1 right there
15:31:17 <sgordon> "speak or forever hold your peace"
15:31:22 <oschreib> quaid: so only one X -1 will delay the release?
15:31:24 <quaid> sgordon: bingo!
15:31:30 <quaid> oschreib: well ...
15:31:48 <quaid> the usual with -1 is "if you can prove the merit with your argument"
15:31:51 <sgordon> usually it would be a -1 with a reason
15:32:00 <quaid> so it's not an automatic stop of the release, it's a stop of the discussion to find out why -1
15:32:01 <sgordon> if it's say the board members or lead maintainers
15:32:13 <sgordon> then you would expect the -1 to become a +1 if their concern is addressed
15:32:20 <quaid> oschreib: call it 3? and no -1?es
15:32:25 <quaid> sorry, mouse slip
15:32:45 <oschreib> well, 3 is too easy, no -1 is to hard.
15:32:57 <oschreib> but no -1 is better.
15:33:08 <oschreib> but we need to define on what you can post a -1
15:33:13 <quaid> oschreib: well, that's the way the lightweight consensus model works with -1
15:33:23 <quaid> oschreib: anyone can post a -1 for any reason, but the reason has to hold up to scrutiny
15:33:54 <quaid> I could say, "-1 - the release name is offensive in $language" - how could we predict that in advance?
15:34:03 <oschreib> so if mgoldboi will post a -1, and three other guys thinks he's completely wrong, what will happen?
15:34:18 <mgoldboi> always blaming me ha...
15:34:25 <quaid> mgoldboi's mind has to be changed :)
15:34:44 <oschreib> Fine. let's give it a try.
15:34:51 <sgordon> oschreib, the assumption is that all leads / board members are adult
15:35:02 <quaid> #link http://www.ovirt.org/governance/voting/
15:35:03 <sgordon> and will respond as such
15:35:17 <sgordon> but it's about having the conversation
15:35:21 <quaid> #info the project has governance about voting already in place about voting
15:35:22 <sgordon> to turn that -1 into a +1
15:35:47 <sgordon> be it through explanation or actually going back and changing something if it's a valid problem
15:36:19 <sgordon> just for reference to the previous topic
15:36:31 <sgordon> here is the fedora beta a blockers http://fedoraproject.org/wiki/Beta_Release_Blockers
15:36:31 <quaid> oh, look, this is covered:
15:36:37 <quaid> Votes on Releases
15:36:38 <quaid> Votes on whether a project or oVirt is ready to be released follow a format similar to majority approval — except that the decision is officially determined solely by whether at least three +1 votes were registered. Releases may not be vetoed. Generally the community will table the vote to release if anyone identifies serious problems, but in most cases the ultimate decision, once three or more positive votes have been garnered, lies wi
15:37:05 <oschreib> so, currently we don't care about -1
15:37:16 <sgordon> hmm
15:37:27 <quaid> yeah, it's a special case, I guess - we don't want to get to that point to hear about a -1 at that stage
15:38:01 <quaid> that's probably from Apache experience in people derailing releases with -1 positions they won't back down from?
15:38:22 <sgordon> possibly
15:38:34 <quaid> ok, so ... there's our process, if we want to change that :) we need to come to consensus and bring it to the Board
15:38:52 <oschreib> We need to grand someone the right to veto the -1
15:39:02 <oschreib> grant*
15:39:08 <sgordon> i think we need *some* process for handling a -1
15:39:33 <oschreib> indeed
15:40:32 <quaid> ok, I think that topic is too large and undecidable in an IRC meeting, so ...
15:40:33 <sgordon> basically the problem as worded is we dont have a process for the "if anyone identifies serious problems" bit
15:40:47 <oschreib> We need time to think about it. should we revisit this item next meeting? or open a thread about it?
15:40:52 <quaid> sgordon: well, if it's serious, won't the release manager agree?
15:41:05 <quaid> if the release manager doesn't agree it is serious, isn't that their job to determine?
15:41:17 <quaid> oschreib: open a thread about it, yeah
15:41:25 <sgordon> quaid, sure, where is that in the process
15:41:37 <sgordon> the release manager is the one who thought it was ready and put it to a vote
15:41:45 <quaid> sgordon: "the ultimate decision, once three or more positive votes have been garnered, lies with the individual serving as release manager. "
15:41:47 <sgordon> vote comes in as +3, -1 with a serious problem
15:42:00 <sgordon> that of course isnt in the bit you pasted
15:42:01 <sgordon> :P
15:42:17 <mgoldboi> -1 can delay and be examined for a week and than goes to release manager decision?
15:42:19 <quaid> if you make people accountable for their work, you have to give them the authority to do that work, even if it mean sthey might screw something up :)
15:42:40 <oschreib> quaid: mgoldboi +1
15:42:42 <sgordon> well i just think if it's a vote where we have no -1 option
15:42:43 <quaid> personally, I'm not sure I'd want to be a release manager with that - all the work and accountability without the authority
15:42:44 <sgordon> it's not a vote
15:42:48 <flrichar> I have a vm running on my ovirt setup, and I set the display for vnc ... it's prompting for a password
15:43:09 * quaid doesn't like to call this a voting process, he thinks of it as consensus tools
15:43:17 <quaid> I find the word 'vote' to be divisive :)
15:43:21 <sgordon> flrichar, you need to get a vnc ticket using the API
15:43:25 <quaid> but I didn't write this governance
15:44:05 <quaid> sgordon: I think the bit I pasted covers - there can be no VETO but that doesn't mean no -1 vote, just that it does't mean a veto
15:44:23 <quaid> sgordon: so if there are 3 +1s and >1 -1, the release manager has the job of deciding what to do
15:44:37 <quaid> but isn't able to be vetoed in that job by just any maintainer
15:45:12 <quaid> if the relmanager pushes the release and messes up because of the -1 concern ... they can be replaced for next time, right?
15:45:30 <quaid> I mean, this is FLOSS code, not medical equipment or (even more important) enterprise products :)
15:46:38 <quaid> oschreib: so, yeah, I think we should talk about this voting as part of the release process discussion on the mailing list so it's clear to everyone, and we can all decide if we like it as-is, etc.
15:46:59 <quaid> anyone want to start that thread?
15:48:11 <oschreib> not really
15:48:14 <oschreib> but I'll do that
15:48:44 <quaid> well, if you don't care, you can just include in the release process you propose that it uses the standard project voting rules.
15:48:56 <quaid> and someone else can bring up if they don't like that standard process, etc.
15:49:32 <oschreib> I do care :)
15:49:32 <oschreib> just doesn't like endless threads so much
15:49:40 <quaid> #action oschreib make sure release process points to release voting governance
15:50:01 <quaid> #action oschreib make sure arch@ is familiar and comfortable with the release voting process
15:52:09 <quaid> ok, we beat this topic up enough
15:52:42 <quaid> anything else before I move on to the next endless thread? :)
15:53:11 <oschreib> nope
15:54:01 <quaid> actually, I'm going to propose skipping the IRC topic - I thought we could move on that, but there isn't much time
15:54:05 <quaid> and enough is being said on list :)
15:54:09 <quaid> any objection?
15:54:14 * quaid waits a moment
15:54:36 <ovirtbot> 14[[07Meetings14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2798&oldid=2752&rcid=2880 5* 03Quaid 5* (+1566) 10/* 2012 */ updating to include the weeks of logs since 1/11
15:55:00 <quaid> #topic Anything else?
15:55:12 <quaid> #meetingname oVirt wekly sync
15:55:12 <ovirtbot> The meeting name has been set to 'ovirt_wekly_sync'
15:55:19 * quaid often forgets that
15:55:25 <quaid> #meetingname oVirt weekly sync
15:55:25 <ovirtbot> The meeting name has been set to 'ovirt_weekly_sync'
15:55:28 <quaid> *whew*
15:57:01 <quaid> ok then
15:57:06 <quaid> thanks everyone for your time
15:57:10 <quaid> sorry again about the timing confusion
15:57:12 <quaid> #endmeeting