Hello everyone, I planned to send this email yesterday but I didn't get a chance to. It would be good to plan the next few weeks for getting packages in Zesty and the Backports repositories so we know what to work on. I proposed a timeline on Big Blue Button yesterday while we were doing merges, but I didn't get a yes or no from everyone, so I'm proposing the following timeline:
Wednesday, November 9: * Have the autopkgtests finished for Frameworks 5.27 * Upload Frameworks 5.27 to Zesty * Upload Frameworks 5.27 to Backports Landing, wait for Plasma 5.8.3 to do anything with it * Upload Plasma 5.8.3 to the Staging PPA * Create the Trello card for Plasma Debian Syncs and start doing so Saturday, November 12: * Plasma should be completely merged from Debian and autopkgtests should be working * Frameworks 5.27 should have completely migrated from zesty-proposed to zesty-release so Plasma 5.8.3 can be built against it in the archive * Upload Plasma 5.8.3 to Zesty * Upload Plasma 5.8.3 to Backports Landing, send out a call for testers so we can migrate this to Backports * Upload Frameworks 5.28 to the Staging PPA * Recompile the Plasma in Staging against Frameworks 5.28 and fix any problems that may arise from doing so, to be prepared for Plasma 5.8.4 Wednesday, November 16: * Frameworks 5.27 should have completely migrated from zesty-proposed to zesty-release so nothing tries to build against Frameworks 5.28 * Upload Frameworks 5.28 to Zesty * Upload Frameworks 5.28 to Backports Landing * Move Plasma 5.8.3 and Frameworks 5.27 to Backports (we could postpone this a couple days) After that is done, we would have the following: Staging: * Plasma 5.8.3 * Frameworks 5.28 * Applications 16.04.3 Zesty Archive: * Plasma 5.8.3 (compiled against Frameworks 5.27) * Frameworks 5.28 * Applications 16.04.3 Backports Staging: * Plasma 5.8.3 (compiled against Frameworks 5.27) * Frameworks 5.28 * Applications 16.04.3 Xenial/Yakkety Backports: * Plasma 5.8.3 * Frameworks 5.27 * Applications 16.04.3 This would be a loose timeline and we could adjust timing when appropriate, but it would be great if we had a general plan. After this is done, we have a few weeks until Plasma 5.8.4 is released. It would be great if we could schedule a day on a weekend where we get together on Big Blue Button, do what we did with the Frameworks Debian Merges, and try to make KCI very close to being spotless (or maybe even 100%). We talk out whatever issues we have, maybe someone shares their screen, but it's a time to be productive and all in one place to talk about issues. Getting KCI FTBFS jobs down to a manageable amount should be a priority within the team, and in the few weeks we have before we need to stage another KDE release, we could get that done for sure. Another thing we could discuss in the meantime is making sure that while we are shipping the latest software, all of the software is usable and works as intended. I think it would be beneficial if we had a bug hunting session and ensure that whatever bugs we have are reported and being worked on. This makes a better Kubuntu for all of us. An example of an area of Kubuntu that is very buggy is KMail. Yesterday I tried to set it up, but I couldn't set it up because it was having problems with Akonadi. We shouldn't ship software as buggy as that, and people just installing software instead of that isn't an excuse. One could install Thunderbird or Evolution (etc.), sure, but then why do we include software that doesn't work on our seed? So that is, in my opinion, what we should really focus on in the next few weeks. We need to get these sort of things done now so that we aren't suffering for the rest of the cycle. Once those few weeks are over, we have another bugfix version of Plasma to ship, 5.8.4. You may have noticed above that we ship Frameworks 5.28 but don't compile anything against it yet. I think this is a good thing to do because it's less work in the long run for uploading packages. If we sort out any issues Frameworks 5.28 might have *before* compiling a whole desktop environment for it in Backports Landing or the Archive, that would be preferred. A few weeks of maintenance time doesn't hurt, either. Plus, the Kubuntu users that are developers get the latest Frameworks with new features and bugfixes, which is also a good thing to have. Developers are users too. ;) So the way I propose it's set up is this. We get Plasma 5.8.3 compiled against Frameworks 5.27, get both of those in Zesty archive and Backports, then we get Frameworks 5.28 in Staging. While people are testing that, we recompile Plasma 5.8.3 against it in the Staging Plasma PPA by setting a build dep in the PPA options. If there are any visible issues, we take note of them and get them fixed in the Staging PPA. But we would actually release Plasma 5.8.4 built against Frameworks 5.28. I think we should do this, unless somebody sees the importance of waiting until Frameworks 5.28 lands to ship Plasma 5.8.3 (and compile against that). Please do speak up if you think we should go that route, and postpone the timeline until then. The one other thing I wanted to write about in this email is Applications. Currently, we're waiting on Qt 5.7.1 to land in the archive to upload Applications. With that Qt release will come QtWebEngine and QtWebChannel, which are needed dependencies for this new Applications release if I remember correctly. I've been talking with Timo and I'll help get Qt 5.7.1 in the archive. We don't know an exact timeline yet, as we're waiting for the Qt release team to release, but once Qt 5.7.1 is released, it will go into a PPA. From there, we should recompile all of our packages in KCI against it and make sure there are no breaks caused by the new Qt. At this point we could also set the Qt PPA as a dep of Staging Applications, and upload a fresh Applications release there. We can work out any problems there, and wait for Qt to land in the archive to upload it. While it will land in the Qt PPA soon after 5.7.1 is released, Timo told me it takes *months* sometimes to get everything in the Ubuntu Phone repositories and everything else working. Since not only do we need Qt 5.7.1 in the archive for Kubuntu (for Applications) but Lubuntu as well, so we can continue work on our LXQt transition, I plan on working closely with Timo to learn and speed this up whenever possible. I'll keep you all posted about this. Thoughts? -- Simon Quigley [email protected] tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
