20:59 <tsimonq2> #startmeeting arraybolt3 for ~lubuntu-dev
20:59 <meetingology> Meeting started at 20:59:44 UTC.  The chair is tsimonq2.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
20:59 <meetingology> Available commands: action, commands, idea, info, link, nick
21:00 * arraybolt3[m] powers on battle suit
21:00 <tsimonq2> arraybolt3 @arraybolt3:matrix.org:  Hi, please introduce yourself.
21:00 <arraybolt3[m]> OK.
21:02 <arraybolt3[m]> My name is Aaron Rainbolt. I am a developer in my free time with a passion for using and enhancing Linux. I spend a lot of time helping others with their Linux systems, helping to develop Lubuntu, and planning future projects related to the Linux ecosystem. I've loved working with the Lubuntu team so far and hope to continue to for as long as I can.
21:03 <tsimonq2> Hey! Before we begin, do we have a majority of Lubuntu Developers?
21:03 <kc2bez[m]> I am here.
21:04 <tsimonq2> Dan, you can start with the first question
21:04 <kc2bez[m]> Sounds good.
21:04 <kc2bez[m]> What is Ubuntu delta and why might we want it?
21:05 <arraybolt3[m]> An Ubuntu delta is a difference in the packaging between a Debian package and the Ubuntu package it is based on. Ubuntu deltas are generally kept to a minimum, but may come in handy when there is a critical difference between how Ubuntu does something and how Debian does it with the same software package.
21:06 <arraybolt3[m]> It may also be useful in the event Ubuntu releases a Stable Release Update for a particular software package without changing the rest of the package dramatically (for instance, in a backported security or bug fix).
21:07 <arraybolt3[m]> Technically, the Ubuntu delta is the diff between a Debian package and its corresponding Ubuntu package, generated with debdiff, I believe.
21:07 <arraybolt3[m]> (Tar, I misphrased the start, it's the difference between an Ubuntu package and the Debian package it is based on. Ubuntu is based on Debian, not the other way around.)
21:08 <tsimonq2> Dan, if that answers your question, I'll move onto mine :)
21:08 <kc2bez[m]> I am good, thanks.
21:09 <tsimonq2> What is Feature Freeze and Beta Freeze respectively, and why are they important?
21:11 <arraybolt3[m]> Feature Freeze is the point at which new packages, features, and APIs are stopped being introduced into the current development release of Ubuntu. It is the time when we concentrate on fixing bugs in the development release. There isn't a freeze of the upload queue during this time. Exceptions may be granted if a change contributes to a high priority feature goal, if it contains only bug fixes, or if it is warranted due to other
21:11 <arraybolt3[m]> exceptional circumstances.
21:13 <arraybolt3[m]> Beta Freeze is a much more intensive freeze that occurs just before the beta ISOs of the development release are created. At this point, no new features, user interface changes, documentation strings, kernel features, or hardware enablement changes are allowed.
21:13 <arraybolt3[m]> (It isn't quite as intensive as Final Freeze, however.)
21:13 <tsimonq2> A quick followup question if I may, what are the differences in "intensity" that you're specifying in terms of what lands in a queue and what goes straight into the Ubuntu archive?
21:14 <arraybolt3[m]> The intensity differences are how tightly the archive is frozen - can something just be uploaded and go straight into the archive or a queue, or does it need a special exception for it to go through?
21:14 <arraybolt3[m]> The more that things need exceptions, the more intensive the freeze.
21:15 <tsimonq2> There's a slightly more nuanced answer to that question that does not directly affect my vote, follow up after
21:15 <tsimonq2> I'm satisfied
21:15 <tsimonq2> Back to Dan :)
21:15 <kc2bez[m]> I have a follow-up to that too.
21:16 <kc2bez[m]> What team reviews the exceptions referenced in the Freeze period?
21:17 <arraybolt3[m]> For Beta Freeze, it's the release team. I'm not sure about the other freezes, I can look that up however.
21:17 <kc2bez[m]> I'm good with that answer.
21:17 <kc2bez[m]> Simon?
21:19 <tsimonq2> What does ${misc:Depends} do and why is it useful?
21:20 <arraybolt3[m]> I know I've read the docs for that, one moment...
21:21 <arraybolt3[m]> According to the Debian documentation, some debhelper commands may cause the generated package to depend on some additional packages. Each of these commands generate a list of the required packages for each binary package. ${misc:Depends} is substituted with that list.
21:21 <arraybolt3[m]> (Drawing from https://www.debian.org/doc/manuals/maint-guide/dreq.en.html)
21:22 <tsimonq2> I'm satisfied with that answer. Dan?
21:22 <kc2bez[m]> What does it take for a package to be considered a valid candidate for proposed migration?
21:24 <arraybolt3[m]> The package must:
21:24 <arraybolt3[m]> 1. Be built and published on all architectures it is currently published for in the release pocket.
21:24 <arraybolt3[m]> 2. Have all of its dependencies satisfied by packages that are either in the release pocket or by packages that will be installed at the same time.
21:24 <arraybolt3[m]> 3. Pass all autopkgtest test suites (or have any failures be ones that have always failed).
21:25 <arraybolt3[m]> (For 1, it is acceptable if other binaries from the same source for the same architecture are up to date in -proposed, and the binary in question has been removed.)
21:25 <kc2bez[m]> Great, thanks.
21:27 <tsimonq2> Let's say the Ubuntu archive is open. Please provide two examples of when it would be a bad time to upload a new LXQt stack
21:28 <arraybolt3[m]> Hmm...
21:28 <arraybolt3[m]> One example would be if it could cause problems with other large transitions occurring at the same time (clogging up the queue too much).
21:28 <arraybolt3[m]> Another example might be if a dependency needed for the new LXQt stack is not yet in either -proposed or -release, but in that instance one would probably get local build failures before uploading the packages to the archive.
21:29 <tsimonq2> Answer one is what I'm looking for, I'm looking for a more general example than answer two
21:29 <tsimonq2> (So please provide one more if you could)
21:30 <arraybolt3[m]> I guess another bad time would be if a package in -proposed is currently having trouble migrating and the new LXQt stack depends on that package, as that would result in a partial stack migration and break LXQt for users of the development release (like me!).
21:31 <tsimonq2> Okay, I'm good. I would have also accepted "when the autopkgtest queues are backed up"... :)
21:31 <tsimonq2> On to Dan
21:31 <kc2bez[m]> What is a SRU and when would it be warranted?
21:33 <arraybolt3[m]> A Stable Release Update is a change made to a package in an already-released version of Ubuntu. Stable Release Updates are not to be used for overly large changes, as that comes with a significant regression risk, and released versions of Ubuntu must remain stable for their existing user base. However, for high-impact bugs and security problems, a Stable Release Update can be used to fix the bug so long as it comes with a
21:33 <arraybolt3[m]> sufficiently low regression risk, a good test suite, and a good reason to do the update.
21:34 <arraybolt3[m]> (Some stable release updates may be appropriate for things like LTS hardware enablement, certain new features for LTS releases that can be safely introduced, and bug fixes with an obviously safe patch. This isn't an exhaustive list.)
21:34 <kc2bez[m]> Thanks, I'm good with that.
21:36 <kc2bez[m]> Simon, do you have any more?
21:36 <tsimonq2> Give me a second to find this one, I'll let Dan ask another one in the meantime
21:36 <tsimonq2> I have two more
21:36 <tsimonq2> I think the first of the two deserves exact text :P
21:36 <kc2bez[m]> Ok
21:37 <kc2bez[m]> What is MoM and how is it helpful?
21:38 <arraybolt3[m]> MoM (or Merge-o-Matic) is an automated tool that assists in bringing new packaging changes from Debian into Ubuntu while preserving Ubuntu deltas. Due to its nature as an automated tool, it should not be trusted blindly to do the right thing, however it can help ease the maintenance burden when an Ubuntu delta must be preserved and cannot be upstreamed into Debian and dropped.
21:39 <kc2bez[m]> Thanks.
21:41 <tsimonq2> Let's say LXQt upstream releases a piece of software named lxqt-funstuff. The license isn't standard, but states "You may use this software in source and compiled form as you wish, but you must send me a postcard at the mailing address listed below:"
21:41 <tsimonq2> Is this permissible to distribute in Ubuntu?
21:41 <tsimonq2> And as a small followup, is it permissible to distribute files with no license whatsoever in the Ubuntu archive?
21:44 <arraybolt3[m]> When encountering a non-standard license, it would be necessary to match it up against the Debian Free Software Guidelines to determine if it complied with them or not (though this may not be something someone with limited legal knowledge can do safely). In this particular instance, I believe this license would not be DFSG-compatible, as it would not allow free redistribution, the very first point of the DFSG.
21:44 <arraybolt3[m]> No, it is absolutely not permissible to distribute unlicensed files in the Ubuntu (or Debian) archive. Such files must be assumed to have all rights reserved by the copyright owner.
21:45 <tsimonq2> Perfect. Dan, do you have any more questions?
21:45 <kc2bez[m]> I am good at this time.
21:46 <tsimonq2> Sounds good. Here goes my next question...
21:46 <tsimonq2> When should you tag an upload in its packaging Git repository?
21:46 * arraybolt3[m] looks up docs in Phabricator
21:47 <arraybolt3[m]> Only once the upload is accepted, the release commit must be tagged with ubuntu/VERSION, where VERSION is the full Ubuntu version.
21:48 <tsimonq2> Sweet. One more question, I've saved this for last...
21:49 <tsimonq2> Where do you see Lubuntu in 2 years?
21:51 <arraybolt3[m]> In 2 years, I hope that as people migrate away from Windows 10 in preparation for it to go EOL, those with lower-end hardware discover Lubuntu and use it to keep their current hardware alive rather than throwing it away. I would like to see it become one of the best Windows alternatives in the Linux ecosystem, as we continue to polish it, stabilize it, and enhance it to work for both power users and non-power users out of the box.
21:52 <arraybolt3[m]> (I also personally hope to see it work on those pesky Windows 8 netbooks with 32-bit UEFI and a 64-bit CPU by then :D)
21:52 <tsimonq2> That's all I have. Time to vote...
21:53 <tsimonq2> #vote Add ~arraybolt3 to ~lubuntu-dev
21:53 <meetingology> Please vote on: Add ~arraybolt3 to ~lubuntu-dev
21:53 <meetingology> Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname')
21:53 <tsimonq2> #voters kc2bez, tsimonq2
21:53 <meetingology> Current voters: kc2bez, tsimonq2
21:53 <tsimonq2> (And teward's proxy vote)
21:54 <tsimonq2> +1
21:54 <meetingology> +1 received from tsimonq2
21:54 <kc2bez> +1
21:54 <meetingology> +1 received from kc2bez
21:54 <kc2bez[m]> teward gave a +1 via proxy
21:55 <tsimonq2> #endvote
21:55 <meetingology> Voting ended on: Add ~arraybolt3 to ~lubuntu-dev
21:55 <meetingology> Votes for: 2, Votes against: 0, Abstentions: 0
21:55 <meetingology> Motion carried
21:55 <tsimonq2> Congratulations arraybolt3, you are now a Lubuntu Developer.
21:55 <tsimonq2> #endmeeting