Hi, FESCo. Just wanted to request some quick consideration of something that came up from my wiki re-work.
There are two sort of 'checkpoint' dates in the Changes policy which have been carried over from the old Features policy. One is the "Changes Freeze", which is sited three weeks before Alpha Freeze, and when Changes are supposed to be in a "testable" state. The other is really only called the "Beta deadline/accepted changes 100% complete", which is kind of awkward, and is when Changes are supposed to be in "100% code complete" state.
We had a bit of confusion about the "Changes Freeze" due to a mistaken change to the Changes/Policy page, and as part of the discussion of that. mattdm suggested perhaps these points could be renamed "Changes checkpoints". I like that idea - it describes what they are more clearly than either "Freeze" (because we don't actually freeze anything at either point) or "deadline".
At present the wiki documentation is a bit messed up because I changed things according to what was written on the Changes/Policy page, which turned out to be inadvertently incorrect (the "Changes/Feature Freeze" date was conflated with the "Alpha Freeze", which doesn't appear to have been anyone's intention). I'd like to fix it all up, but it'd be good to know whether the dates will be renamed before I go do the edits.
So FESCo at today's meeting sort of gave me carte blanche to do something sane and communicate it back. Here's what I've got:
https://fedoraproject.org/wiki/Changes/Policy#For_developers (expand the 'What are the change process deadline dates (Checkpoints)?' header) https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
Basically, we now have three dates:
I kept the 'deadline' name in the 'subtitle', to try and keep the sense of urgency some wanted, but made the headline names all 'Checkpoint' to keep them consistent and avoid possible confusion with the old "Change deadline" dates which were actually the milestone freezes.
The saga of the actual 'feature completion deadline' date continues, I'm afraid. It seems at least clear that the conflation of the "Feature Freeze" / "Changes Freeze" / "Change Checkpoint 2" date with Alpha Freeze was a mistake on stickster's part, not actually a FESCo decision.
When the date is actually supposed to be, though, is an interesting question. None of the current (before my changes) or old Changes or Features policy pages explicitly states this; they all talk about what it means, not when it is.
If we look at historical practice, what happened is that for every release after No Frozen Rawhide, it was always placed on the same date as the Branch event. All the way from https://fedoraproject.org/wiki/Releases/13/Schedule to https://fedoraproject.org/w/index.php?title=Releases/21/Schedule&oldid=386596 (last rev before I touched it), this is the case.
However, there's a bit of a problem with that in practice, because the branch date changed. If you look at the older schedules - 13 through 18 - the branch date was only a week before Alpha freeze. From 19 onwards the branch date was moved relatively earlier, to two or three weeks before Alpha freeze...and the "Feature / Changes Freeze" or "feature completion deadline" or whatever moved along with it. I'm not sure if this was explicitly considered by FESCo.
For right now, I've made the Wiki document the facts on the ground, and stated that Checkpoint 2 occurs on the same day as the Branch event. However, FESCo may want to consider if this is in fact what they want, still. I see three possibilities:
I think it makes sense to make it on the same day as Alpha Freeze. Before that we aren't frozen so the implication is that we want development to keep flowing in, after that we are, so to me that means it should be all complete and testable at that point.
Little nugget for fact fans: the chain of causality for the Branch event / 'feature freeze' was the other way around. Way back in the mists of time (otherwise known as No Frozen Rawhide), the Branched date was chosen to occur on the date of the feature freeze, which was a thing that already existed.
"Without getting too much into detail, when we reach feature freeze, and offer pre-branch capability, we turn that into a full branch event." - https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
Of course, we've tweaked the process quite a bit since the original NFR so I don't know if that matters much any more, just thought I'd mention it.
I got disconnected yesterday as my laptop ran out of juice...
So a few comments: * "Change Checkpoint 1: Proposal submission deadline" - I'm not sure it makes sense to number checkpoints as we have different labels with description. Also this deadline applies only to System Wide Changes. "Change Checkpoint: Proposal submission deadline (System Wide Changes)"
"Change Checkpoint 2: Feature completion deadline" should be "Change Checkpoint: Completion deadline". Please, do not use "feature" - we had hard times trying to avoid it in the name. "Change" was the best replacement but...
"Change Checkpoint 3: 100% code complete deadline" would be "Change Checkpoint: 100% code complete deadline". Also hard stop for Self Contained changes.
"Make it a separate day probably somewhere between the two, defined in relation to them" seems like the best approach. It's later than branch, on the other hand at Alpha Freeze - we want it testable and in Alpha but without the hassle of freeze exceptions etc.
The reason for numbering them was simply to give people a shorthand for referencing them. If they don't have numbers, what do you call them? No-one's going to sit down and write out "100% code complete deadline". Giving them numbers lets people just say 'checkpoint 3' or something.
"Feature complete" came straight from the text. I didn't put it in there. Here's the page from before I ever touched it:
https://fedoraproject.org/w/index.php?title=Changes/Policy&oldid=359507
" Change freeze: New changes must be feature complete or close enough to completion"
I just took it out and used it for the name. Calling it 'completion deadline', with no qualification of what kind of 'completion' we're talking about, seems misleading.
"It's later than branch, on the other hand at Alpha Freeze - we want it testable and in Alpha but without the hassle of freeze exceptions etc."
So it's worth bringing up that there's a lack of clarity as to whether these are the dates on which FESCo will check the Changes to see whether they have reached these statuses, or the hard dates by which they must have reached these statuses presumably with FESCo checking along the way. For example, if you expand "The process for complex system wide changes", there's a bit that says:
" FESCo will re-review the status of complex changes one week before the Beta change deadline. At this time, FESCo typically decides whether to activate the contingency plan. Any change for which FESCo can't make this decision one week before beta must include a note on its Change wiki page and tracking bug. "
exactly how that ties into the Checkpoints is not specified. It doesn't seem to be an entirely clear policy.
I think we finished discussing this in the last weeks meeting, but didn't agree to close it. ;)
I'll close it now, and ask that you re-open if there's anything more we need to discuss here.
So we never completely decided on the 'change checkpoint 2' date formally, I don't think - but for Fedora 22, jreznik made it the same day as Alpha freeze. So I'll make the policy page document that, for now.
I was pointed to this ticket by adamwill, as he realized that the outcome of this discussion has not been fully reflected in F23 and F24 schedules. So, I went through this discussion, checked the way how old schedules (F22 and some releases before F22) were planned to compare how things were done in the past and to understand what is the issue here.
Basically, the discussion in this ticket has two topics. The first one is naming of deadlines for Changes. The second topic is time alignment of Change deadlines with key milestones. My comments and proposals to this two topics follows:
Task names: I am fine with the current naming and do not have any objecions here. The current naming is:[[br]] Change Checkpoint: Proposal submission deadline (System Wide Changes)[[br]] Change Checkpoint: Completion deadline (testable)[[br]]* Change Checkpoint: 100% Code Complete Deadline
Checkpoints alignment[[br]]Here I put together a proposal of the rules, which were more-less followed during the planning of previous releases and make sense to me:
I would like to ask FESCo to review the proposed timelines for planning Changes and alignment of this timelines with branching, mass rebuild and Freezes. In case this will be agreed by FESCo, I will modify the [https://fedoraproject.org/wiki/Changes/Policy Fedora Release Planning Process] and I will also follow these guidelines during F25 planning (and all the upcoming releases as well).
I case there are any objections to the proposal, please let me know what these are and what are your recommendations, so I can follow up with it.
NOTE: I am not able to attend the meeting on 2016-01-08, so if there will be a need for my direct input during the discussion, please postpone this ticket to the meeting on 2016-01-15.
+1 to both of jkurik's proposals.
Login to comment on this ticket.