17:00:18 #startmeeting FESCO (2014-10-01) 17:00:18 Meeting started Wed Oct 1 17:00:18 2014 UTC. The chair is mattdm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:19 #meetingname fesco 17:00:19 The meeting name has been set to 'fesco' 17:00:21 #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:21 Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:23 #topic init process 17:00:27 Hello 17:00:37 morning 17:00:37 good $TIMEOFDAY, everyone 17:00:40 hello everybody 17:01:01 hi 17:01:34 * mattdm waits a couple of minutes 17:02:44 hhhffhi 17:03:02 okay good enough :) 17:03:09 #topic Fedora 22 scheduling strategy (and beyond) 17:03:10 .fesco 1349 17:03:12 mattdm: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349 17:03:12 https://fedorahosted.org/fesco/ticket/1349 17:03:26 heh somebody is hijacking my keyboard :) my 3 year old son actually 17:03:33 So I was glad jreznik showed up to explain that I'm not totally crazy 17:03:39 * nirik waves to t8m's son. ;) 17:03:46 * mattdm waves too 17:04:02 That is, the documented process and actual process have drifted 17:04:04 so, yeah, we have played with this in recent years... trying to see changes first, etc 17:04:32 * jreznik will become crazy one day from scheduling but ... 17:05:02 Do we have an opinion after these various approaches taken which one was the best? 17:05:09 mattdm: I'll do a few more updates to the Fedora Release Life Cycle but adamw did a great job 17:05:28 I think jwb is right in that being strict with the schedule has specific assumptions / consequences 17:05:29 We could probably ignore the F18 and F21 cases though as exceptions. 17:05:30 jreznik: we do still need to sort the Change/Feature Freeze issue 17:05:55 adamw: yeah I think that's the next agenda item? 17:05:55 I'm here. Sorry for being late 17:06:04 yes, it is 17:06:24 adamw: well, the nominal topic is "consider renaming..." but there's all the other stuff too. 17:06:29 adamw: I'm not completely sure I understood that issue 17:06:34 so I think it's good for people for us to have 'normal' targets we try and meet... 17:06:48 but each release might be different and of course 18/21 were/are 17:06:50 hey all 17:06:58 hi dgilmore 17:07:03 jreznik: we'll cover it under the next agenda item :) 17:07:24 nirik: on the other hand, we had 19, 20 that worked pretty well 17:07:58 it seems to me like we generally follow the system described on Life Cycle once we decide what the target date is - it seems like once a target date is agreed, that schedule is more or less put into place in relation to it. and then we inevitably miss a couple of the Go points and slip. 17:08:05 nirik: yeah, so, I guess I think we should either strongly commit, or else change the documentation to say that releases are unpredicatable but roughly 7 months apart 17:08:32 I’m not quite sure that the difference matters, considering the next FESCo can always change their mind. 17:08:43 (and with 7 months, I mean we'd keep scheduling 6 months but be honest that the week of slip matters) 17:08:47 right, or even this fesco deciding f22. 17:09:51 adamw: I'm going to write "no earlier than" to that page 17:10:12 what does strongly commit mean? that we say 'these 2 dates always' and actually remove scheduling discussions from fesco? :) 17:10:30 * nirik admits that has some appeal. ;) 17:10:38 mattdm: i say we strongly commit and work out ways to allow longer term development of things like anaconda rewrite. or allowing a longer cycle slip for things like Fedora.NEXT but that be considered on a case by case basis 17:10:51 nirik: that's a very practical way, yes :) 17:10:54 theoretically it means Changes without feasible rollback plans are never accepted 17:11:05 or if they are accepted, it's a one-off release 17:11:17 Perhaps the answer is that we always target those two dates and agree up-front if we need a longer cycle that we skip one 17:11:23 which makes things like e.g. major gcc upgrades harder 17:11:29 The schedule could be kept much better if we actually developed on rawhide and do only minimal changes after branching. 17:11:30 jwb: we allow for them to be developed on the side and rolled in when ready 17:11:36 or if they are accepted and they are catastrophic, we eat the catastrophe. (sorry, X in this release doesn't work!) 17:11:40 sgallagh: and if we don’t need a longer cycle but the scheduling ends up with a 3-month cycle then we do one? 17:11:45 (er, where "X" hopefully isn't _actually_ X) 17:11:55 dgilmore, sure, that's doable if we think we can sustain 2x development and support costs 17:12:01 i'm still skeptical we can 17:12:10 and the development of the next release started immediately after branching the current one 17:12:19 t8m, yes. 17:12:22 t8m: right 17:12:34 jwb: shorter term we can't longer term I am sure we can 17:12:34 well, an option would be to avoid branching that early, to avoid the 2 parallel development branches 17:13:06 kalev: yeah, I was kind of kicking that around. in effect, it means that we go into freeze very shortly after branching 17:13:08 as in, branch after Beta, or something, and impose all the freezes from alpha till beta to the rawhide / master branch 17:13:14 and I think adamw threatened to resign :) 17:13:16 kalev: the other side of that is that we couldn't stablize for say alpha very well if a constant flow was coming in 17:13:39 kalev: thats not an option. We would have to go back to freezing rawhide and roll back no frozen rawhide 17:13:49 mattdm: What do you actually see as the benefits of strict deadlines? Of the benefits you cite, most can just as well live with the ~6-months-ahead visibility we get with scheduling one release at a time; and for those that would benefit from a longer visibility (conferences, support), slips are big enough a factor to make the schedules unreliable anywa. 17:13:49 One thing that could reduce ongoing maintenance burden would be to stop allowing an updates stream for anything but security bugs. 17:14:00 So all new functionality goes into F N+1 17:14:03 dgilmore: right, that's exactly what I'm suggesting 17:14:15 mitr: I think it helps people plan for their longer-term features better. 17:14:28 kalev: I do not think that really gains us much 17:14:34 sgallagh: non security bugs are also bugs that are worth fixing 17:14:36 mitr: upstream projects (gnome, etc) could know approx when to do things... also we avoid (mostly) big chunks of holidays 17:14:36 we could possible have Bodhi in effect on the rawhide branch, so that we'd have the updates-testing repo and bodhi tagging builds to the rawhide branch after the freezes kick in 17:14:39 cutting the stable release churn will 17:14:49 If I know that a release is coming out in may, that's a lot more meaningful than a "sometimes something like six months after whenever this one gets done" 17:14:50 drago01: It was a hypothetical. 17:14:54 making the cost of spinning releases would help 17:14:57 mattdm: Does the difference between 12 and 14 months ever matter? (If so, I would like to intern with the person who has learned to do software effort estimation that well.) 17:15:06 as in the human time in doing it, and having faster turn around 17:15:10 kalev: that sounds like turning rawhide into branched. ;) which would requre a ton of effort 17:15:18 personally, I think current way of doing schedule is a good compromise... of course, doing more development in branches could be one way how to make things working better but it also has some issues - especially a lot of stuff can get out of sync (aka anaconda f18 days) 17:15:19 mitr plus I think the impact on events like flock is really large 17:15:29 nirik: yep, it would require considerable tooling effort, no disagreement there 17:15:33 Robyn _wanted_ flock to happen right after a release 17:15:34 mattdm: its never been something like six months after this one 17:15:52 dgilmore: assuming six is something like seven :) 17:15:56 mattdm: its always been may/october f18 threw things for a loop 17:16:08 mattdm: But then for Flock we don't want the schedules to be long-term predictable as much as we would like to not slip 17:16:15 dgilmore: well, but see jreznik's comment. 17:16:25 mattdm: events will always depend on free and free space 17:16:50 unless someone comes with a huge pack of money to schedule flock out of holidays season 17:16:52 mitr: we can plan for some amount of slip and still keep basically away from conference times 17:16:54 mattdm: Because even if we can’t move Flock we could have moved the release instead—but that fails because we don’t know how much we will slip. 17:16:54 mattdm: some people are currently ignoring rawhide and will do so until f21 is out 17:17:10 we're kind of having two parallel conversations here. 1) the fact that rawhide isn't really buying us much other than a free-flowing repo to throw stuff so how do we make it more valuable and 2) the schedule 17:17:12 mattdm: but right now is the best time to get the most disruptive changes into rawhide 17:17:22 jwb: yeah 17:17:24 dgilmore: yeah, so that's where the idea of freezing the branch immediately has appeal. 17:17:28 dgilmore, which is hard to do when everyone is busy fixing stuff in branched. 17:17:30 downside, qa team all quits :) 17:17:30 jwb: true. 17:17:57 jwb: this is true also. 17:17:59 I'm not sure we have many really distruptive changes in the undergoing release 17:18:02 well, IMHO it's not hard to fix in rawhide and branched in general. New versions are trivial 17:18:13 jwb: not everyone ignores rawhide now but a lot do 17:18:14 and if we have, we should be able to say "please no" aka nm-09 17:18:16 fwiw i'm kinda on the 'not really seeing a problem to fix' side 17:18:21 people who are not doing it just need to adjust their workflow. 17:18:32 We can only freeze that much, or restrict post-GA updates that much, if the thing we freeze is stable enough for us to live with the software for the next ~8 months; which IMHO it usually isn't. 17:18:54 adamw: on schedule? 17:19:07 I don't think restrictions magically make people work on something else 17:19:48 drago01: The prohibition on UI changes post-.0 seems to work remarkably well for GNOME 17:20:11 i don't think flood of updates magically make the branched/released distro better 17:20:16 drago01: Same here: it is a matter of timing / delivery mechanism for the work, not resigning people to different activities. 17:20:22 jwb: I don't disagree 17:20:30 there's a balance. it has not been achieved. how do we achieve it. 17:20:32 s/resigning/reassigning/ 17:20:42 adamw: Schedule wise I agree 17:20:59 So, I think what I'm hearing overall is that having rawhide in better shape continously is probably a practical prequisite to consistent calendar-based schedules 17:21:04 mitr: my point is rather if someone works on FN you cannot just "close the doors" and he will magically go and work on fn+1 17:21:12 * nirik doesn't think rawhide is in that bad a shape. 17:21:28 nirik, i don't think it's in bad shape. i think it's pure luck that it isn't though 17:21:29 We're doing an awful lot of "Here's one thing we can do" without a whole lot of "What are we trying to accomplish?" 17:21:46 * jreznik doesn't think we have that many issues with not-frozen branched under development 17:21:47 nirik: would you be comfortable freezing it at any arbitrary point and giving it a month to stabilize before release? 17:21:47 jwb: well, luck and some poking by various people when it goes off the rails. 17:21:49 nirik: on rawhide. i can see possible value in tweaking schedule approach slightly, i guess, though the overall 'time/feature hybrid' model seems decent. i really don't see what problem there is to fix in rawhide. 17:21:56 nirik, perhaps luck plus some help from a dedicated few 17:21:59 nirik, heh, jinx 17:22:13 mattdm: no. Why? I think it's valuable for it to not freeze 17:22:32 i would say we really haven't seen many cases where someone did something insane during the 'unfrozen' periods that caused significant destabilization 17:22:35 nirik sorry, _branching_ from any arbitrary point and shipping that. 17:22:51 adamw: yep, that's something I'm trying to say 17:22:59 I think there are definitely cases where branched is frozen and people push changes to rawhide and branched and find out their change is bad and fix it because they could see it in rawhide. 17:23:15 it's again a good compromise between frozen and completely open development 17:23:38 at the same time, our current development force is split in two, some people are running rawhide and some branched, same goes with testers 17:23:45 mattdm: well, there are points where large changes are landing... mass rebuilds, perl rebuilds, stack X is landing, etc... aside those I dunno. I guess one time is as much good as another... 17:24:14 I think we could improve rawhide stablity with some gating, which we are working on. ;) 17:24:18 kalev: well, wasn't that sort of the *point*? 17:24:18 nirik: the perl rebuild is actually on a branch -- and it could just as well be there if the whole rawhide is frozen 17:24:29 I haven't actually seen anyone address the top-level questions about releases: "Do we want two releases per year, and what does that gain us? Is it innately better than some other arbitrary number of releases?" 17:24:43 no-one seemed to be particularly happy with freezing rawhide because some people wanted to do 'development' work when it was frozen 17:24:56 * nirik isn't sure how this turned into rawhide discussion, perhaps we should refocus at a higher level? ;) 17:25:03 it's therefore inherently the *expectation* of a no-frozen-rawhide model that the 'workforce' will 'split' in the way you describe 17:25:09 if it *didn't*, that would make no-frozen-rawhide pointless 17:25:11 nirik: I was kind of trying to do that with my question there. 17:25:19 yeah, let's maybe focus on the scheduling for now and leave rawhide for another time 17:25:48 FWIW, we are close to having rawhide signed, and then we can add some gating tests to composes... but anyhow. 17:25:58 adamw well, not necessarily. as it is, we have a split in _development_. but it could be that just the testing and stabilization splits. 17:26:07 sgallagh: I'd say that it makes sense to do releases either in 6 or 12 month schedule; this makes it easy to sync with upstreams as a year / half a year is a natural thing for humans to schedule with 17:26:23 I do have plans to work on making rawhide not break 17:26:41 I think a year-long release makes a lot of people unhappy and anxious and am not eager to do it again soon 17:26:49 so, six months seems good. 17:26:50 sgallagh: I don’t have an _equation_, but overall the timing of the post-branch process and the experience with F21 does suggest that something about 6 months is simply a sweet spot of new/exciting vs. able to publish a sufficiently polished release. 17:26:58 sgallagh: yeah, I think a number of our upstreams do 6mo cycles. it seemed to be a sweet spot between too fast and too slow in the past. 17:27:00 kalev: Well, different projects have different schedules 17:27:17 Two of our most important happen on multiples of 3 months, so that's probably a good baseline. (Kernel and GNOME) 17:27:19 mitr: jinx. ;) 17:27:23 mattdm, s/people/developers 17:27:38 jwb no, users 17:27:55 there is no way i would agree a "lot" of users dislike a yearly release 17:28:01 also longer cycles means supporting older code for longer time 17:28:15 * sgallagh nods 17:28:16 i.e like the f19 "zombie" 17:28:26 jwb: nope but they get frustrated that the stuff they care about isn't updated 17:28:27 another question might be... if we do 2 releases a year, should we look at supporting 3 releases? :) (ie, 18months) 17:28:31 * nirik runs 17:28:32 mattdm: 6-9 month cycles i think 17:28:34 mattdm, the majority of the comments i hear from people about why they don't use fedora is there is too much churn and not a long enough cycle to make it worth it 17:28:48 another thing we could do is make base fedora releases on 6 month schedule, but if some of our Products want to skip every other release, we could release those images on 12 month schedule 17:28:48 mattdm: 12 months Is too long between 17:28:53 ??? 17:29:05 kalev: why? 17:29:15 jwb same old thing. cake and eating it. 17:29:16 server once a year and workstation every 6 months 17:29:17 kalev: That’s again verging into implementation vs. _what do we want to do_ 17:29:22 dgilmore: same here, 6-9 17:29:37 mattdm, yes, but it's disingenuous to say the 6mo release is for users. 17:29:41 Southern_Gentlem: That's worth considering, certainly, but let's worry about the Fedora Project as a whole first 17:29:58 do we have numbers on how long our cycles actually are? 17:29:58 sgallagh, i am 17:30:03 kalev: as soon as we start doing that the distro is forked, and the cost and burden of maintainence goes through the roof 17:30:06 mattdm, because the users don't care about the _release_. they care about their apps. if the base OS didn't change for 12 months, nobody would care other than the people working on the base OS 17:30:07 I’m leaning towards 9 being too long FWIW. 17:30:08 I have long thought 9month cycle would be great, but the problem is that it hits holidays after a while... 17:30:08 there aren't 6 months anyway due to slips 17:30:18 dgilmore: I think Server had plans to do this, that's why I brought that up 17:30:18 jwb: agree. 17:30:19 jwb: on the other hand look what people do, when there's no update for theirs android device... seems like the whole industry goes to shorter release cycle 17:30:37 The only real feedback I have got at conferences- is for trying for maybe 6-9 more months of lifespan- once a year is scary to me as Fedoran, FOSS person :) 17:30:37 although someone on users list was complaining about mesa, so hardware enablement factors in too 17:30:44 so we should take a look how to make upgrades easier (we really sucks there) than prolonging support 17:30:45 drago01: distrowatch tracks release dates 17:30:55 jreznik, eh, i understand your point but i don't believe it's a fair comparison to make. 17:30:56 jreznik: We don‘t have that security problem, I’m not sure there is any lesson to be learnt 17:31:00 anyway back to the top issue since we're half an hour in.... 17:31:01 drago01: http://distrowatch.com/table.php?distribution=fedora 17:31:05 kalev: We've talked about doing "point releases" that come out along with the Fedora schedule but don't change ABI; it's a little different. 17:31:26 And off-topic for the moment :) 17:31:29 jwb: well and they want there hardware they just bought to work *now* not a year latter (currently not that much on issue because of kernel rebases but still its part of the "base os") 17:31:35 *later 17:31:41 I'm willing to go with "schedule as needed" for now, even though I like the idea of "cut from rawhide at any point and it's good to go" for an aspirational target 17:31:43 so really, fedup should be the first thing to take a look... I can't imagine telling users to use fedup... 17:31:43 adamw: thanks 17:31:44 drago01: we hit November every year from 2007 to 2011 17:31:55 F18 should have been a November release; it broke hte streak 17:32:29 we did an intentional 9 months cycle in earlier 17:32:35 can't recall which relase that wa 17:32:36 s 17:32:42 F8 or F9 17:32:47 mattdm: so, whats our proposal or action here? just update the wiki with 'as needed' and move on? or ? 17:32:57 ok 17:33:07 nirik: yeah, that wasn't my original proposal but at this point I'm good with it. 17:33:08 from the schedule it looks like 5 17:33:14 I think it was f9 due to 'incidents' 17:33:25 nope, 9 hit may on the nose. 17:33:29 or 10? 17:33:31 anyhow... 17:33:32 i think you guys are older than you realize ;) 17:33:35 nirik: wasn't the point of the proposal simply "do not let slips of fn move the relase date of fn+1 back" ? 17:33:43 nope, all those releases hit may/november or barely missed 17:33:54 for what it's worth, I think it would make sense to set some tentative schedule for F22 so the the development teams can have some ideas how it's going to look 17:34:02 drago01: thats what the policy is today 17:34:20 kalev: I usually propose fn+1 shchedule at beta time 17:34:22 FESCo chose to make an exception for F19, F20 and F21 17:34:26 So it does sound to me like we're *roughly* agreed that two releases per year is a reasonable approach, yes? 17:34:31 drago01: well, not exactly... since we haven't scheduled it yet 17:34:42 sgallagh: sure. 17:34:45 sgallagh: yes 17:34:48 dgilmore: ok 17:34:58 so the only things I think we need to decide is no more exceptions 17:35:02 jreznik: and we could look at trying to get back to may? 17:35:09 kalev: at beta release I already have some overview where final lands as it's not GA Fn-1 + 6 months, but there's always some overlap 17:35:15 sgallagh: yes 17:35:18 dgilmore: which we never can decide :) 17:35:19 the 9 month cycle was FC5, fwiw. http://lwn.net/Articles/168225/ 17:35:22 Proposal: For immediate future, schedule each release as needed with the normal targets of May/October as defaults but adjusted as fits that release. 17:35:24 yes, you guys are all older than you thought. ;) 17:35:33 nirik: I always try to be as close to may as possible 17:35:37 mitr: we can decide to do better 17:35:37 mattdm: +1 17:35:43 * nirik awards adamw the 'historian' badge. If it existed. 17:35:46 mitr: and we can decide to go back to policy 17:35:48 at least for now 17:35:51 adamw, damn. i do feel old. 17:35:54 we hit 6 months really pretty solidly all the way from 6 through to 18, i think maybe we think we're worse at this than we are 17:36:02 mattdm: *shrug* yes. 17:36:06 (and FC4 was still the worst fedora release ever, no offense anyone, and that long cycle was _painful_.) 17:36:06 mattdm: +1 17:36:09 (lol pup) 17:36:12 mattdm: so that's what we have now (even in the end it lands june/november) 17:36:13 heh 17:36:15 So what about adapting mattdm's original proposal to be something like "We target six-month cycles. If a slippage occurs, it borrows time into the next cycle up to N weeks, after which we automatically skip that release" 17:36:35 skip release? 17:36:47 The one we were borrowing time into 17:36:53 sgallagh: not sure we need to set that as some kind of policy? or you think thats better than just us deciding? 17:36:59 i don't see what that buys us at all 17:37:08 other than endless rawhide and stagnant releases 17:37:18 sgallagh: what would that N weeks be? 17:37:19 (or worse, massively updated releases) 17:37:19 It buys us a clear consequence of slipping too much, as well as a plan for staying on the defined cycle. 17:37:20 yep, please, don't do it 17:37:26 sgallagh: I've become convinced that we're not ready for that :) 17:37:28 dgilmore: I was thinking 6 17:37:33 sgallagh: I’d rather not spend an hour discussing this today, only to be overridden in 10 minutes next year for $unforeseeable_reasons 17:37:36 mattdm: no, we are not 17:37:41 sgallagh, "we hit dates or we don't ship" seems rather dumb 17:37:55 jwb: That's not what I said. 17:38:16 Let me rephrase, it may have been unclear. 17:38:18 sgallagh, but it's the practical outcome. software is hard, slips will happen. 17:38:31 saying we're going to skip a release doesn't buy you anything 17:38:31 i believe by 'borrowing time' he means slips in F-N cause the F-N+1 cycle to be shortened 17:38:33 We assert the goal is for six week cycles. 17:38:34 jwb, I think you misunderstood 17:38:44 sgallagh: 6 month 17:38:45 and if the F-N+1 cycle then becomes too short due to the 'borrowing', it gets cancelled instead. 17:38:48 So let's say that because of slips, F22 has now taken eight months. 17:38:51 Right, months. Sorry 17:38:59 adamw, yeah, i got that part. i'm fine with that. it's the "don't do a release" part i object to 17:39:21 I'm suggesting that F23 then automatically becomes a 10-month cycle instead of a 4-month one. 17:39:32 Because 4 months is basically impossible. 17:39:35 well, i guess if we'd in theory wind up with a 3-month F-N+1 it's possibly reasonable to say 'skip that and use the next point instead, i.e. 9 months' 17:39:38 which lands you into the same situation we have TODAY 17:39:41 sgallagh: I get that, not sure its great though 17:39:46 which means there's no point in having this conversation 17:39:46 sgallagh: why? it just means less changes 17:39:53 jwb: +1 17:40:15 drago01, that works if people haven't been landing changes in rawhide that they think will take 6months 17:40:21 i kinda see the merit in it, as it allows us to handle significant slippage while sticking with our release *months* and sync with GNOME 17:40:33 jwb: No, the question we have today is whether to just offset the next cycle so it's six months after whenever-the-heck-we-ship this one 17:40:33 adamw: yes, exactly, that's the reasoning 17:40:36 but i can go either way 17:40:38 I'd rather like if we could try to figure out a plan how to avoid slips, instead of planning what to do if we slip for 6 weeks 17:40:42 jwb: oh true 17:40:50 kalev: hey, it's always worth having a plan for the unfortunate 17:40:56 kalev: I don't think those things are mutually exclusive 17:40:56 adamw: We end up with circular reasoning at that time because one of the major drivers for even _having_ releases that frequently is GNOME :) 17:41:38 sgallagh: The implicit target of May/Oct is already steering us away from just doing another 6-month release, isn’t it? 17:41:42 sure, it's all a bit slippery. 17:41:51 sgallagh, but it doesn't help you on the development side. your proposal has no net gain there 17:42:00 mitr: hey, Beta TC1 doesn't look bad. shipit! 17:42:24 I think that by gating Rawhide, and doing more automated QA earlier it will help us slip less 17:42:24 adamw: No, I mean in the post-GA scheduling discussion about the next cycle. 17:42:30 okay, so, 40 minutes on this one. 17:42:46 more 40 ahead of us! 17:42:52 re: slips perhaps we could have a seperate retrospective thing and try and see if there's things we can do to solve the issues that cause slips moving forward. 17:42:59 dgilmore: it could 17:43:15 Sure, but history has shown that slips will happen and we can't always predict why. 17:43:26 I also think we will not solve anything here today 17:43:32 nirik: we do some kind of looking bad when working on the next schedule 17:43:38 one thing that could helps with slips is if we had buffer time in between milestones 17:43:56 kalev: we do? you mean more? 17:43:58 kalev: like a year? :) 17:43:58 as in, instead of pushing out the whole schedule, we'd go from 4 weeks of development time between milestones, to 3 weeks of development time 17:43:59 So if we agree (and it sounded like we did) that having June/Oct or May/Oct releases is the best approach, then I was proposing how we can address that so we don't diverge there again 17:44:31 * adamw would like to get five minutes for the next agenda item just so we can finish the wiki cleanup without having to make any executive discussions... 17:44:37 er, decisions. 17:44:37 Main question is whether to make that a formula or to reconsider every time 17:44:46 sgallagh: sure. not saying they wouldn't still happen. we could have avoided some of teh slippage if id been doing full composes of rawhide sooner. I think we have a bunch of room for improvement. just need time 17:45:04 dgilmore: Yes, absolutely we should prevent repeating our mistakes :) 17:45:07 sgallagh: It seems to me that your proposed approach is an inevitable consequence of the earlier consensus, except that nailing down the details would take a lot of time today. 17:45:19 nightly full composes would help a lot... and screams when they fail. 17:45:58 45 minutes in.... proposal: take converation to ticket. come back next week with concrete proposals. vote -1 to continue talking about this now. 17:46:05 mattdm: ack 17:46:11 +1 :) 17:46:12 +1 17:46:15 +1 :) 17:46:17 mattdm: +1 17:46:21 +1 17:46:24 mattdm: +1 17:46:25 mattdm: +1 17:46:36 #info taking conversation to ticket; coming back next week with some concrete proposals 17:46:45 okay :) 17:46:50 #topic Consider renaming "Change(s) freeze" and "Beta deadline/accepted changes 100% complete" points 17:46:52 .fesco 1351 17:46:53 mattdm: #1351 (Consider renaming "Change(s) freeze" and "Beta deadline/accepted changes 100% complete" points) – FESCo - https://fedorahosted.org/fesco/ticket/1351 17:46:53 https://fedorahosted.org/fesco/ticket/1351 17:46:55 adamw: ! 17:47:02 yaay 17:47:19 did everyone understand this from the ticket? 17:47:53 * jreznik is trying to understand it :) 17:47:55 +1 17:47:55 I think so 17:47:57 sure, +1 17:47:58 adamw: +1 please do it 17:48:05 adamw: +1 17:48:12 i have no opinion (because i somehow missed this ticket entirely) 17:48:36 I'm +1 to the suggestion 17:49:05 I'm also in favor of all of adam's insomnia/obsession/whatever cleanups to the wiki 17:49:05 ok +1 17:49:14 alpha could be checkpoint, at beta time, it really should be freeze (and we're back to that 45 minutes long discussion again) 17:49:30 jreznik: this relates specifically to the Changes policy 17:49:33 jreznik: curse you! 17:49:53 jreznik: i still don't think freeze is the right word for the Beta Changes 'checkpoint' because nothing freezes *as part of the Changes policy* 17:49:53 there isn't a Changes tree or repository or anything. 17:50:22 * mattdm afk for three minutes. +1 to everything while I'm gone! 17:50:24 that date happens on the same day as the Beta freeze itself at present, i just think it's clearer to keep the understanding that they're technically speaking two independent events 17:50:29 jreznik: Not a freeze; contingency decision point, or perhaps contingency deadline. 17:50:38 the point at which Changes are expected to be 100% 'code complete' could be a different day, if FESCo so decided. 17:50:42 mitr: I like it 17:51:21 adamw: it makes sense to be tied to release freezes 17:51:44 * jreznik could go with alpha time being checkpoint and beta contingency deadline 17:51:51 jreznik: for the beta point, yup, and in fact we have an explanation of why in the 'milestone freezes' page now 17:52:14 jreznik: so the other thing to clean up is that the Alpha Change checkpoint isn't actually supposed to be on the same day as Alpha Freeze 17:52:26 i got that part wrong, because of a mistaken edit to the Changes/Policy page by stickster 17:52:27 my battery is crying... I have ten more seconds.... 17:52:37 will read it later when back to docking station 17:52:49 but we're pretty clear on what happened there now, so i'm just gonna re-adjust that back to what the actual intent was 17:52:59 adamw: +1 17:53:26 so, is the proposal now "change checkpoint" and "change deadline"? 17:53:34 please not change deadline. 17:53:36 anything but that. 17:53:52 (since that's what we called the milestone freezes until, like, tuesday.) 17:54:19 change contingency point? dunno, don't much care. ;) 17:54:22 adamw: is "change contingency deadline" better, or is "deadline" the problem? 17:54:40 that's better as it's at least not an identical term 17:55:06 i'm not sure we need to try and express the totality of its intent in its name.. 17:55:10 I also like it because it implies some seriousness about the contingencies 17:55:21 i mean, i liked 'checkpoint' because it's kind of simple and memorable and not confused with anything else 17:55:42 the *definition* of the point can explain what's actually required (and the schedule can still have the "must be 100% code complete" note) 17:55:53 right I am still in favor of calling 'em all "checkpoint" but I don't want to get stuck on it. 17:56:07 welp, just pick a name and i can finish up the page edits 17:56:09 Or perhaps instead of threatening with consequences, focus on the scuccess and call it “change acceptance checkpoint/date/deadline”? 17:56:11 just please not 'change deadline' :) 17:56:20 uh plus also we technically have +5 votes for "checkpoint" :) 17:56:39 adamw: pick one name you like most, and have us vote on that :) 17:56:51 adamw: you'll see how quickly +1's come 17:56:58 adamw: +1 17:57:00 (see?) 17:57:14 how about "Change completion deadline"? 17:57:17 +1 17:57:29 +whateverittakestomoveon 17:57:33 +1 17:57:38 jwb: haha, nice vote. 17:57:49 i guess i'll go and do something that looks good and then update the ticket to let you know what it was. 17:57:59 +1 yeah. 17:58:03 thanks for all the wiki work adamw. appreciated! 17:58:03 adamw, sounds amazingly super great awesome 17:58:04 +1 17:58:19 +1 17:58:22 adamw: +1 17:58:24 and thanks for working on this, adamw! 17:58:26 thanks folks 17:58:27 #agreed adam to update ticket with something that looks good and we're all basically happy with that 17:58:31 adamw, for the record, i'm just happen when anyone takes any interest in actually making the wiki better. so sincere thanks 17:58:40 #info lots of plusses so much counting 17:58:40 uh, s/happen/happy 17:59:03 #info sincere thanks to adam from fesco for making the wiki better 17:59:28 #topic Next week's chair 18:00:01 i'll do it 18:00:08 #info jwb to chair next week 18:00:11 #topic Open Floor 18:00:21 * mattdm notes 1 hour time 18:00:35 any open floor items? going in 1 minute 18:01:15 just to note there's an outage later today. ;) 18:01:24 nirik: 4 hour outage? 18:01:25 in 3hours... koji will be down for a while. ;) 18:01:40 nirik: sounds fun :) 18:01:44 hopefully less. 18:01:50 #endmeeting