On March 27, 2010, Tom Albers wrote: > Final problem we had this cycle was changing dependencies until late in the > schedule. I want to stop that insanity. So I added a dependency freeze at > the soft feature freeze time. People should by then know what they want to > add as features for that cycle and think about the dependencies they need. > During the dependency freeze it is not allowed to introduce new > dependencies or raise the version of existing dependencies.
sounds sane, though perhaps it would make more sense to delay it until the hard freeze? that's still nearly 3 months prior to release and does put that barrier in place that you note we need. > I hope you agree to these changes so we can make the schedule final > soonish. http://techbase.kde.org/Schedules/KDE4/4.5_Release_Schedule it's looking better and better. thanks for putting this together :) one thing that's not 100% clear to me from that page, however, is when the 4.5 branch is created in relation to trunk being frozen. in the "June 23rd: Tag + release RC 1" section it says: "Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged." i suppose that means that when RC 1 is tagged, then the branch is made and trunk is re-opened for development targetting the 4.6 release? some clarification around that in the schedule page would be great. there are three weeks between RC1 and RC2. that's probably about a week longer than is useful for at least some of us. the teams i'm involved with have found that after ~2 weeks of testing a pre-release we stop getting significant numbers of reports for new issues and it becomes a mark-the-duplicates game in bugs.kde.org. after a subsequent pre-release that addresses those issues, we start getting new issues reported again. the betas are two weeks apart and that's awesome; can we move the RCs to have the same gapping? that would mean one of: * moving RC2 back to July 7 * moving RC1 forward to June 30 if we move RC2 back, we give ourselves more room for another RC if needed. if we move RC1 forward, we give ourselves room for perhaps another beta release. there is a full week between tagging and release of betas. there is also just one week between release of beta N and the tagging of beta N+1. is it possible to shorten the window between tag and release, so that the window between release of beta N and tagging of beta N + 1 is longer, allowing for more fixes to make it into the N + 1 beta? e.g. if beta 2 was tagged on the 4th, that would give us 2 more days (for a total of 9) to get feedback on beta 1 and incorporate fixes into beta 2; this would mean only 5 days, however, between tag and release of beta 2. this is probably not a _critical_ issue, but if we can get a bit more efficiency out of the beta cycles, that's always a plus. but perhaps tag-to-release in under a week is too little time from a release team perspective (e.g. due to the effort needed to make it happen)? in general, i think this schedule is looking good and imho we should try and make it "official" by wednesday at the latest and announce it at that point to k-c-d. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
