18:00:19 <mitr> #startmeeting FESCO (2012-11-28)
18:00:19 <zodbot> Meeting started Wed Nov 28 18:00:19 2012 UTC.  The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:22 <mitr> #meetingname fesco
18:00:22 <zodbot> The meeting name has been set to 'fesco'
18:00:24 <mitr> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
18:00:24 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
18:00:26 <mitr> #topic init process
18:00:28 <mitr> Hello all
18:00:39 <jwb> hi.  i'm 2/3 here today
18:00:42 * notting is here
18:00:43 * nirik is sort of here.
18:00:58 <mjg59> Hi
18:01:05 <mmaslano> evening
18:01:35 * jreznik is around to serve fesco (and yeah, final blocker bug meeting happening...)
18:02:01 <jwb> maybe we should rephrase that as "block bug meeting for final"
18:02:08 <jwb> because i doubt it's the last blocker bug meeting
18:02:36 <jreznik> jwb: sure and the list is huge :(
18:03:09 * pjones is here
18:03:12 * limburgher here but busy
18:03:39 <mitr> t8m seems to be offline, let's start
18:04:00 <mitr> #topic #966 Fedora 19 Schedule proposal (DRAFT!)
18:04:02 <mitr> .fesco 966
18:04:04 <mitr> https://fedorahosted.org/fesco/ticket/966
18:04:04 <zodbot> mitr: #966 (Fedora 19 Schedule proposal (DRAFT!)) – FESCo - https://fedorahosted.org/fesco/ticket/966
18:05:08 <pjones> this schedule proposal is basically just copying the (completely terrible) f18 schedule, except actually worse, because it puts the feature submission deadline on the day after development begins.
18:05:17 <jreznik> well - what I need is from FESCo to a) set the timeframe and target date for F19 release and propose the changes as a few members were not ok with current release process (and yeah, I see that problems too)
18:05:25 <jreznik> pjones: yes, it is
18:05:41 <jreznik> but a start point and I got your point
18:06:09 <jreznik> so what I want now is discuss it
18:06:12 <mjg59> Where do we expect people to do feature development?
18:06:27 <mitr> Does the "development begins" date have any real function?
18:06:33 <limburgher> In my eyes, immediately post branching.
18:06:39 <pjones> mitr: it's just the date the branch happens
18:06:49 <pjones> it's the earliest date you can feasibly commit a change on
18:07:09 <mitr> pjones: no, branch is scheduled on 2012-02-26 in the proposal
18:07:15 <jreznik> mitr: it's the time when schedule starts - you need it for tj
18:07:26 <jwb> tj?
18:07:33 <mitr> jreznik: OK, so we can ignore it
18:07:35 <notting> mitr: no, development for f19 can begin as soon as *f18* branches
18:07:38 <jreznik> taskjuggler or any other scheduling tool
18:07:39 <notting> jwb: taskjuggler
18:07:44 <jwb> oh
18:08:02 <jwb> notting, right.  development basically already began
18:08:05 <mjg59> notting: How?
18:08:06 <jwb> or should have
18:08:08 <jreznik> but as notting pointed out - the real development can start when f18 branches
18:08:12 <jwb> mjg59, you develop in rawhide?
18:08:13 <nirik> rawhide?
18:08:18 <mjg59> jwb: Rawhide's unusable
18:08:24 * nirik disagrees.
18:08:25 <mjg59> We explicitly tell people not to use it
18:08:32 <jwb> mjg59, then we should stop producing it
18:08:37 <mitr> mjg59: that doesn't make the F19 branch usable just because we branched
18:08:48 <nirik> we should not do that.
18:08:54 <mjg59> How long was systemd broken in rawhide?
18:08:56 <pjones> mitr: oh actually, you're right - this diverges from past schedules in that previously it was the prior branch date
18:09:03 <notting> mjg59: usability of rawhide depends on what you're developing for that release, yes. but it offers you a place to put and build code
18:09:07 <nirik> mjg59: a week or two...
18:09:19 <pjones> mitr: whereas on this one it's compressed forward in time because we'd look stupid putting dates in the past
18:09:33 <mjg59> If we're going to predicate our development schedule on it being possible to do development in rawhide, we should ensure that rawhide is somewhere where people can actually do development
18:09:37 <mjg59> And that includes being able to use rawhide
18:09:42 <pjones> (well, far in the past - I note that this schedule began on monday)
18:09:44 * nirik agrees.
18:09:46 <mitr> I'm all for making rawhide more usable, but does it really affect the F19 schedule?
18:09:53 <jwb> ... yes
18:10:08 <mjg59> mitr: It does if the entire development window for F19 is basically "Rawhide, now"
18:10:12 * nirik has some ideas around that... but not sure how well any of it will work.
18:10:12 <jreznik> pjones: we did it several times - looking on slips and dates when the point "here the schedule starts" in the past
18:10:15 <mitr> What would be different in the schedule under the assumption that rawhide should not be used?
18:10:28 <jwb> mitr, because otherwise development doesn't start until f19 is branched, and when it's branched it'll be utterly broken if rawhide is
18:10:43 <jwb> branching doesn't magically make stuff work
18:11:05 <mitr> jwb: In practice development happens all the time, AFAICT the "development start" date doesn't mean much.
18:11:06 <notting> branching doesn't magically make stuff work, nor does rawhide magically break things.
18:11:11 <jreznik> jwb: and there's the problem we hit - the time between branch and alpha freeze is quite short...
18:11:13 <mjg59> People aren't going to be working on making rawhide work until after F18 is frozen for final
18:11:31 <jwb> then we push out the f19 schedule to reflect that
18:11:32 <mjg59> Which gives us, what, a month?
18:11:40 <limburgher> Ok, wild idea, why does f19 branch have to wait for f18 to be GA?
18:11:51 <jwb> mjg59, or push the schedule out to reflect reality
18:12:04 <notting> limburgher: the factor in the instability of rawhide is developer attention, not the presence or absence of a branch
18:12:05 <mitr> mjg59: 2 months between F18 release and alpha change deadline
18:12:12 <mjg59> limburgher: It doesn't, but I suspect that that just results in us having a broken F19 branch as well as broken rawhide
18:12:24 <limburgher> notting mjg59, good points.
18:12:30 <mitr> limburgher: That would make the problem of people working on the branch first and ignoring rawhide completely even worse
18:12:32 <mjg59> mitr: Yes, but nobody will be able to do any development in F19 at that point because the branch will still be broken
18:12:42 <jreznik> mjg59: yep, making rawhide from f19 branch is not option neither
18:12:44 <nirik> and it will be more work for everyone.
18:12:45 <limburgher> mitr:  Ick, didn't think of that.
18:13:17 <mitr> mjg59: So what's your proposal?  N months between final and alpha, where N >> 2?
18:13:29 <mjg59> So, basically, I'm fine with this schedule as long as rawhide is usable right now
18:13:31 * mitr would prefer dicussing specific schedule changes
18:13:37 <notting> and we also cannot *solve* that developer inattention/behavior with a schedule - although the suggestion appears to be to schedule around it?
18:13:45 <nirik> mjg59: I could try and work on rawhide sooner rather than later...
18:13:56 <pjones> notting: well, we haven't been able to solve it any other way, either.
18:14:04 <mjg59> And as long as developers are actually working on rawhide right now
18:14:14 <mjg59> Which is pretty much another way of saying that I'm not ok with this schedule at present
18:14:19 <jwb> notting, well, if we don't schedule around reality, we wind up slipping later anyway
18:14:33 <mjg59> So, eh, just move everything out a month
18:14:44 <jwb> when is the final f18 freeze?
18:14:54 <pjones> TBH I'm not sure rawhide is the issue - there's really just not enough time to do major features.
18:14:57 <nirik> well, some folks are using/building against rawhide, it's just unclear how many or if it's usable for big feature owners, since we don't know yet who all those are.
18:14:59 <jreznik> jwb: 2012-12-18
18:15:00 <mitr> jwb: 2012-12-18
18:15:07 <pjones> which is why they always land in chunks, and if they can't land in chunks we wind up pushing the schedule out
18:15:14 <pjones> as F18 so terribly exemplified.
18:15:24 <mjg59> pjones: Given the F18 slips, in theory most developers should already have landed their F18 work and could be doing F19 development in rawhide now
18:15:37 <jreznik> mjg59: yep
18:15:50 <notting> mjg59: except the ones tied to fixing f18 blockers. which also happens to be a group with a lot on the plate for f19
18:15:50 <mjg59> pjones: But obviously reality
18:16:03 <mjg59> notting: Well sure.
18:16:10 <jreznik> notting: it hits anaconda - definitely
18:16:11 <pjones> mjg59: right, and most developers don't do big features anyway, so they're not the ones that get hurt by the schedule simple not making big features possible
18:16:26 <mjg59> If we're planning more significant Anaconda work for F19 then this doesn't work at all
18:16:34 * nirik nods
18:16:37 <jwb> so...  maybe we should actually look at the f19 features first
18:16:45 <jwb> because i have no fscking idea what you're talkinga bout
18:17:06 <limburgher> So far I can only think of RPM off the top of my head.
18:17:09 <mitr> ... and to complicate it even more: Do we want to change the feature process before accepting F19 features or not?
18:17:11 <jwb> but if there is BIG SCARY THINGS, then i'd rather understand what those are and how long (estimation) they'll take before we just up and set a schedule
18:17:17 <mjg59> Well, feature submission deadline isn't for 2.5 months
18:17:29 <notting> jwb: https://fedoraproject.org/wiki/Anaconda/Work_List lists some stuff
18:17:48 <limburgher> jwb:  We could also set the schedule and approve, modify or deny features accordingly.
18:17:50 <mitr> jwb: https://fedoraproject.org/wiki/Category:FeatureReadyForWrangler is what we seem to have
18:17:51 <nirik> proposal: tenatively accept this schedule, adjust as we need to as soon as we see a compelling need to
18:17:58 <pjones> mitr: no, that just plain doesn't actually work
18:17:58 <mjg59> nirik: -1
18:18:05 <pjones> that mentality is why F18 is such a disaster.
18:18:47 <mmaslano> so what's your proposal?
18:18:59 <jreznik> pjones: well - anaconda/fedup made the mess - and yeah, there's space to make it better to fit anaconda development into schedule but
18:19:01 <notting> do people have issues with the intervals and milestones that start at 02-12 through the release, or merely *that* they start at 02-12?
18:19:07 <pjones> jreznik: bullshit
18:19:13 <mitr> pjones: what do you mean exactly?  F18 didn't have a feature submission deadline blocked on feature process changes IIRC
18:19:17 <pjones> jreznik: the schedule made this mess, and I said so before it was approved.
18:19:25 <mjg59> proposal: Schedule a feature submission deadline, set the rest of the schedule after we know what we're actually planning on incorporating
18:19:32 <jwb> mjg59, +1
18:19:44 <pjones> the reason anaconda didn't fit in to the schedule is that we made a schedule where it could not be fit in.
18:19:44 * nirik notes it's very difficult to plan without knowing anything about what people are going to try and do at this point, aside from 'new rpm'
18:19:48 <jwb> and i'd suggest setting it earlier than 2/12
18:19:56 <jwb> nirik, right.
18:20:02 <mjg59> jreznik: It's impossible to develop against rawhide and the feature development time after branch is tiny
18:20:06 <jreznik> jwb: I'm ok with setting it eariler
18:20:18 <jreznik> mjg59: that's said - I agree with this point
18:20:20 <mjg59> jreznik: So we either fix rawhide or we change the schedule such that there's an acceptable amount of development time post branch
18:20:29 * nirik thinks there's some value to at least tenative milestones after that, we can always change them...
18:20:32 <jwb> basically, i think we're saying a time based release isn't working.  let's try and be smarter
18:20:33 <notting> mjg59: i am -1 to that merely because if we're doing that we are essentially changing to be fully feature-based instead of time-based, and i'm not comfortable with that decision made in this (relative) vacuum
18:20:40 <mjg59> jreznik: It's not the fault of individual projects within the distribution
18:21:02 <mjg59> notting: Well, what are our options here?
18:21:11 <jwb> notting, time-based hasn't worked well at all.  name the last release we didn't have significant slips?
18:21:17 <mitr> -1 as well, I think given the size of the distribution we simply have to be time-based
18:21:18 <mjg59> notting: If the people working on Anaconda are going to need more time, it's not like we can ship without them
18:21:57 <notting> jwb: there was a spreadsheet. hrm. think there were a few that were in the ~2 week range
18:22:02 <pjones> mitr: I think that's a bit of a logic failure.  Most features are small - they'll fit in a schedule that's effectively time based, but the timeframe can be determined by ticket items landing.
18:22:16 <mitr> mjg59: For big changes, it means either doing them in smaller steps, or doing them in a separate branch and integrating when ready.  We have quite a few upstreams with longer release cycles than 6 months.
18:22:33 <mjg59> mitr: Fedora is Anaconda's upstream
18:22:58 <notting> mjg59: i think if we want to move to feature-based, then we should *plan* actual features and roadmaps. doing feature based, but basing it off of whatever people happen to file a ticket for seems a insufficient/misguided
18:23:09 <pjones> mitr: which means we have to decide which ones of them we want to land in each release.
18:23:11 <mitr> pjones: Yes, to some extent - but we should set an expectation of how long the release cycle is supposed to be.  Adjusting a few weeks is not a big deal, of course
18:23:19 <jwb> i still think blindly setting a schedule now is irresponsible.  set a feature submission deadline, STICK TO IT, and then flesh out the rest of the schedule
18:23:28 <pjones> jwb: I absolutely agree with that.
18:23:29 <mitr> (20 minutes, continue disscussion?)
18:23:34 * nirik thinks we shouldn't decide to switch from timebased here with no community/board input.
18:23:34 <limburgher> jwb: +1
18:23:50 <jreznik> nirik: +1
18:23:53 <mjg59> The aim should still be to release approximately on time
18:23:54 <limburgher> nirik: +1
18:23:58 <pjones> for clarity: +1
18:24:09 <mjg59> But does anyone believe that we will meet the proposed schedule?
18:24:18 <pjones> no, not even a little.
18:24:23 * nirik has no idea since it's unknown whats going to be in it.
18:24:26 <jwb> i have utterly no idea.
18:24:33 <jwb> which is why i think it's irresponsible
18:24:49 <pjones> nirik: you don't need to know that to know it'll slip.  it's somewhat compressed from even f17 and f16, which both slipped.
18:24:55 <nirik> but if we say this is what we want to try and do, feature owners might adjust to that too... ie, too short, I'll shoot for f20
18:25:06 <pjones> nirik: how's that not better?
18:25:06 <jwb> nirik, that is a good thing...
18:25:07 <mitr> mjg59: I'd expect respective package maintainers to take the schedule into account.  If they don't, we have a governance problem.
18:25:11 <limburgher> nirik: Yes.
18:25:25 <nirik> pjones: sure, but if it was 6 months longer you think it would not slip?
18:25:34 <mjg59> mitr: Again, how should people be doing development if a feature will take longer than 6 months?
18:25:36 <notting> i think time-based is a reasonable thing , if we are able to make good estimates as to what we can do in that time, and the feature owners can hit the estimates they make. in a shocking development, software estimation is a really hard problem
18:25:55 <pjones> nirik: I think if we decided upon a realistic timeframe for features we /expect/ to be in it, we can do a better time based release.
18:26:03 <pjones> I think mechanically sticking with six months is idiotic.
18:26:12 <mitr> nirik: I'm fine with not having a _fixed_ schedule now, but setting at least a rough expectation for the scale of features is important I think.
18:26:28 <jwb> notting, if we're going to stick to time-based without regard to _what_ is being put into the release, then FESCo needs big sticks to reject/revert things that went in and aren't going to make it
18:26:29 <nirik> pjones: we can't do that at this point... can we?
18:26:51 <notting> pjones: but if you set the release time after the feature submission, you then limit yourself to the greatest length of all features submitted
18:26:58 <jreznik> jwb: definitely - fesco needs that sticks and it's probably for what fesco is here...
18:27:00 <mjg59> Proposal: Fesco writes a description of the Fedora development model
18:27:03 <nirik> mitr: right, as it will help people determine if something should try for f19 or f20... or whatever
18:27:16 <jwb> notting, no, not really.  you evaluate the features and any that seem overly long-toothed you reject
18:27:16 <mjg59> And then we work out which bits of reality need to change to match it
18:27:39 <mjg59> And then, based on that, we figure out how features can be developed and design a schedule that fits them
18:27:52 <jwb> notting, basically, you actually pick features for the release instead of saying SURE SOUNDS GOOD ALL THE FEATURES
18:28:17 <mmaslano> -1 I do not want change development model, just to be more strict on unfinished features
18:28:22 <pjones> notting: no, that's only true if we set it after feature approval
18:28:36 <mitr> jwb: OTOH, most features are small and limited-impact enough that any one of them not making it is not a problem
18:28:45 <mjg59> mmaslano: We don't have a development model
18:28:48 <jwb> how is that OTOH?
18:28:49 <mjg59> mmaslano: We have at least three
18:28:56 <mitr> pjones: Hence my wish for at least a tentative schedule
18:28:56 <pjones> mmaslano: by that model we'd never be able to do the anaconda UI rewrite under any circumstances.
18:29:15 <jwb> pjones, sure we would.  we'd just have f18
18:29:21 <mmaslano> I gues we do not have new anaconda in every FEdora release
18:29:24 * jreznik is ok with tentative schedule and possible reschedule after feature submission deadline
18:29:43 <mitr> pjones, mjg59: I'm _really_ unwilling to design Fedora schedules and processes in a way that is primarily driven by current anaconda development model.
18:29:52 <pjones> mmaslano: you're missing the point, though.  it's not the only big change we've ever done, just the only one we couldn't completely half-ass for one release and fix in the next.
18:29:54 <mmaslano> jwb: pulling in only some features might be really tricky, you would need mass rebuild after pulling all accepted features
18:30:07 <jwb> mmaslano, there is nothing guaranteeing that
18:30:15 <jwb> it is certainly possible, but so what?
18:30:40 <pjones> mitr: And I'm not asking you to.  I am asking for a model that makes it possible for /some/ anaconda development model to work without causing massive problems for fedora releases.
18:30:46 <mitr> BTW,
18:30:47 <nirik> mjg59: I'd be happy to hear/see/approve/etc a development model... do we have time to do that before deciding any schedule? do we have people interested in drafting proposals for it?
18:30:49 <mitr> jwb: i still think blindly setting a schedule now is irresponsible.  set a feature submission deadline, STICK TO IT, and then flesh out the rest of the schedule
18:30:51 <mitr> had +5, sorry about missing that.
18:31:13 <mitr> Given that is agreed, can we set the feature submission deadline now?
18:31:15 <notting> proposal: move feature submission deadline back to 1/29 (fudcon + 1 week)
18:31:21 <mjg59> +1
18:31:22 <pjones> notting: +1
18:31:24 <jwb> notting, +1
18:31:30 * nirik shrugs. ok.
18:31:37 <jreznik> mitr: +1
18:31:38 <jreznik> proposal - set tentative schedule for May and reschedule after feature submission deadline if needed - put feature submission earlier
18:31:39 <jreznik> + adjust the branch/alpha deadline gap
18:31:46 <mjg59> jreznik: -1
18:31:47 <pjones> jreznik: -1
18:31:54 <pjones> in fact I think we already agreed not to do that
18:31:59 <notting> (yes, not everyone will be at fudcon, but i wouldn't want it before then)
18:32:07 <limburgher> notting: +1
18:32:26 <mmaslano> notting: why?
18:32:29 <pjones> that's +5
18:32:38 <pjones> six if we include notting
18:32:49 <mitr> #agreed: Feature sumission deadline pushed back to 1/29, we'll figure out the rest of the schedule based on submitted features
18:32:50 <nirik> fudcon lets folks discuss and get ideas/energy for things that they might not have wanted to push in before that.
18:32:58 <notting> mmaslano: gives people at least *some* getting-together place to discuss things. next possible large-scale one is devconf, and i think that's too late
18:33:08 <notting> so, i understand the 'don't set the full schedule'
18:33:18 <notting> but i think we need a 'not before' date, so we can give feature submitters a guideline
18:33:23 <mmaslano> well great for those who will be there...
18:33:34 <nirik> notting: for final release? or ?
18:33:48 <mitr> notting: yes, we need a guideline
18:33:51 <jreznik> well, it means we are going to break the May/October tradition - it should be communicated to the community + probably Board/Fedora QA should be involved too...
18:33:56 <mitr> For alpha branching, I think
18:34:13 <mjg59> jreznik: Uh. I think we've already broken that tradition.
18:34:16 <mitr> s/branching/freeze/
18:34:46 <jreznik> mjg59: no - f18 is exceptional - previously we were able to make it (+/- weeks)
18:34:46 <mjg59> notting: I've no problem with saying that final release will not be before 05-21
18:35:11 <mjg59> And I think we should do everything we can to make a release on that date
18:35:11 <notting> mjg59: and the branch date will not be before 02-26, etc?
18:35:17 <mjg59> notting: Sure
18:35:31 <pjones> jreznik: only because we pushed major features that clearly couldn't land within one release, or split them in half and made them crappy in the first of two releases.
18:35:35 <jreznik> mjg59: that is tentative schedule and we are back to the discussion
18:35:45 <mjg59> jreznik: Not really?
18:35:50 <pjones> jreznik: no, it isn't.
18:35:55 <pjones> it's intentionally not.
18:36:21 <jreznik> how it isn't? if you say branch will be not before date, ga not before (but we try to make it?)
18:36:30 <pjones> jreznik: it's saying that's the minimum time they should plan for, but we may decide, before freeze, to make it longer.
18:36:32 <mitr> pjones: Hm, so which variables are left, and which are important?
18:36:32 <mjg59> jreznik: Because changing it isn't a slip
18:36:47 <jreznik> mjg59: yes, it's tentative schedule then
18:37:01 <pjones> that's not what those words mean.
18:37:05 <mjg59> jreznik: No. We'll have a tentative schedule after feature submission.
18:37:22 <pjones> mitr: I'm not sure what you're asking
18:37:28 <jreznik> mjg59: after? you just agreed to have that guidance dates...
18:37:50 <mitr> proposal: Announce that a) Alpha branching, when features are expected to be testable, is tentatively scheduled for 2/26; b) it will not be earlier; c) it may be later, but we ask feature submitters to plan features of a scale that corresponds to the tentatively scheduled date
18:37:53 <mjg59> jreznik: Yes, guidance dates that aren't a tentative schedule
18:38:47 <pjones> mitr: -1.  "tentatively scheduled for 2/26" and "won't be scheduled for a date earlier than 2/26" are not the same thing, as we've *just* been saying.
18:39:23 <notting> this seems like a quibble over wording and the importance thereof, and we're crossing native-language speaker boundaries
18:39:32 <jwb> notting, yes
18:39:34 * nirik nods, agrees with notting
18:39:39 <mitr> pjones: If we say "you have at least 2 months to work on your feature, but feel free to propose features that need 2 years of work", that's not terribly useful
18:39:49 <pjones> if we say it's tentatively scheduled, it discourages people from checking back with what the real schedule is when we actually decide on it.
18:39:55 <mitr> AFAICS the only difference between "tentative schedule" and "no later than" is that we don't call a slip a slip
18:40:02 <jreznik> mitr: +1
18:40:25 * notting looks for better wording
18:41:03 <pjones> mitr: that's not the only difference.  the difference is actually that we *actually* haven't decided upon a time frame yet, and so it /wouldn't be a slip/.
18:41:07 <pjones> It's not merely semantics.
18:41:27 <mitr> pjones: I have close to zero trust in FESCo being able to estimate the time needed better than the feature owners.
18:41:39 <notting> proposal: fesco agrees to initially target a end-of-may release with end-of-february  branch date, but may adjust outwards depending on submitted features.
18:41:43 <jreznik> we really need better wording
18:42:00 <jwb> mitr, nobody has suggested otherwise
18:42:07 <pjones> mitr: that's ironic, because how time estimates are one of the things we basically don't ask feature owners.
18:42:10 <limburgher> notting: +1
18:42:15 <pjones> s/how //
18:42:21 <drago01> pjones: maybe we should
18:42:26 <pjones> drago01: indeed.
18:42:28 <drago01> s/maybe//
18:42:32 <mitr> pjones: I alwasys interpreted that as "We ask them implicitly by setting a schedule"
18:42:35 <limburgher> pjones: I think they're supposed to be implied.
18:42:43 <jwb> clearly hasn't worked
18:42:47 <pjones> limburgher: that's sort of the opposite of asking, isn't it?
18:42:48 <limburgher> jwb: <nods>
18:42:58 <limburgher> pjones:  Exactly. :)
18:43:12 <nirik> notting: +1 I guess. Perhaps we could/should add that we will decide the schedule at some date? after feature submission deadline?
18:43:24 <mmaslano> well yes we believe they plan features doable in the time frame
18:43:35 <jreznik> nirik: +1 as I proposed - after feature submission deadline
18:43:43 <notting> nirik: sure, tack 'after the feature submission deadline' at the end of the statement
18:43:48 <pjones> mmaslano: except when they tell us that the features aren't doable in that time frame we callously refuse to listen at all.
18:44:26 <mmaslano> hm when developer said with feature page proposal, he can't do it
18:44:46 <jreznik> notting: could you repropose it with that added after feature submission deadline?
18:44:52 <mitr> pjones: If you are talking about anaconda, I haven't seen anything like that - http://fedoraproject.org/wiki/Features/NewInstallerUI certainly doesn't suggest anything like it
18:45:14 <jreznik> and also - we should set how we decide if we make it given guidance dates or not...
18:45:18 <pjones> mmaslano: mitr: no, we discussed it *in the meeting*.  And then we put it off for 2 releases, and finally just forced it in regardless of the schedule.
18:45:25 <pjones> you can't be serious that you didn't notice any of that?
18:45:56 <mitr> pjones: 2 releases before F18 would be before I was in FESCo
18:46:09 <notting> Proposal: FESCo agrees to initially target a end-of-May release with an end-of-February branch date, but may adjust outwards depending on submitted features. Schedule will be made  at or shortly after the feature submission deadline.
18:46:19 <jwb> notting, +1
18:46:25 <mmaslano> notting: +1
18:46:33 <limburgher> notting: +1
18:46:38 <mjg59> +1
18:46:42 <pjones> +1
18:46:46 <nirik> +1
18:46:58 <drago01> notting: what's the difference between that and just use that schedule and then slip if needed?
18:47:09 <drago01> notting: seems like the same thing worded differently
18:47:25 <mitr> notting: +1 - would be happier with "feature owners are asked to scope features with the feature submission deadline in mind", considering that we apparently don't explicitly ask for that.
18:47:28 <mitr> Or do we want a different mechanism?
18:47:32 <jreznik> so two questions - we should set how we decide if we make it given guidance dates or not and how do we want to communicate this?
18:47:52 <mitr> #agreed FESCo agrees to initially target a end-of-May release with an end-of-February branch date, but may adjust outwards depending on submitted features. Schedule will be made  at or shortly after the feature submission deadline. (+8)
18:48:10 <nirik> jreznik: well, what do you mean... we will set a schedule after features are submitted?
18:48:13 <pjones> jreznik: We decide by having a discussion and coming up with proposals and voting on them.
18:48:32 <jreznik> pjones: I can take care of it
18:48:57 <pjones> o_O
18:49:25 <mitr> pjones: So that means that for features submitted early, can we or can't we -1 them based on excessive scope?
18:49:51 <pjones> of course we can.  we can -1 them for whatever reason we want.
18:49:52 <jreznik> pjones: to make it happen :)
18:50:10 <pjones> it would be best if it's not capricious, mind you.
18:50:33 <mitr> Anything more on F19 non-schedule?
18:50:53 <jreznik> mitr: yep - how do we want to communicate it externally?
18:51:07 <jwb> we... just voted on taht
18:51:09 <pjones> jreznik: ... we just approved fairly specific language.
18:51:12 <pjones> I recommend using it.
18:51:12 <jwb> with notting's proposal
18:51:13 <nirik> devel-announce... ?
18:51:30 <mitr> jreznik: I can send the announcement, or do you want to?
18:51:32 <jreznik> jwb, pjones: people would understand it as Fedora 19 has to be released in May...
18:51:43 <jreznik> mitr: I can do it...
18:51:46 <mitr> Thanks
18:51:55 <jreznik> just the concept is really ver different to "set final date"
18:51:57 <jreznik> very
18:51:58 <mitr> #action jreznik will announce F19 features and timing
18:52:10 <mitr> Moving on...
18:52:13 <mitr> #topic #896 Refine Feature process
18:52:15 <mitr> .fesco 896
18:52:16 <notting> or un-timing, as the case may be.
18:52:17 <mitr> https://fedorahosted.org/fesco/ticket/896
18:52:17 <zodbot> mitr: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896
18:52:22 <pjones> jreznik: if you feel that way, that would have been a good thing to say back when we were discussing the language to use...
18:52:24 <drago01> jreznik: well "the final schedule will be decided on xxx"
18:53:24 <nirik> mmaslano: you have some concrete proposals here for us to act on?
18:53:40 <mmaslano> we'd like to discuss the proposal
18:53:55 <mitr> https://fedoraproject.org/wiki/User:Mmaslano/Feature_process that is
18:54:17 <mmaslano> does anyone have a comment on anything from the proposal? https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
18:54:41 <jreznik> pjones: I like the language now - but still it needs more care - but... I'm ok with it
18:54:51 <mmaslano> I don't think weneed to vote on it now, but I would be glad if you read it and comment it
18:55:02 <nirik> a few things: a) standalone features that have objections should just go to fesco not get delayed to the next release... imho...
18:55:05 <jwb> i didn't have time to read it yet
18:55:36 <mitr> nirik: I think that's covered: "Every team on Fedora devel can share their views and escalate feature to FESCo to go through the regular Feature process. "
18:55:42 <mmaslano> nirik: it's about features proposed after feature submission deadline
18:55:58 <nirik> ok, then it doesn't read right to me... but ok.
18:55:58 <pjones> "The feature will be assigned to one of FESCo members, who will help with process in Fedora (technical help like where to ask for different koji buildroot, it can also point out that buildroot will be neccessary). "
18:56:04 <pjones> this seems like it's delegating rel-eng tasks to fesco.
18:56:43 <mmaslano> not really, the fesco member can help with various task (provenpackager commits, discussion with other teams, point wher to ask, how to mass file bugs, etc)
18:57:20 <mmaslano> for example filing bugs by script in past weren't without problem
18:57:36 <jreznik> pjones: it's just example
18:58:05 <pjones> yes, but I'm having trouble coming up with other examples that aren't also simply miss-delegation to fesco
18:58:39 <nirik> well, it's not that they do those tasks, its' that they help coordinate and help the feature folks talk to the right people, etc.
18:59:03 <pjones> I guess what I'm asking is - has that been a giant problem that people are having?
18:59:08 <nirik> ie, 'you should file a ticket there to get this done' 'you shouldn't mass file bugs until you talk to the FPC' etc
18:59:10 <mmaslano> the thing is at least one fesco member will be watching development of the feature closely, (s)he can help, but do not have to. No questions about status will be needed, because the fesco member will know
18:59:31 <mitr> pjones: Visiblity into feature status?  It's been a major issue recently.
18:59:32 <mmaslano> nirik: yes
18:59:37 <pjones> mmaslano: that seems unrealisticlly optimistic
18:59:39 <limburgher> mmaslano: Yes.
18:59:39 <mmaslano> nirik: if you can word it better...
18:59:51 <pjones> mitr: that's a completely different thing
19:00:02 <nirik> well, if a feature doesn't need much, feature owners may not communicate with a fesco shepard either.
19:00:07 <jreznik> and actually it fits what we agreed before for f19 schedule - there would be an overview of the scope, what has to be done - not based on percentage in the list
19:00:32 <limburgher> nirik: Then the shepherd initiates communication.  No response, drop the feature.
19:00:46 <pjones> and I don't see how it'll change the fact that if we ask for percentages, people will make them up out of whole cloth.
19:01:07 <pjones> oh, actually, I misread on that.
19:01:10 <limburgher> pjones:  They've always been, and will always be, somewhat soft.
19:01:19 <pjones> still - it's a separate thing.
19:01:21 <nirik> I guess the idea is that the fesco shepard will be able to spend some time gathering more detailed status info on features... not sure it will work out in practice, but meh
19:01:29 <limburgher> the shepherd will be able to estimate that as well.
19:01:52 <pjones> I don't particularly like the implicit idea that people serving on fesco have a lot of spare time to spend on other peoples' features.
19:02:16 * Southern_Gentlem hopes for maybe 1-2 features for f19 so it wont take so long to get out the door
19:02:25 <limburgher> pjones: It isn't necessarily a large time commitment.  That it is for a feature is itself a possible warning of trouble with that feature.
19:02:27 <drago01> nirik: and how would that work for a feature like lets say SB?
19:02:27 <mitr> Bridging the communication gap when FESCo and feature owners start with different assumptions would be the primary benefit
19:02:41 <drago01> nirik: where even the owners cannot give a timescale
19:02:43 <pjones> limburgher: that isn't really how it reads
19:02:43 <jwb> nirik, if it isn't going to work out in practice, then it would be silly to agree to do it
19:02:43 <nirik> drago01: as well as with anything else?
19:02:44 <limburgher> mitr: Yes.
19:02:55 <mitr> pjones: We expect most of the current features to fall in the "self-contained" category, so there should be 1-2 feature per member at most
19:03:08 <pjones> mitr: yes, that's why I'm discussing the other category.
19:03:40 <nirik> jwb: well, it might be worth trying was my point...
19:03:40 <pjones> Isn't this what the feature-wrangler is for?
19:04:20 <limburgher> shepherd=sub-wrangler
19:04:23 <mitr> pjones: Yes, this does add ask for workload beyond the daily meeting.  OTOH I've been spending 4-8 hours a week reviewing features in the "feature crunch" time currently, and that would go away.
19:04:51 <mmaslano> no, wrangler is looking only on feature page and status. He doesn't care about details, what would be broken. At least it was the practice
19:05:43 * jreznik is willing to do more work than what feature wrangler did before - just it would be probably insane for one person to take care of all features... but yeah, I already did a lot of these communication...
19:06:34 <mitr> Proposal: Announce process proposal changes on fedora-devel, revisit next week.
19:06:52 <pjones> mitr: *blink*.  That sounds like you're saying it gets you out of having to be prepared for the meeting.
19:06:59 <pjones> I hope that's not what you're saying.
19:07:06 <notting> mitr: proposed process changes?
19:07:06 <nirik> mitr: +1
19:07:26 <mitr> notting: right, thanks
19:07:28 <mmaslano> pjones: did you read all features before meeting, check scope etc?
19:07:34 <pjones> mmaslano: yes.
19:07:37 <mmaslano> wow
19:07:42 <pjones> That's how I spent this morning.
19:08:05 <notting> if the problem is unclear feature-owner/fesco communication, i'm not sure adding a fesco monitor *solves* it as much as works around it. we'd want to *solve* it in the long term by properly incenting that it happen, etc.
19:08:07 <pjones> (well, some of it - we have a fairly short agenda today.)
19:08:08 <mitr> pjones: For self-contained features, this means I check the assumed scope and leave the other parts to the respective maintainer, yes.
19:08:54 <limburgher> notting:  By being more willing to axes features, perhaps?
19:09:22 <mitr> notting: I'm not sure what can offer a feature owner that wants to get a feature into a release to be more realistic/pessimistic about time estimates; the urge to call it "almost done" is fairly strong.
19:09:39 <notting> limburgher: if people think punishment is the only way, that's kind of sad
19:10:17 <pjones> notting: and changing the process so that it's clear that you'll actually be doing so
19:10:17 <limburgher> notting:  Agreed, I don't want it to be.
19:10:20 <mitr> limburgher: For all but the very major features, "axing features" is mostly removing it from the relnotes and announcements
19:10:36 <mitr> That's still something, but not really a huge stick
19:10:37 <mmaslano> imho we should tell people what to do to have the feature ready
19:10:46 <limburgher> mitr:  True, and for things like ananconda, it's even less. :)
19:10:49 <pjones> right now when you change percentages and whatnot, that's absolutely *not* what you're doing, and nobody, I hope, is operating under the assumption that they are.
19:12:32 <mitr> 15 minutes on this topic, continue?
19:13:01 <notting> for the two parts of the proposal, the first ('self contained features') the goal is... reduce perceived fesco busywork?
19:13:09 <notting> perceived and/or actual
19:13:28 <jreznik> notting: to reduce fesco work but also to lower the barrier to propose feature
19:13:35 <jwb> ugh
19:13:35 <mitr> notting: {fesco, feature owner}, and at the same time, make every feature significantly more visible to fedora-devel
19:13:58 <jreznik> and visibility as mitr said
19:14:16 <notting> jreznik: if it's still a properly-filled out feature page, barrier is the same
19:14:47 <jreznik> notting: I know many people who do not want to propose feature because "fesco is going to nack it" - not a good attitude, indeed :(
19:15:09 <jreznik> the same can happen with review on f-d but...
19:15:10 <jwb> i don't think this proposal really addresses the major problems with the feature process
19:15:25 <notting> the second part of the proposal is to increase/force better communication?
19:15:54 <jwb> jreznik, then in those situations, it's probably very clearly NOT a feature to begin with
19:16:05 <pjones> I don't think the barrier to propose features is very high - it's all the work after you propose them that's a pain
19:16:09 <jreznik> jwb: the major problems are features we are not aware of... as fedup for example
19:16:15 <pjones> (where I use the term "work" quite loosely.)
19:16:24 <jwb> jreznik, this proposal doesn't do anything to address that
19:16:40 <mmaslano> jwb: how do you want to fix that?
19:16:51 <jreznik> jwb: no - it's really refinement - and not the whole overhaul of feature process
19:17:34 <jwb> mmaslano, the ticket is open still.  i haven't gotten time to really write down anything concrete
19:17:39 <mitr> jwb: "Feature" process started as "we need to collect marketing items", now we see it more as "we need to coordinate technical changes" - which sense do you use in "not a feature to begin with"?
19:18:05 <jwb> neither?
19:18:09 <jwb> look, our feature list is bullshit
19:18:16 <jwb> there are too many damn features
19:18:23 <jwb> some of them are clearly features
19:18:30 <jwb> others are simple "UPDATE PACAKGE BOO"
19:18:37 <jwb> they're all on the list with the same weight
19:18:43 <pjones> many of those are managers telling engineers "you need to get things on the feature list to improve visibility"
19:18:43 <jwb> most of them aren't features
19:18:44 <jreznik> btw. Board would like to make a call for FUDCon to work on Feature process
19:18:57 <pjones> jreznik: shocking.
19:19:03 <pjones> just what does the board actually do?
19:19:36 <pjones> (not a serious question, of course.)
19:20:02 <jreznik> jwb: it depends - not the same weight from different povs too
19:20:04 <drago01> jwb: exactly
19:20:34 <jreznik> is "python 3.x" feature? it's just update - but could lead to a massive change...
19:20:45 <mitr> jwb: This proposal would make the different weight more visible
19:20:45 <notting> jwb: well, that's what the first part of the proposal was, was to split out... "items of note"... into a separate category
19:20:56 <pjones> yes, clearly it is.  It's both a major technical change and something that might cause people to use (or not use) Fedora.
19:20:58 <notting> if we want to change more around what "items of note" have to do, we could
19:21:05 <jwb> "Update D programming environment"  "Boost 1.50" "Fontconfig 2.10"  none of those a features in a distribution that FOCUSES on updating stuff every release
19:21:21 <mjg59> I don't want less review of those features by fesco. I want *no* review of those features by fesco.
19:21:33 <jreznik> jwb: for people using D programming env - it could be useful feature to know the changes...
19:21:34 <jwb> mjg59, yes
19:21:41 <jwb> jreznik, that doesn't make it a Feature
19:21:46 <mitr> That's 25 minutes on this topic, and I think another group wants to use the channel in 9 minutes.
19:21:49 <jwb> it makes it something to put in the rel-notes
19:21:51 <mitr> Defer to next week?
19:21:53 <jwb> yes
19:21:56 <jwb> or fudcon
19:21:58 <pingou> mjg59: I would see, one, but just one at first
19:21:59 <jreznik> jwb: it's definitely feature for D users...
19:22:08 <jwb> jreznik, they can read it in the release notes
19:22:10 <mmaslano> I'd rather discuss it next week
19:22:11 <limburgher> next week
19:22:17 <mmaslano> not all of us will be in US
19:22:27 <mjg59> pingou: I'm sorry, I don't understand
19:22:33 <jreznik> the question is - could we delegate it? to SIGs? to devels?
19:22:46 <pjones> mjg59: I ... think he's suggesting a test run?
19:22:55 <pingou> mjg59: all features should go through fesco at least once, other should more than one (imo of course)
19:22:55 <pjones> not sure how you'd orchestrate that.
19:23:05 * jreznik is completely ok with that too (actually it's part of self contained features - if SIG thinks it's ok, it's ok for FESCo)
19:23:17 <mjg59> pingou: Currently all features go through fesco once. I don't think that's desirable.
19:23:33 <jreznik> just please add comments to the ticket :)
19:24:00 <pingou> mjg59: since time is running out, let's agree to disagree for now :)
19:24:04 <mitr> Moving on...
19:24:06 <mitr> #topic #974 Allow releases on Wed and Thu as well
19:24:08 <mitr> .fesco 974
19:24:10 <mitr> https://fedorahosted.org/fesco/ticket/974
19:24:10 <zodbot> mitr: #974 (Allow releases on Wed and Thu as well) – FESCo - https://fedorahosted.org/fesco/ticket/974
19:24:18 <jreznik> mjg59: as I said - I'm not against delegation, it's part of the proposal - and fesco gets just list to ack... so not even once...
19:25:01 <mitr> I'm -1 - I think a weekly meeting overhead is about the maximum acceptable
19:25:23 <pjones> So... the only comment was on an orthogonal issue.
19:25:25 <limburgher> I want more time to think it over.
19:25:38 <tflink> pjones: maybe I'm misunderstanding, then
19:26:04 <notting> i am... ok with the idea of shipping on days other than tuesday in general, but against the idea of a floating release day in the release week that's not known until 5 days before
19:26:23 <pjones> the problem is of when we can reschedule things like the go/no-go to when we do decide to reschedule.  It has nothing to do with the time frame and everything to do with overly constraining ourselves on the /results/.
19:26:28 <jwb> notting, i'm sick at the moment and having trouble parsing that sentence
19:26:42 <mitr> pjones: If there is a weekly go/no-go meeting, under what circumstances would you use a different day than the earliest available?
19:27:14 <mitr> And if the go/no-go meeting is not weekly, what is the frequency?
19:27:19 <jwb> has anyone asked the mirrors?
19:27:33 <jwb> because if they don't support this, it's moot to discuss it
19:27:40 <pjones> mitr: situations like (but not exactly like) last week where we postponed it to a holiday and could have benefit from postponing it one more day instead, but we couldn't, because we're married to tuesdays.
19:27:42 <jreznik> jwb: yep, mirrors are first to ask
19:27:51 <jwb> but has anyone actually asked?
19:27:59 <nirik> not that I know of.
19:28:07 <mitr> Can anyone take that action item?
19:28:09 <jwb> then i propose we revisit when someone has
19:28:16 <nirik> I think they are fine as long as we have long enouhg to mirror stuff to them.
19:28:22 <jreznik> jwb: someone commented it in the thread why Tue was selected
19:28:27 <nirik> I can't see why they would care what day of the week.
19:28:30 <tflink> I think that final go/no-go #1 is currently scheduled for 2013-01-01
19:28:46 <notting> jwb: i don't like the idea of deciding around go/nogo the week before whether you're releasing the next tuesday, wednesday, or thursday
19:28:48 <jreznik> nirik: so it's more about - time to mirror stuff that just day of week?
19:29:10 <jreznik> nirik: you are probably closest to mirrors - could you ask the most important ones?
19:29:11 <pjones> notting: no, but we wind up having to do that anyway
19:29:24 <pjones> because of our terminal slippage problem
19:29:25 <nirik> jreznik: I can ask on the mirror list, but I don't know that they would care...
19:29:51 <jreznik> nirik: if they would not care - then it's ok to not to stick with Tue
19:30:02 <notting> pjones: surely we're slipping because we *aren't* terminating the schedule ok i'll stop myself now
19:30:18 * nirik is with tflink on the 'constant status meetings crap because we are slipping less than a week'
19:30:28 <jwb> i've completely lost wtf we're talking about
19:30:34 <tflink> I don't really care which day of the week release or go/no-go is, as long as we don't end up doing a perpetual "we'll release tomorrow if all these tests pass"
19:30:41 <pjones> nirik: also agreed - but this ticket has nothing to do with that.
19:30:43 <nirik> anyhow, proposals seem to be 'more time' or -1 on this?
19:31:40 <jreznik> tflink: it could help in that times - we have one final blocker bug, do we want to push release by one week for this one or not?
19:31:45 <tflink> pjones: then I'm still not following you 100%. I understand the intent but I don't see how this isn't opening the door to the chaos I'm concerned about
19:32:02 <notting> so, perhaps i'm misunderstanding
19:32:04 <tflink> jreznik: what about 2 blocker bugs?
19:32:06 <notting> is it:
19:32:07 <tflink> or 3
19:32:28 <pjones> tflink: it's not saying somehow that less time is okay.  If we keep the time window the same, right now we can't move a g/ng to friday because we can't ship on wednesday, and for no other reason than having decided that we ship on tuesday.
19:32:36 <notting> Proposal: when scheduling a G/NG and release date one week or more in advance, allow shifting it so that release is on any of tuesday, wednesday, or thursday?
19:33:12 <pjones> notting: that's... pretty much exactly the proposal in the ticket.
19:33:30 <tflink> pjones: I'm fine with that as long as there is wording that doesn't allow for last-minute changing of dates for release in the hope that a blocker will be fixed
19:33:31 <mjg59> tflink: This is about avoiding the case where we have to have a G/NG on a national holiday because otherwise we have to slip by another week because we can only release on Tuesday
19:34:13 <mitr> pjones: I don't think that notting's wording would have solved the "we can't slip only 1 day" problem that motivates the proposal.
19:34:31 <mitr> Or perhaps I'm confused
19:34:42 <tflink> like I said, I don't care which day of the week we release on. I just don't want to open the door to the added chaos of "we only need one more day, lets' move go/no-go to tomorrow and panic while getting through all the test cases"
19:34:48 <mjg59> tflink: Given that QA are still going to be the ones deciding when there's a G/NG meeting, I think you're free to impose additional constraints
19:34:51 <notting> mitr: i *think* what the 1-day problem motivated was 'if we had moved the G/NG and release date forward when we slipped earlier, we could have avoided this', or something.
19:35:05 <notting> not necessarily 'we want to slip 1 day now'. or perhaps i'm confused
19:35:06 <tflink> I thought that go/no-go was PM, not QA
19:35:35 <mjg59> Wait, how many definitions of PM are we up to now
19:35:45 <nirik> it's fesco/rel-eng/qa votes I thought?
19:35:59 <tflink> for go/no-go, sure but I thought he was talking about the date of the meeting
19:36:00 <notting> QA feeds heavily into the go/nogo decision, as the item most likely to cause a nogo
19:36:09 <mjg59> Whatever. From a *technical* perspective, which is what fesco should be determining, I don't see any problem with this as long as it's fine with the mirrors
19:36:29 <mjg59> If other teams want to impose additional constraints on the timing of meetings then I think those teams should do so
19:37:02 <mjg59> Basically: Is there an engineering reason why the release has to be on Tuesday?
19:37:10 <mjg59> If not, we should approve this
19:37:57 <tflink> depends on if you consider tester sanity an engineering issue, I suppose
19:38:12 <jwb> i have no idea why it's even under our responsibility to approve or reject it
19:38:28 <pjones> jwb: apparently we're the people who decided it has to be on tuesday?
19:38:39 <pjones> and if we don't decide otherwise, who will?
19:38:48 <nirik> so, 'go/no-go can be on thursday or friday, for a tuesday or wed release the following week'?
19:38:58 <mjg59> tflink: No, I think that's an issue that QA should handle
19:39:01 <jwb> pjones, the people responsible for releasing things?  i think they're called rel-eng
19:39:03 <pjones> nirik: right
19:39:19 <nirik> thats much more clear to me, if thats what is being proposed. ;)
19:39:33 <mitr> mjg59: "Development, QA, and Release Engineering meet" from https://fedoraproject.org/wiki/Go_No_Go_Meeting?rd=Engineering_Readiness_Meetings
19:39:40 <pjones> nirik: or if it is somehow better, even saturday for a thursday release.  I don't see when that would be better, but I'd prefer we not limit ourselves.
19:39:57 <notting> well, inasmuch as fesco approves schedules, we implicitly picked the tuesday dates as the ones we approve
19:39:57 <jreznik> nirik: it's one part - if we want to skip holidays etc... other part is - do we want to do it for example if we are out of time etc?
19:40:19 <nirik> pjones: I suppose.
19:40:19 <pjones> notting: right, but last week we thought that we were constrained by that.  So I'd like to officially say that we're not.
19:40:28 <nirik> jreznik: out of time?
19:40:31 <tflink> mjg59: becasuse we have so much control over what's thown our way. I see your point, though even if I think that solution is a tad impractical
19:40:58 <pjones> tflink: it would have been more practical than what we actually did last week.
19:41:00 <jreznik> nirik: like we want to avoid release on Christmas day? as we were talking about it? etc.
19:41:03 <notting> pjones: *shrug* fine with me +1
19:41:12 * pjones is also +1
19:41:27 <nirik> ok, fine +1... lets pass it and move on.
19:41:39 <limburgher> +1 as well.
19:41:43 <mjg59> +1
19:41:50 <jwb> +1
19:41:53 <mitr> +1
19:41:56 <mmaslano> +1
19:42:38 <mitr> "Releases must be on Tuesday, Wednesday, or Thursday, but always pick Tuesday by default unless there's a specific reason not to."
19:42:44 <mitr> Is that what we agreed upon? :)
19:42:56 <pjones> yes :)
19:43:02 <mitr> #agreed Releases must be on Tuesday, Wednesday, or Thursday, but always pick Tuesday by default unless there's a specific reason not to."
19:43:08 <mitr> #topic Next week's chair
19:44:28 <mitr> Would anyone like to volunteer?
19:44:33 <notting> sure, why not.
19:44:36 <mitr> Thanks
19:44:49 <mitr> #action notting will chair next wee's meeting
19:44:55 <mitr> #topic Open Floor
19:45:00 <mitr> Anything for open floor?
19:45:19 <limburgher> Not here.
19:46:09 * nirik has nothing.
19:47:01 <mitr> OK, thanks all!
19:47:04 <mitr> #endmeeting