[15:50] <arraybolt3> Taking a look at Lubuntu Update again today
[15:51] <arraybolt3> I added a "Check for updates" button to it some time ago and am hopefully going to get that pushed to the archive today.
[16:18] <tsimonq2> arraybolt3: Thanks, let me know if you need anything. ;)
[16:18] <tsimonq2> *:)
[16:18] <tsimonq2> extra caffeinated today my bad
[16:58] <arraybolt3> ok so we need to decide what UI we want the actual do-release-upgrade process to have.
[16:58] <arraybolt3> I am NOT brave enough to reimplement do-release-upgrade itself from scratch :P so we're just going to launch it and let it do the hard work.
[16:59] <arraybolt3> But how exactly do we want to inform the user that a new release of Lubuntu is available? Where should the button go that lets them install it? Do we work in how much time is left before the current release goes EOL? Perhaps we try to force the user to release-upgrade if they're like a week away from EOL?
[17:01] <arraybolt3> meh, at least for LTS a forced update like that isn't a great idea.
[17:12] <tsimonq2> arraybolt3: When I added this into the Python 3 version, here was my rationale...
[17:12] <tsimonq2> do-release-upgrade will only actually run once all updates have been applied.
[17:13] <tsimonq2> The user story I had in my mind is, let's ask them once the update is fully finished if they want to do a release upgrade.
[17:13] <tsimonq2> Slightly more passive than a standalone notification.
[17:13] <tsimonq2> Anyway, thoughts?
[17:14] <arraybolt3> I like it.
[17:14] <arraybolt3> Like run one extra check that says "A new version of Lubuntu is available!" and then buttons "Install Now", "Remind me later", and "No, and don't ask again"?
[17:16] <arraybolt3> hmm, there's some extra UX to work out here
[17:16] <arraybolt3> I'll figure something out and give a proposal.
[17:43] <tsimonq2> Sounds good :)
[18:15] <arraybolt3> tsimonq2, guiverc, kc2bez, teward, wxl: https://notes.lubuntu.me/NG3kwx2QQ0CN5K73Vbkbzg?edit take a look and see what you think
[18:15] <arraybolt3> (intentionally pinging the whole Council since this is somewhat of a major UX decision that I think we should all be involved in)
[19:19] <arraybolt3> pondering the above, I feel like perhaps it's a bit too complicated.
[19:28] <arraybolt3> alright, much simpler plan up at the top of that doc.
[19:30] <tsimonq2> arraybolt3: I do believe we're overdue for an upgrade from CodiMD to HedgeDoc.
[19:31] <arraybolt3> heheh
[19:35] <arraybolt3> tsimonq2: you know IRC is right here, we don't *have* to chat in notes scattered all over the doc :P
[19:35] <arraybolt3> though it is cool to watch you type
[19:35] <tsimonq2> bahahahaha
[19:35] <arraybolt3> https://xkcd.com/1810/
[19:36] <tsimonq2> Honestly, the long-term vision for this is to actually have some kind of simple, dedicated Lubuntu Settings menu. Something really simple to enable Backports, provide release information, etc. So I think this could be a great addition to that task. "Enable upgrades to devel" or something more user-friendly than that.
[19:36] <arraybolt3> agreed, that makes sense to me
[19:37] <arraybolt3> right now the "main window" is really just the update installer. So eventually we'll refactor this into a main "control panel" or some such... although, sigh, we're risking an awful lot of overlap with software-properties-qt
[19:37] <tsimonq2> I was just about to say the same exact thing :)
[19:37] <arraybolt3> is that... optional? Like could we gut that out of Lubuntu and everything still work?
[19:37] <arraybolt3> It's pretty much on life support right now.
[19:37] <tsimonq2> Yeah, I'd say so
[19:37] <tsimonq2> Well...
[19:38] <tsimonq2> We still need a GUI story. That being said, the three Qt flavors are the de facto maintainers for that right now.
[19:38] <tsimonq2> It's PyQt5. We could always just rewrite it as a team ;)
[19:38] <tsimonq2> Meh, next cycle or something, that way we can go right to Qt 6...
[19:38] <arraybolt3> right, but it's in main, *and* source tracked in LP.
[19:38] <tsimonq2> For now I think this works
[19:38] <tsimonq2> this is true
[19:38] <arraybolt3> Last time we tried to get a bug fix in that it took like seven years.
[19:38] <tsimonq2> @Eickmeyer knows what I mean. :P
[19:39] <arraybolt3> (maybe only five, but multiple years before anyone fixed it and then like six months or a year before the fix was merged)
[19:39] <tsimonq2> arraybolt3: I'm a Core Developer who's much more active now :P
[19:39] <tsimonq2> I shall not let these pass XD
[19:39] <Eickmeyer> "It's been 84 years...."
[19:39] <tsimonq2> >:P
[19:40] <arraybolt3> Eickmeyer: o_O what, are you fixing a bug in Linux -0.5?
[19:40] <Eickmeyer> 🤦
[19:40] <Eickmeyer> Titanic reference gone missed.
[19:40] <arraybolt3> actually if you go back 84 years I think you're relegated to debugging by literally picking moths out of wiring.
[19:40]  * arraybolt3 never saw that movie
[19:41] <Eickmeyer> Yep, there it is.
[19:41] <arraybolt3> you need to use LOTR references for me to clue in :P
[19:41] <Eickmeyer> I mean, that reference I used is so ubiquitous to pop culture I was nearly sure it would've caught.
[19:43] <arraybolt3> tsimonq2: do you think my "checkpoints" are too aggressive in the plan I linked to?
[19:43] <arraybolt3> We really need the user to do *something* before EOL, but we have to walk a fine line between being helpful and being annoying.
[19:44] <tsimonq2> arraybolt3: That has an "OLD IDEA" prefix on it so I didn't give it more than a glance, I'll be happy to do that now though. ;)
[19:44] <arraybolt3> I meant the "NEW IDEA".
[19:45] <arraybolt3> notice I have 1 year before EOL, 6 months, 1 month, 1 week, etc.
[19:45] <arraybolt3> so the time between reminders keeps getting shorter and shorter until a critical point passes or the user does something.
[19:46] <tsimonq2> okay looking sec :)
[19:46] <arraybolt3> also we need to make sure our popup doesn't look **too** much like an advertisement or we'll scare people into thinking malware has entered the chat :P but hopefully by just making it a notification like the normal update notifications, it will look pretty normal.
[19:46] <tsimonq2> arraybolt3: Think about our support length for another quick second...
[19:47] <arraybolt3> also we should actively avoid wording like "Upgrade Later" or things like that to avoid looking like the infamous Get Windows 10 fiasco.
[19:47] <tsimonq2> arraybolt3: There will be cases in which the next LTS is released less than a year before the existing one goes EOL.
[19:47] <tsimonq2> arraybolt3: I'd cut out one year, do the first notification as soon as the next LTS is out, then continue with the 6 month etc. as you described
[19:48] <arraybolt3> +1
[19:48] <tsimonq2> EOSS... so like, the 5 year mark?
[19:48] <arraybolt3> right
[19:48] <arraybolt3> eoss = end of standard support, that's when the thing is **really** EOL.
[19:49] <tsimonq2> I think the purpose of this is fairly valid. That being said, the reason we do have these warnings is to encourage the user to upgrade. The point at which the nagging should be insistent/every session/every day is once it hits our EOL.
[19:50] <tsimonq2> We could argue for that to be EOSS instead of EOL, that's a discussion worth having.
[19:50] <arraybolt3> another interesting point - if a user upgrades 1 week before EOSS, they'll upgrade to a release that gets updates but that is still EOL. So that could require some fun handling code, possibly.
[19:50] <tsimonq2> bah just diff distro-info-data with meta-release{-lts}
[19:50] <arraybolt3> IMO we would want hyper-nag mode to trigger **before** EOL of stable releases and EOSS of LTS releases.
[19:50] <arraybolt3> Once a user goes EOL/EOSS, upgrades become tricky.
[19:52] <arraybolt3> I'd say not to do daily nags for LTS EOL, since technically the releases are still usable and there are valid reasons for people to continue using them.
[19:52] <arraybolt3> (i.e., my hardware doesn't work with the kernel in the latest LTS quite yet)
[19:53] <tsimonq2> I mean, yes but no. Part of the do-release-upgrade process is to run any and all system updates prior to starting the process. The only hangup you really have is that the archive may be moved. And to be honest, since this LTS will be supported for 12 years on the Canonical side, the archive will exist for about that long. Obviously, you can't hop from e.g. 20.04 to 24.04, but you can just hop 
[19:53] <tsimonq2> LTSes until you're good, or reinstall as you suggested.
[19:53] <tsimonq2> You are right, we should have a "stop nagging me" option.
[19:53] <tsimonq2> They should just have to be intentional about it. If you think about a user, they love clicking "Never" buttons.
[19:53] <arraybolt3> they don't move the LTS archive until after 10/12 years?
[19:53] <tsimonq2> yep
[19:53] <arraybolt3> https://help.ubuntu.com/community/EOLUpgrades has moving to old-releases in there
[19:53] <arraybolt3> so that's surprising to me
[19:54] <tsimonq2> http://us.archive.ubuntu.com/ubuntu/dists/ remember Trusty? I do ;)
[19:54] <arraybolt3> huh, cool
[19:54]  * arraybolt3 used Trusty for long and far, that was actually my first distro
[19:54] <tsimonq2> same :)
[19:54] <arraybolt3> Xenial too. So yeah, you're right.
[19:55] <tsimonq2> Here's the other thing... we still have our old LXDE ISOs up :/
[19:55] <arraybolt3> I'd still prefer to start the nags before, but that makes sense to me.
 Stop making me feel old ;)
[19:55] <arraybolt3> tsimonq2: not anywhere public, I know from experience
[19:55] <arraybolt3> I had to dig them out of Archive.org last time I needed one to test something.
[19:55] <tsimonq2> arraybolt3: So, then what's this? https://cdimage.ubuntu.com/lubuntu/releases/18.04.5/release/
[19:56] <tsimonq2> ;)
[19:56] <arraybolt3> interesting, wonder why that didn't work for me back... oh, I know why
[19:56] <arraybolt3> I was trying to get an interim release
[19:56] <arraybolt3> sigh, I really with Ubuntu would make their private archives of cdimage.ubuntu.com public, there are some good gems in there.
[19:56] <arraybolt3> (like Kubuntu 14.04)
[19:56] <arraybolt3> anyway
[19:56] <arraybolt3> s/Ubuntu/Canonical/
[19:57] <tsimonq2> So, looks like we have two Lubuntu Council votes for tsimonq2 wxl @kc2bez @teward001 @guiverc:
[19:58] <tsimonq2>  1) ACK/NACK on general direction of https://notes.lubuntu.me/NG3kwx2QQ0CN5K73Vbkbzg?edit# - advice/consent.
[19:58] <tsimonq2>  2) https://cdimage.ubuntu.com/lubuntu/releases/18.04.5/release/ removal of these images from cdimage
 I didn't read the whole thing. The "new idea" seems like a good plan.
 Ack
 spam much, @tsimonq2?
[20:14] <tsimonq2> spam not enough if you're not responding XD
[20:14] <tsimonq2> jk sorry if I'm bugging you today
[20:17] <arraybolt3>  /me considers sending the word "spam" 300 times and then decides not to for fear of Libera's autokill bot
 tsimonq2: i'm at the office today working in the server room with my phone just buzzing in my back pocket giving me annoyance.
 so i mean
 *slaps tsimonq2 upside the head with a rotten fish*
[21:15] <tsimonq2> https://launchpad.net/ubuntu/+source/apparmor/4.0.0~alpha2-0ubuntu8
 https://matterbridge.lubuntu.me/1091d959/file_10386.jpg
[21:29] <arraybolt3> tsimonq2: I think you need to set your laptop down a bit more softly from now on.
[21:29] <tsimonq2> XD
[21:29] <arraybolt3> seriously though, what kind of bizarre buffer overflow have you triggered :P
[21:30] <tsimonq2> pfft I have no idea XD
[21:31] <Eickmeyer> 😶
 Simon has managed to hack the Source Code of the Matrix xD
[22:44] <tsimonq2> arraybolt3: I have an LC answer, roughly, on direction for you...
[22:45] <tsimonq2> arraybolt3: New idea is ACK, but we have to have a way to suppress it, or we'll get pitchforks.
[22:45] <tsimonq2> arraybolt3: I would suggest having that "don't remind me again" button but hide it behind a VERY LARGE dialog box saying "whelp, you're on your own if you're sure about this"
[22:46] <tsimonq2> @kc2bez, @teward001: Did I summarize correctly? ^^^^^
[22:46] <tsimonq2> https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2038958 testing Lunar now
[22:46] -ubottu:#lubuntu-devel- Launchpad bug 2038958 in lubuntu-update-notifier (Ubuntu Mantic) "[SRU] Add support for release upgrading" [Medium, Fix Committed]
[22:47] <arraybolt3> tsimonq2: how big of a dialog box? Like should it require something akin to Github's triple confirmation when deleting a repository?
[22:48] <arraybolt3> (tl;dr: when you go to delete a repo in GH, first you click the button. It gives you a popup with a second delete button. Clicking that button says "Unexpected bad things will happen if you don't read this!" and gives you some warnings and yet another delete button. Clicking that one says "To delete this repository, type Username/reponame." Typing what it tells you do will enable yet another
[22:48] <arraybolt3> delete button, and only clicking that fourth button will actually delete the repo - and then it might ask you for your 2FA key too.)
[22:50] <tsimonq2> arraybolt3: I think it should be noticeable enough that the user should be sure of what they're doing, but not as bad as Microsoft, if you catch my drift.
[22:50] <arraybolt3> kk
[22:50]  * tsimonq2 has flashbacks of Windows 10 popping up random alerts and locking random things because of the lack of a Microsoft account...
[22:51]  * tsimonq2 also brings the Ubuntu Pro situation re: advertising forward for arraybolt3's consideration
[22:52] <arraybolt3> good points
[22:52] <tsimonq2> <3
[22:54] <arraybolt3> !ping
[22:55] <arraybolt3> (network check)
[22:55] <tsimonq2> arraybolt3: if it was anyone else I'd say PM ubottu ;P
[22:55] <arraybolt3> +1