KDE SC 4.5 schedule

[Aaron J. Seigo]

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