Re: KDE 4.4.2 tarballs (try #1) uploaded
On Sunday 28 March 2010, Simon Edwards wrote: The kdebindings tarball fails to build with this error: It is fixed up on the 4.4 branch (rev 1108301). Great, thank you Simon! This works indeed. I've updated the tarball. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.5 schedule
On March 27, 2010, Simon Edwards wrote: I strongly want to see an API freeze kick in at this time too. No more changes to APIs or header files (except docs) after this date, including the result will be poorer APIs than necessary. those of us working on new API often do not get critical feedback on API related issues, particularly the detail oriented sort. already some things leak through and make it into final releases, despite doing API reviews at the project level (e.g. on plasma- devel) and subsequently asking for review elsewhere (e.g. k-c-d). the less time we have to do this, the more warts that will slip through. i understand that the ballance point is binding releases, but i question prioritizing those efforts over the sanitation of the C++ APIs that underly them. if bindings need extra time to release, could we do bindings releases N weeks after the Development Platform C++ release? this would avoid a trade off between rushed bindings and more warts in the C++ API. -- 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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.5 schedule
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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kde-l10n-sv for 4.4.2 does not compile
You might want to remove sv/kdeedu/kturtle/index.docbook to make it compile. Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.5 schedule
On March 29, 2010, Tom Albers wrote: Op Monday 29 March 2010 19:02 schreef u: On March 27, 2010, Simon Edwards wrote: I strongly want to see an API freeze kick in at this time too. No more changes to APIs or header files (except docs) after this date, including the result will be poorer APIs than necessary. those of us working on new API often do not get critical feedback on API related issues, particularly the detail oriented sort. already some things leak through and make it into final releases, despite doing API reviews at the project level (e.g. on plasma- devel) and subsequently asking for review elsewhere (e.g. k-c-d). the less time we have to do this, the more warts that will slip through. i understand that the ballance point is binding releases, but i question prioritizing those efforts over the sanitation of the C++ APIs that underly them. if bindings need extra time to release, could we do bindings releases N weeks after the Development Platform C++ release? this would avoid a trade off between rushed bindings and more warts in the C++ API. I don't think a separate release from kdebindings is managable in the current team. fair enough. What we could do is a soft api freeze, where api changes are allowed, but need to be CCMAIL'ed to the kde-bindings ml. that's doable. And set a hard api freeze (a week before rc1 tagging?) where no api changes are allowed anymore. Could that help? if at all possible i'd prefer at the point of rc1 tagging so that we have the full development time window to ensure API goodness. Simon (and other bindings people): would that be enough time for you folks? -- 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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
