=================================== #fedora-meeting: FESCO (2012-11-28) =================================== Meeting started by mitr at 18:00:19 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-11-28/fesco.2012-11-28-18.00.log.html . Meeting summary --------------- * init process (mitr, 18:00:26) * #966 Fedora 19 Schedule proposal (DRAFT!) (mitr, 18:04:00) * LINK: https://fedorahosted.org/fesco/ticket/966 (mitr, 18:04:04) * AGREED: : Feature sumission deadline pushed back to 1/29, we'll figure out the rest of the schedule based on submitted features (mitr, 18:32:49) * 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) (mitr, 18:47:52) * ACTION: jreznik will announce F19 features and timing (mitr, 18:51:58) * #896 Refine Feature process (mitr, 18:52:13) * LINK: https://fedorahosted.org/fesco/ticket/896 (mitr, 18:52:17) * LINK: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process that is (mitr, 18:53:55) * #974 Allow releases on Wed and Thu as well (mitr, 19:24:06) * LINK: https://fedorahosted.org/fesco/ticket/974 (mitr, 19:24:10) * AGREED: Releases must be on Tuesday, Wednesday, or Thursday, but always pick Tuesday by default unless there's a specific reason not to." (mitr, 19:43:02) * Next week's chair (mitr, 19:43:08) * ACTION: notting will chair next wee's meeting (mitr, 19:44:49) * Open Floor (mitr, 19:44:55) Meeting ended at 19:47:04 UTC. Action Items ------------ * jreznik will announce F19 features and timing * notting will chair next wee's meeting Action Items, by person ----------------------- * jreznik * jreznik will announce F19 features and timing * notting * notting will chair next wee's meeting * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * pjones (105) * mitr (102) * jwb (72) * jreznik (70) * mjg59 (61) * nirik (52) * notting (48) * limburgher (30) * mmaslano (27) * tflink (12) * drago01 (8) * zodbot (7) * pingou (3) * Southern_Gentlem (1) * t8m (0) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
