Re : kdesupport discussion on release-team list
Sorry!! I sent this message a week ago, but it seemed to have been lost! Please ignore. Benoit 2008/9/1, Benoît Jacob [EMAIL PROTECTED]: Hi, I just found out these discussions on the release-team list, to which I am not subscribed: http://mail.kde.org/pipermail/release-team/2008-August/002395.html http://mail.kde.org/pipermail/release-team/2008-August/002433.html My questions are: 1. Is /trunk/kdesupport going to be no longer recommended to build KDE SVN? I mean e.g. on the techbase page, http://techbase.kde.org/Getting_Started/Build/KDE4/Prerequisites#kdesupport Any plan to update that page to no longer recommend to checkout /trunk/kdesupport? 2. What is the difference between a tag and a branch ? I seem to see a lot of overlap between /tags and /branches. 3. So what is the tag that I should create for version x.y of eigen: is it /tags/eigen/x.y ? 4. We are about to release a beta version of eigen but the 2.0 final will have to wait about 6-10 more weeks. Shall I still create a tag as soon as possible? /tags/eigen/2.0-beta1 ? Or wait until 2.0 to create a tag? 5. After we create a tag does that mean that we can do whatever we want in /trunk/kdesupport/eigen2 without risking to break compilation for other people? This is related to question 1. As long as we tell people to use kdesupport, making tags is rather pointless. Cheers, Benoit Howdy, If you are a developer of a kdesupport project, please make sure that your latest-and-greatest stable version is tagged in our subversion tags repository. The lastest-and-greatest stable version should be the version that we need to use when building trunk. If you need help with this, please send a note to release-team ML. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Qt 4.5 and KDE 4.2
Hi, In rescheduling the 4.2 release, it seems we missed the fact that by moving the schedule forward, we can no longer depend on Qt 4.5. I wonder if that is the right thing to do. What would be the disadvantage to revert this change (besides me looking silly), and having a 5 month 4.3 cycle? Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Qt 4.5 and KDE 4.2
On Monday 08 September 2008 12:42:59 Tom Albers wrote: Hi, In rescheduling the 4.2 release, it seems we missed the fact that by moving the schedule forward, we can no longer depend on Qt 4.5. I wonder if that is the right thing to do. What would be the disadvantage to revert this change (besides me looking silly), and having a 5 month 4.3 cycle? The original schedule was acceptable to everyone. Apparently it also was nicely timed to allow for Qt 4.5 before the 4.2 release. The only drawback with the original schedule is how it lines up with Akademy. People already planned to the original schedule -- there are sprints and meetings planned according to the original. Something has to give. - we can't force TT to change their schedule - we can't change the Akademy plans - people can't easily change the dates of their sprints - we don't look good if we stretch the 4.2 cycle out to 8-9 months I have no idea how to proceed. I guess I'd lean toward reverting back to the original since we delayed so long announcing the revised schedule. Either that, or stretch out to 8-9 months. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Qt 4.5 and KDE 4.2
On Monday 08 September 2008, Tom Albers wrote: In rescheduling the 4.2 release, it seems we missed the fact that by moving the schedule forward, we can no longer depend on Qt 4.5. I wonder if that is the right thing to do. What would be the disadvantage to revert this change (besides me looking silly), and having a 5 month 4.3 cycle? 3 months of devel and 2 months of freeze? i suppose it could work for one release. rather tight, but better than altering 4.2 at this point as that is going to screw over at least a couple major KDE projects that do actual planning ahead of time (PIM and Plasma) and likely others. the KDE imaging people are planning a sprint in november as well.. i believe that time was chosen in part due to the previous schedule. -- 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 Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
a self debriefing
once the 4.2 schedule decision is worked out, i think it would be really good to sit back and ask some questions. this may simply re-affirm what we are doing, or it may indicate need for changes. either way, having a conscious awareness of how we are doing is undeniably better than simply making it up as we go along. some questions i'd suggest asking ourselves (please add your own as well): * what has the 6 month cycle won us in terms of real benefit thus far? * are we getting the return in commitment promised from third parties due to the discipline of a 6 month cycle, or do we need to re-assess that with them? * how long before we can disentable the development cycle from it, ala Dirk and Sebastian's presentation at Akademy '08? * if that disentanglement will take more than a year, how do we deal with aligning our development with Qt? (our most critical and quickly evolving component) * under what circumstances should we allow ourselves to alter the plan for the cycle we are currently in at the time? * how do we define useful predictability? is it knowing that the goal in N cycles from now will be 6 months, or is it more important to know with certainty what the next 2-3 releases will actually be? * are application developers being well served by the amount and form of communication thus far? * are the libraries being well served by the amount and form of communication thus far? overall, i think the release team is doing a very good job. the above questions are not an indictment or a measure of distrust in the process. they are, rather, out of respect for what is working and a desire to see this team remain a healthy and well-oiled machine. -- 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 Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Change release schedule Part II
Hi, I think we -by now- all agree the change of plans for 4.2 was a mistake. I've reverted that change on the wiki. To be clear: we stick to the original schedule. Find it at [1]. Sorry for the confusion. Best, Toma [1] http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: a self debriefing
On Monday 08 September 2008 14:25:20 Aaron J. Seigo wrote: some questions i'd suggest asking ourselves (please add your own as well): * what has the 6 month cycle won us in terms of real benefit thus far? For me, there is a real benefit in having a regular cycle. I won't argue here if 6 months is the best frequency. * are we getting the return in commitment promised from third parties due to the discipline of a 6 month cycle, or do we need to re-assess that with them? No idea. * how long before we can disentable the development cycle from it, ala Dirk and Sebastian's presentation at Akademy '08? That's another thread, but I think we should start planning. * if that disentanglement will take more than a year, how do we deal with aligning our development with Qt? (our most critical and quickly evolving component) My understanding is that the Qt release cycle isn't that predictable. But Thiago published the expected dates for the next year or so. Thus, we might be able to plan 4.3 with the Qt cycle in mind. * under what circumstances should we allow ourselves to alter the plan for the cycle we are currently in at the time? We need to do better at the beginning.We need better planning tools. Even a calendar with important, relevant events would help. Once we have a schedule, we should only vary each milestone by 1-2 weeks (as we have always done), depending on the state of the code. (showstoppers, etc) * how do we define useful predictability? is it knowing that the goal in N cycles from now will be 6 months, or is it more important to know with certainty what the next 2-3 releases will actually be? I like being able to say that there will be a new KDE 4.x every Y months. * are application developers being well served by the amount and form of communication thus far? No, I think we stink at communication. * are the libraries being well served by the amount and form of communication thus far? See previous answer. overall, i think the release team is doing a very good job. the above questions are not an indictment or a measure of distrust in the process. they are, rather, out of respect for what is working and a desire to see this team remain a healthy and well-oiled machine. Me too. My biggest areas of concern, in no particular order: - improving communication - improving schedule planning - finalizing our set of module coordinators - 6 months? 8 months, 12 months?... - summer in trunk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Release Coordinator
Hi, unfortunately Matt Rogers recently had to step down from the role of Maintainer/Release Coordinator for the kdevelop and kdevplatform module. So we (that is the KDevelop developer team) tried to find a new person for the job. As far as it looks by now (80% of the team acknowledged it) that will be me - as I basically already do 90% of the job :) I've checked the apropriate techbase page and just wanted to double-check wethere there's anything, besides being subscribed to this list and putting my name on the Release Team page on techbase, that I need to do to start :) Andreas -- You will be recognized and honored as a community leader. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Qt 4.5 and KDE 4.2
On Sep 8, 2008, at 11:42 AM, Tom Albers wrote: Hi, In rescheduling the 4.2 release, it seems we missed the fact that by moving the schedule forward, we can no longer depend on Qt 4.5. I wonder if that is the right thing to do. What would be the disadvantage to revert this change (besides me looking silly), and having a 5 month 4.3 cycle? Toma Another idea would be to also find out how long a conversion to Git and the always summer in trunk approach would take and then releasing kde 4.3 before akademy might not matter as much. -- Matt ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
