17:00:18 <mattdm> #startmeeting FESCO (2014-10-01)
17:00:18 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:19 <mattdm> #meetingname fesco
17:00:19 <zodbot> The meeting name has been set to 'fesco'
17:00:21 <mattdm> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza
17:00:21 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza
17:00:23 <mattdm> #topic init process
17:00:27 <mitr> Hello
17:00:37 <nirik> morning
17:00:37 <mattdm> good $TIMEOFDAY, everyone
17:00:40 <thozza> hello everybody
17:01:01 <jwb> hi
17:01:34 * mattdm waits a couple of minutes
17:02:44 <t8m> hhhffhi
17:03:02 <mattdm> okay good enough :)
17:03:09 <mattdm> #topic Fedora 22 scheduling strategy (and beyond)
17:03:10 <mattdm> .fesco 1349
17:03:12 <zodbot> mattdm: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349
17:03:12 <mattdm> https://fedorahosted.org/fesco/ticket/1349
17:03:26 <t8m> heh somebody is hijacking my keyboard :) my 3 year old son actually
17:03:33 <mattdm> 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 <mattdm> That is, the documented process and actual process have drifted
17:04:04 <nirik> 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 <t8m> Do we have an opinion after these various approaches taken which one was the best?
17:05:09 <jreznik> mattdm: I'll do a few more updates to the Fedora Release Life Cycle but adamw did a great job
17:05:28 <mattdm> I think jwb is right in that being strict with the schedule has specific assumptions / consequences
17:05:29 <t8m> We could probably ignore the F18 and F21 cases though as exceptions.
17:05:30 <adamw> jreznik: we do still need to sort the Change/Feature Freeze issue
17:05:55 <mattdm> adamw: yeah I think that's the next agenda item?
17:05:55 <sgallagh> I'm here. Sorry for being late
17:06:04 <thozza> yes, it is
17:06:24 <mattdm> adamw: well, the nominal topic is "consider renaming..."  but there's all the other stuff too.
17:06:29 <jreznik> adamw: I'm not completely sure I understood that issue
17:06:34 <nirik> so I think it's good for people for us to have 'normal' targets we try and meet...
17:06:48 <nirik> but each release might be different and of course 18/21 were/are
17:06:50 <dgilmore> hey all
17:06:58 <mattdm> hi dgilmore
17:07:03 <adamw> jreznik: we'll cover it under the next agenda item :)
17:07:24 <jreznik> nirik: on the other hand, we had 19, 20 that worked pretty well
17:07:58 <adamw> 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 <mattdm> 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 <mitr> I’m not quite sure that the difference matters, considering the next FESCo can always change their mind.
17:08:43 <mattdm> (and with 7 months, I mean we'd keep scheduling 6 months but be honest that the week of slip matters)
17:08:47 <nirik> right, or even this fesco deciding f22.
17:09:51 <jreznik> adamw: I'm going to write "no earlier than" to that page
17:10:12 <nirik> 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 <dgilmore> 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 <mattdm> nirik: that's a very practical way, yes :)
17:10:54 <jwb> theoretically it means Changes without feasible rollback plans are never accepted
17:11:05 <jwb> or if they are accepted, it's a one-off release
17:11:17 <sgallagh> 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 <jwb> which makes things like e.g. major gcc upgrades harder
17:11:29 <t8m> The schedule could be kept much better if we actually developed on rawhide and do only minimal changes after branching.
17:11:30 <dgilmore> jwb: we allow for them to be developed on the side and rolled in when ready
17:11:36 <mattdm> or if they are accepted and they are catastrophic, we eat the catastrophe. (sorry, X in this release doesn't work!)
17:11:40 <mitr> 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 <mattdm> (er, where "X" hopefully isn't _actually_ X)
17:11:55 <jwb> dgilmore, sure, that's doable if we think we can sustain 2x development and support costs
17:12:01 <jwb> i'm still skeptical we can
17:12:10 <t8m> and the development of the next release started immediately after branching the current one
17:12:19 <jwb> t8m, yes.
17:12:22 <nirik> t8m: right
17:12:34 <dgilmore> jwb: shorter term we can't longer term I am sure we can
17:12:34 <kalev> well, an option would be to avoid branching that early, to avoid the 2 parallel development branches
17:13:06 <mattdm> 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 <kalev> as in, branch after Beta, or something, and impose all the freezes from alpha till beta to the rawhide / master branch
17:13:14 <mattdm> and I think adamw threatened to resign :)
17:13:16 <nirik> 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 <dgilmore> kalev: thats not an option. We would have to go back to freezing rawhide and roll back no frozen rawhide
17:13:49 <mitr> 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 <sgallagh> One thing that could reduce ongoing maintenance burden would be to stop allowing an updates stream for anything but security bugs.
17:14:00 <sgallagh> So all new functionality goes into F N+1
17:14:03 <kalev> dgilmore: right, that's exactly what I'm suggesting
17:14:15 <mattdm> mitr: I think it helps people plan for their longer-term features better.
17:14:28 <dgilmore> kalev: I do not think that really gains us much
17:14:34 <drago01> sgallagh: non security bugs are also bugs that are worth fixing
17:14:36 <nirik> mitr: upstream projects (gnome, etc) could know approx when to do things... also we avoid (mostly) big chunks of holidays
17:14:36 <kalev> 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 <dgilmore> cutting the stable release churn  will
17:14:49 <mattdm> 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 <sgallagh> drago01: It was a hypothetical.
17:14:54 <dgilmore> making the cost of spinning releases would help
17:14:57 <mitr> 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 <dgilmore> as in the human time in doing it, and having faster turn around
17:15:10 <nirik> kalev: that sounds like turning rawhide into branched. ;) which would requre a ton of effort
17:15:18 <jreznik> 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 <mattdm> mitr plus I think the impact on events like flock is really large
17:15:29 <kalev> nirik: yep, it would require considerable tooling effort, no disagreement there
17:15:33 <mattdm> Robyn _wanted_ flock to happen right after a release
17:15:34 <dgilmore> mattdm: its never been something like six months after this one
17:15:52 <mattdm> dgilmore: assuming six is something like seven :)
17:15:56 <dgilmore> mattdm: its always been may/october  f18 threw things for a loop
17:16:08 <mitr> 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 <mattdm> dgilmore: well, but see jreznik's comment.
17:16:25 <jreznik> mattdm: events will always depend on free and free space
17:16:50 <jreznik> unless someone comes with a huge pack of money to schedule flock out of holidays season
17:16:52 <mattdm> mitr: we can plan for some amount of slip and still keep basically away from conference times
17:16:54 <mitr> 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 <dgilmore> mattdm: some people are currently ignoring rawhide and will do so until f21 is out
17:17:10 <jwb> 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 <dgilmore> mattdm: but right now is the best time to get the most disruptive changes into rawhide
17:17:22 <dgilmore> jwb: yeah
17:17:24 <mattdm> dgilmore: yeah, so that's where the idea of freezing the branch immediately has appeal.
17:17:28 <jwb> dgilmore, which is hard to do when everyone is busy fixing stuff in branched.
17:17:30 <mattdm> downside, qa team all quits :)
17:17:30 <nirik> jwb: true.
17:17:57 <dgilmore> jwb: this is true also.
17:17:59 <jreznik> I'm not sure we have many really distruptive changes in the undergoing release
17:18:02 <nirik> well, IMHO it's not hard to fix in rawhide and branched in general. New versions are trivial
17:18:13 <dgilmore> jwb: not everyone ignores rawhide now but a lot do
17:18:14 <jreznik> and if we have, we should be able to say "please no" aka nm-09
17:18:16 <adamw> fwiw i'm kinda on the 'not really seeing a problem to fix' side
17:18:21 <nirik> people who are not doing it just need to adjust their workflow.
17:18:32 <mitr> 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 <nirik> adamw: on schedule?
17:19:07 <drago01> I don't think restrictions magically make people work on something else
17:19:48 <mitr> drago01: The prohibition on UI changes post-.0 seems to work remarkably well for GNOME
17:20:11 <jwb> i don't think flood of updates magically make the branched/released distro better
17:20:16 <mitr> drago01: Same here: it is a matter of timing / delivery mechanism for the work, not resigning people to different activities.
17:20:22 <drago01> jwb: I don't disagree
17:20:30 <jwb> there's a balance.  it has not been achieved.  how do we achieve it.
17:20:32 <mitr> s/resigning/reassigning/
17:20:42 <dgilmore> adamw: Schedule wise I agree
17:20:59 <mattdm> 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 <drago01> 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 <jwb> nirik, i don't think it's in bad shape.  i think it's pure luck that it isn't though
17:21:29 <sgallagh> 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 <mattdm> nirik: would you be comfortable freezing it at any arbitrary point and giving it a month to stabilize before release?
17:21:47 <nirik> jwb: well, luck and some poking by various people when it goes off the rails.
17:21:49 <adamw> 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 <jwb> nirik, perhaps luck plus some help from a dedicated few
17:21:59 <jwb> nirik, heh, jinx
17:22:13 <nirik> mattdm: no. Why? I think it's valuable for it to not freeze
17:22:32 <adamw> 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 <mattdm> nirik sorry, _branching_ from any arbitrary point and shipping that.
17:22:51 <jreznik> adamw: yep, that's something I'm trying to say
17:22:59 <nirik> 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 <jreznik> it's again a good compromise between frozen and completely open development
17:23:38 <kalev> 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 <nirik> 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 <nirik> I think we could improve rawhide stablity with some gating, which we are working on. ;)
17:24:18 <adamw> kalev: well, wasn't that sort of the *point*?
17:24:18 <kalev> 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 <sgallagh> 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 <adamw> 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 <adamw> 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 <adamw> if it *didn't*, that would make no-frozen-rawhide pointless
17:25:11 <sgallagh> nirik: I was kind of trying to do that with my question there.
17:25:19 <kalev> yeah, let's maybe focus on the scheduling for now and leave rawhide for another time
17:25:48 <nirik> FWIW, we are close to having rawhide signed, and then we can add some gating tests to composes... but anyhow.
17:25:58 <mattdm> 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 <kalev> 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 <dgilmore> I do have plans to work on making rawhide not break
17:26:41 <mattdm> 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 <mattdm> so, six months seems good.
17:26:50 <mitr> 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 <nirik> 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 <sgallagh> kalev: Well, different projects have different schedules
17:27:17 <sgallagh> Two of our most important happen on multiples of 3 months, so that's probably a good baseline. (Kernel and GNOME)
17:27:19 <nirik> mitr: jinx. ;)
17:27:23 <jwb> mattdm, s/people/developers
17:27:38 <mattdm> jwb no, users
17:27:55 <jwb> there is no way i would agree a "lot" of users dislike a yearly release
17:28:01 <drago01> also longer cycles means supporting older code for longer time
17:28:15 * sgallagh nods
17:28:16 <drago01> i.e like the f19 "zombie"
17:28:26 <mattdm> jwb: nope but they get frustrated that the stuff they care about isn't updated
17:28:27 <nirik> 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 <dgilmore> mattdm: 6-9 month cycles i think
17:28:34 <jwb> 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 <kalev> 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 <dgilmore> mattdm: 12 months Is too long between
17:28:53 <Southern_Gentlem> ???
17:29:05 <dgilmore> kalev: why?
17:29:15 <mattdm> jwb same old thing. cake and eating it.
17:29:16 <Southern_Gentlem> server once a year and workstation every 6 months
17:29:17 <mitr> kalev: That’s again verging into implementation vs. _what do we want to do_
17:29:22 <jreznik> dgilmore: same here, 6-9
17:29:37 <jwb> mattdm, yes, but it's disingenuous to say the 6mo release is for users.
17:29:41 <sgallagh> Southern_Gentlem: That's worth considering, certainly, but let's worry about the Fedora Project as a whole first
17:29:58 <drago01> do we have numbers on how long our cycles actually are?
17:29:58 <Southern_Gentlem> sgallagh,  i am
17:30:03 <dgilmore> 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 <jwb> 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 <mitr> I’m leaning towards 9 being too long FWIW.
17:30:08 <nirik> I have long thought 9month cycle would be great, but the problem is that it hits holidays after a while...
17:30:08 <drago01> there aren't 6 months anyway due to slips
17:30:18 <kalev> dgilmore: I think Server had plans to do this, that's why I brought that up
17:30:18 <mattdm> jwb: agree.
17:30:19 <jreznik> 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 <MarkDude> 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 <mattdm> although someone on users list was complaining about mesa, so hardware enablement factors in too
17:30:44 <jreznik> so we should take a look how to make upgrades easier (we really sucks there) than prolonging support
17:30:45 <adamw> drago01: distrowatch tracks release dates
17:30:55 <jwb> jreznik, eh, i understand your point but i don't believe it's a fair comparison to make.
17:30:56 <mitr> jreznik: We don‘t have that security problem, I’m not sure there is any lesson to be learnt
17:31:00 <mattdm> anyway back to the top issue since we're half an hour in....
17:31:01 <adamw> drago01: http://distrowatch.com/table.php?distribution=fedora
17:31:05 <sgallagh> 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 <sgallagh> And off-topic for the moment :)
17:31:29 <drago01> 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 <drago01> *later
17:31:41 <mattdm> 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 <jreznik> so really, fedup should be the first thing to take a look... I can't imagine telling users to use fedup...
17:31:43 <drago01> adamw: thanks
17:31:44 <adamw> drago01: we hit November every year from 2007 to 2011
17:31:55 <adamw> F18 should have been a November release; it broke hte streak
17:32:29 <drago01> we did an intentional 9 months cycle in earlier
17:32:35 <drago01> can't recall which relase that wa
17:32:36 <drago01> s
17:32:42 <jwb> F8 or F9
17:32:47 <nirik> mattdm: so, whats our proposal or action here? just update the wiki with 'as needed' and move on? or ?
17:32:57 <drago01> ok
17:33:07 <mattdm> nirik: yeah, that wasn't my original proposal but at this point I'm good with it.
17:33:08 <adamw> from the schedule it looks like 5
17:33:14 <nirik> I think it was f9 due to 'incidents'
17:33:25 <adamw> nope, 9 hit may on the nose.
17:33:29 <nirik> or 10?
17:33:31 <nirik> anyhow...
17:33:32 <adamw> i think you guys are older than you realize ;)
17:33:35 <drago01> 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 <adamw> nope, all those releases hit may/november or barely missed
17:33:54 <kalev> 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 <dgilmore> drago01: thats what the policy is today
17:34:20 <jreznik> kalev: I usually propose fn+1 shchedule at beta time
17:34:22 <dgilmore> FESCo chose to make an exception for F19, F20 and F21
17:34:26 <sgallagh> So it does sound to me like we're *roughly* agreed that two releases per year is a reasonable approach, yes?
17:34:31 <nirik> drago01: well, not exactly... since we haven't scheduled it yet
17:34:42 <nirik> sgallagh: sure.
17:34:45 <kalev> sgallagh: yes
17:34:48 <drago01> dgilmore: ok
17:34:58 <dgilmore> so the only things I think we need to decide is no more exceptions
17:35:02 <nirik> jreznik: and we could look at trying to get back to may?
17:35:09 <jreznik> 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 <mitr> sgallagh: yes
17:35:18 <mitr> dgilmore: which we never can decide :)
17:35:19 <adamw> the 9 month cycle was FC5, fwiw. http://lwn.net/Articles/168225/
17:35:22 <mattdm> 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 <adamw> yes, you guys are all older than you thought. ;)
17:35:33 <jreznik> nirik: I always try to be as close to may as possible
17:35:37 <dgilmore> mitr: we can decide to do better
17:35:37 <kalev> mattdm: +1
17:35:43 * nirik awards adamw the 'historian' badge. If it existed.
17:35:46 <dgilmore> mitr: and we can decide to go back to policy
17:35:48 <dgilmore> at least for now
17:35:51 <jwb> adamw, damn.  i do feel old.
17:35:54 <adamw> 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 <mitr> mattdm: *shrug* yes.
17:36:06 <mattdm> (and FC4 was still the worst fedora release ever, no offense anyone, and that long cycle was _painful_.)
17:36:06 <nirik> mattdm: +1
17:36:09 <jwb> (lol pup)
17:36:12 <jreznik> mattdm: so that's what we have now (even in the end it lands june/november)
17:36:13 <drago01> heh
17:36:15 <sgallagh> 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 <jreznik> skip release?
17:36:47 <sgallagh> The one we were borrowing time into
17:36:53 <nirik> 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 <jwb> i don't see what that buys us at all
17:37:08 <jwb> other than endless rawhide and stagnant releases
17:37:18 <dgilmore> sgallagh: what would that N weeks be?
17:37:19 <jwb> (or worse, massively updated releases)
17:37:19 <sgallagh> It buys us a clear consequence of slipping too much, as well as a plan for staying on the defined cycle.
17:37:20 <jreznik> yep, please, don't do it
17:37:26 <mattdm> sgallagh: I've become convinced that we're not ready for that :)
17:37:28 <sgallagh> dgilmore: I was thinking 6
17:37:33 <mitr> 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 <jreznik> mattdm: no, we are not
17:37:41 <jwb> sgallagh, "we hit dates or we don't ship" seems rather dumb
17:37:55 <sgallagh> jwb: That's not what I said.
17:38:16 <sgallagh> Let me rephrase, it may have been unclear.
17:38:18 <jwb> sgallagh, but it's the practical outcome.  software is hard, slips will happen.
17:38:31 <jwb> saying we're going to skip a release doesn't buy you anything
17:38:31 <adamw> i believe by 'borrowing time' he means slips in F-N cause the F-N+1 cycle to be shortened
17:38:33 <sgallagh> We assert the goal is for six week cycles.
17:38:34 <t8m> jwb, I think you misunderstood
17:38:44 <kalev> sgallagh: 6 month
17:38:45 <adamw> and if the F-N+1 cycle then becomes too short due to the 'borrowing', it gets cancelled instead.
17:38:48 <sgallagh> So let's say that because of slips, F22 has now taken eight months.
17:38:51 <sgallagh> Right, months. Sorry
17:38:59 <jwb> 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 <sgallagh> I'm suggesting that F23 then automatically becomes a 10-month cycle instead of a 4-month one.
17:39:32 <sgallagh> Because 4 months is basically impossible.
17:39:35 <adamw> 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 <jwb> which lands you into the same situation we have TODAY
17:39:41 <dgilmore> sgallagh: I get that, not sure its great though
17:39:46 <jwb> which means there's no point in having this conversation
17:39:46 <drago01> sgallagh: why? it just means less changes
17:39:53 <jreznik> jwb: +1
17:40:15 <jwb> drago01, that works if people haven't been landing changes in rawhide that they think will take 6months
17:40:21 <adamw> 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 <sgallagh> 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 <mattdm> adamw: yes, exactly, that's the reasoning
17:40:36 <adamw> but i can go either way
17:40:38 <kalev> 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 <drago01> jwb: oh true
17:40:50 <adamw> kalev: hey, it's always worth having a plan for the unfortunate
17:40:56 <sgallagh> kalev: I don't think those things are mutually exclusive
17:40:56 <mitr> 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 <mitr> 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 <adamw> sure, it's all a bit slippery.
17:41:51 <jwb> sgallagh, but it doesn't help you on the development side.  your proposal has no net gain there
17:42:00 <adamw> mitr: hey, Beta TC1 doesn't look bad. shipit!
17:42:24 <dgilmore> I think that by gating Rawhide, and doing more automated QA earlier it will help us slip less
17:42:24 <mitr> adamw: No, I mean in the post-GA scheduling discussion about the next cycle.
17:42:30 <mattdm> okay, so, 40 minutes on this one.
17:42:46 <jreznik> more 40 ahead of us!
17:42:52 <nirik> 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 <nirik> dgilmore: it could
17:43:15 <sgallagh> Sure, but history has shown that slips will happen and we can't always predict why.
17:43:26 <dgilmore> I also think we will not solve anything here today
17:43:32 <jreznik> nirik: we do some kind of looking bad when working on the next schedule
17:43:38 <kalev> one thing that could helps with slips is if we had buffer time in between milestones
17:43:56 <nirik> kalev: we do? you mean more?
17:43:58 <jreznik> kalev: like a year? :)
17:43:58 <kalev> 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 <sgallagh> 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 <adamw> er, decisions.
17:44:37 <mattdm> Main question is whether to make that a formula or to reconsider every time
17:44:46 <dgilmore> 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 <sgallagh> dgilmore: Yes, absolutely we should prevent repeating our mistakes :)
17:45:07 <mitr> 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 <nirik> nightly full composes would help a lot... and screams when they fail.
17:45:58 <mattdm> 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 <dgilmore> mattdm: ack
17:46:11 <mattdm> +1 :)
17:46:12 <nirik> +1
17:46:15 <kalev> +1 :)
17:46:17 <thozza> mattdm: +1
17:46:21 <t8m> +1
17:46:24 <sgallagh> mattdm: +1
17:46:25 <mitr> mattdm: +1
17:46:36 <mattdm> #info taking conversation to ticket; coming back next week with some concrete proposals
17:46:45 <mattdm> okay :)
17:46:50 <mattdm> #topic Consider renaming "Change(s) freeze" and "Beta deadline/accepted changes 100% complete" points
17:46:52 <mattdm> .fesco 1351
17:46:53 <zodbot> 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 <mattdm> https://fedorahosted.org/fesco/ticket/1351
17:46:55 <mattdm> adamw: !
17:47:02 <adamw> yaay
17:47:19 <adamw> did everyone understand this from the ticket?
17:47:53 * jreznik is trying to understand it :)
17:47:55 <dgilmore> +1
17:47:55 <thozza> I think so
17:47:57 <nirik> sure, +1
17:47:58 <mitr> adamw: +1 please do it
17:48:05 <thozza> adamw: +1
17:48:12 <jwb> i have no opinion (because i somehow missed this ticket entirely)
17:48:36 <mattdm> I'm +1 to the suggestion
17:49:05 <mattdm> I'm also in favor of all of adam's insomnia/obsession/whatever cleanups to the wiki
17:49:05 <t8m> ok +1
17:49:14 <jreznik> 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 <adamw> jreznik: this relates specifically to the Changes policy
17:49:33 <mattdm> jreznik: curse you!
17:49:53 <adamw> 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 <adamw> 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 <adamw> 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 <mitr> jreznik: Not a freeze; contingency decision point, or perhaps contingency deadline.
17:50:38 <adamw> the point at which Changes are expected to be 100% 'code complete' could be a different day, if FESCo so decided.
17:50:42 <jreznik> mitr: I like it
17:51:21 <jreznik> 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 <adamw> jreznik: for the beta point, yup, and in fact we have an explanation of why in the 'milestone freezes' page now
17:52:14 <adamw> 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 <adamw> i got that part wrong, because of a mistaken edit to the Changes/Policy page by stickster
17:52:27 <jreznik> my battery is crying... I have ten more seconds....
17:52:37 <jreznik> will read it later when back to docking station
17:52:49 <adamw> 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 <mattdm> adamw: +1
17:53:26 <mattdm> so, is the proposal now "change checkpoint" and "change deadline"?
17:53:34 <adamw> please not change deadline.
17:53:36 <adamw> anything but that.
17:53:52 <adamw> (since that's what we called the milestone freezes until, like, tuesday.)
17:54:19 <nirik> change contingency point? dunno, don't much care. ;)
17:54:22 <mattdm> adamw: is "change contingency deadline" better, or is "deadline" the problem?
17:54:40 <adamw> that's better as it's at least not an identical term
17:55:06 <adamw> i'm not sure we need to try and express the totality of its intent in its name..
17:55:10 <mattdm> I also like it because it implies some seriousness about the contingencies
17:55:21 <adamw> i mean, i liked 'checkpoint' because it's kind of simple and memorable and not confused with anything else
17:55:42 <adamw> 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 <mattdm> right I am still in favor of calling 'em all "checkpoint" but I don't want to get stuck on it.
17:56:07 <adamw> welp, just pick a name and i can finish up the page edits
17:56:09 <mitr> Or perhaps instead of threatening with consequences, focus on the scuccess and call it “change acceptance checkpoint/date/deadline”?
17:56:11 <adamw> just please not 'change deadline' :)
17:56:20 <mattdm> uh plus also we technically have +5 votes for "checkpoint" :)
17:56:39 <kalev> adamw: pick one name you like most, and have us vote on that :)
17:56:51 <kalev> adamw: you'll see how quickly +1's come
17:56:58 <mattdm> adamw: +1
17:57:00 <mattdm> (see?)
17:57:14 <adamw> how about "Change completion deadline"?
17:57:17 <kalev> +1
17:57:29 <jwb> +whateverittakestomoveon
17:57:33 <mattdm> +1
17:57:38 <adamw> jwb: haha, nice vote.
17:57:49 <adamw> 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 <mattdm> +1 yeah.
17:58:03 <nirik> thanks for all the wiki work adamw. appreciated!
17:58:03 <jwb> adamw, sounds amazingly super great awesome
17:58:04 <thozza> +1
17:58:19 <t8m> +1
17:58:22 <mitr> adamw: +1
17:58:24 <kalev> and thanks for working on this, adamw!
17:58:26 <adamw> thanks folks
17:58:27 <mattdm> #agreed adam to update ticket with something that looks good and we're all basically happy with that
17:58:31 <jwb> 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 <mattdm> #info lots of plusses so much counting
17:58:40 <jwb> uh, s/happen/happy
17:59:03 <mattdm> #info sincere thanks to adam from fesco for making the wiki better
17:59:28 <mattdm> #topic Next week's chair
18:00:01 <jwb> i'll do it
18:00:08 <mattdm> #info jwb to chair next week
18:00:11 <mattdm> #topic Open Floor
18:00:21 * mattdm notes 1 hour time
18:00:35 <mattdm> any open floor items? going in 1 minute
18:01:15 <nirik> just to note there's an outage later today. ;)
18:01:24 <mattdm> nirik: 4 hour outage?
18:01:25 <nirik> in 3hours... koji will be down for a while. ;)
18:01:40 <mattdm> nirik: sounds fun :)
18:01:44 <nirik> hopefully less.
18:01:50 <mattdm> #endmeeting