Current status of Zesty and Backports

Mon Nov 7 10:11:39 UTC 2016

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 <tsimonq2 at ubuntu.com>:

> 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
> tsimonq2 at ubuntu.com
> tsimonq2 on freenode and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/kubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20161107/6a9807ae/attachment-0001.html>