Thank you Simon for the proposal. I see this as an optimistic road-map, and I think it's going in the right direction to have a road-map set.
I'm not sure about compiling Plasma 5.8.3 on Frameworks 5.27. What's the minimal dependency Plasma 5.8.3 requires from Frameworks? I'm not sure I understand why not compile everything new with Frameworks 5.28 as soon as we have it available. Perhaps I'm missing something here. Regarding Qt 5.7: What's the current status of having it in the archive? Is this more than a one man job? If yes, I believe that should be our first focus. Regards, Ovidiu-Florin Bogdan *Ovidiu - Florin BOGDAN* GeekAliens.com <http://ovidiu.geekaliens.com> Kubuntu România <http://kubuntu.org> <http://www.google.com/profiles/ovidiu.b13> 2016-11-07 7:12 GMT+02:00 Simon Quigley <[email protected]>: > 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 >
-- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
