Re: Reconsidering Ubuntu bug-filing redirection
On Mon, Oct 14, 2019 at 12:13:30PM +0100, Colin Watson wrote: > About ten years ago [1] [2], Launchpad was changed so that, if people > try to file a bug on Ubuntu directly via the web, then they're instead > redirected to https://help.ubuntu.com/community/ReportingBugs which > explains how to file a bug using the appropriate tools. Some way down, > this explains how to file bugs manually and bypass this redirection. > > At the time, this change was described as an experiment. I think it's > worth having a look at this and seeing if we can tweak it to reduce some > sources of frustration. > > I think we could consider other approaches in the Launchpad UI to give > people a nudge towards good local bug-reporting tools while being > slightly less user-hostile to people who know what they're doing about > bugs in general but not about Ubuntu's processes. I have two specific > independent ideas that I'd like to submit for consideration: > > * Rearrange the UX for reporting bugs on Ubuntu as a non-member of >~ubuntu-bugcontrol so that it presents the reference to ReportingBugs >and the advice to use ubuntu-bug in a way that's hard to ignore but >that can still be skipped. Back in 2010 there was some discussion on this issue, and Deryck Hodge had a proposal to make the UX follow a "Your bug is X% complete" style, maybe conceptually similar to this suggestion, which was captured as a "Bugs Q" story: https://dev.launchpad.net/Bugs/BugQ%26A Fairly rough concept there, but apparently was included for the LP 4.0 roadmap (https://dev.launchpad.net/VersionFourDotO/Stories). Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Supporting LZ4 as initramfs compressor
On Tue, Oct 15, 2019 at 05:18:47PM +0100, Dimitri John Ledkov wrote: > On Tue, 15 Oct 2019 at 11:13, Dimitri John Ledkov wrote: > > > > On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov wrote: > > > > > > On Wed, 5 Jun 2019 at 19:59, Steve Langasek > > > wrote: > > > > > > > > Hi Dimitri, > > > > > > > > One point here: > > > > > > > > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote: > > > > > - lz4 size weight over gzip is marginal (14%) but imho worth the > > > > > improved boot time & initrd creation time > > > > > > > > A 14% increase in initramfs size is NOT marginal. Since there are (and > > > > will > > > > always be) various scenarios which require a separate /boot partition, > > > > we > > > > have over several cycles been contending with how to ensure a clean > > > > upgrade > > > > as kernel+initramfs sizes increase over time and push up against the > > > > space > > > > limits of the boot partitions that have historically been created. > > > > > > > > If you are making a change that increases the size of initramfses by 14% > > > > across the board, you must also: > > > > > > > > - update the ubuntu-release-upgrader code to take this into account so > > > >users don't run out of space in the middle of the upgrade > > > >- possibly in a way that is smart enough to know if a user is already > > > > configuring initramfs-tools to use a non-default compressor, to > > > > avoid > > > > false-positives > > > > - check that the minimum size requirements for /boot that are encoded > > > > in > > > >the installers are still adequate, or if they need updating (and if > > > > they > > > >need updating, update this back to 18.04) > > > > - document this issue in the release notes > > > > > > > ubuntu-release-upgrader is dynamically calculated, but I have now > > proposed to bump/update the fallback guestimate. > > > > did the calculation of new size requirements, and /boot sizes are > > still well enough (up to 10 kernels) > > > > release notes updated > > > > The Cking recent lz4 measurements tests are documented in the > description of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934 And also in comment #5 of that same bug. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934/comments/5 -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Supporting LZ4 as initramfs compressor
On Tue, 15 Oct 2019 at 11:13, Dimitri John Ledkov wrote: > > On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov wrote: > > > > On Wed, 5 Jun 2019 at 19:59, Steve Langasek > > wrote: > > > > > > Hi Dimitri, > > > > > > One point here: > > > > > > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote: > > > > - lz4 size weight over gzip is marginal (14%) but imho worth the > > > > improved boot time & initrd creation time > > > > > > A 14% increase in initramfs size is NOT marginal. Since there are (and > > > will > > > always be) various scenarios which require a separate /boot partition, we > > > have over several cycles been contending with how to ensure a clean > > > upgrade > > > as kernel+initramfs sizes increase over time and push up against the space > > > limits of the boot partitions that have historically been created. > > > > > > If you are making a change that increases the size of initramfses by 14% > > > across the board, you must also: > > > > > > - update the ubuntu-release-upgrader code to take this into account so > > >users don't run out of space in the middle of the upgrade > > >- possibly in a way that is smart enough to know if a user is already > > > configuring initramfs-tools to use a non-default compressor, to avoid > > > false-positives > > > - check that the minimum size requirements for /boot that are encoded in > > >the installers are still adequate, or if they need updating (and if > > > they > > >need updating, update this back to 18.04) > > > - document this issue in the release notes > > > > ubuntu-release-upgrader is dynamically calculated, but I have now > proposed to bump/update the fallback guestimate. > > did the calculation of new size requirements, and /boot sizes are > still well enough (up to 10 kernels) > > release notes updated > The Cking recent lz4 measurements tests are documented in the description of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934 -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Supporting LZ4 as initramfs compressor
On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov wrote: > > On Wed, 5 Jun 2019 at 19:59, Steve Langasek wrote: > > > > Hi Dimitri, > > > > One point here: > > > > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote: > > > - lz4 size weight over gzip is marginal (14%) but imho worth the > > > improved boot time & initrd creation time > > > > A 14% increase in initramfs size is NOT marginal. Since there are (and will > > always be) various scenarios which require a separate /boot partition, we > > have over several cycles been contending with how to ensure a clean upgrade > > as kernel+initramfs sizes increase over time and push up against the space > > limits of the boot partitions that have historically been created. > > > > If you are making a change that increases the size of initramfses by 14% > > across the board, you must also: > > > > - update the ubuntu-release-upgrader code to take this into account so > >users don't run out of space in the middle of the upgrade > >- possibly in a way that is smart enough to know if a user is already > > configuring initramfs-tools to use a non-default compressor, to avoid > > false-positives > > - check that the minimum size requirements for /boot that are encoded in > >the installers are still adequate, or if they need updating (and if they > >need updating, update this back to 18.04) > > - document this issue in the release notes > ubuntu-release-upgrader is dynamically calculated, but I have now proposed to bump/update the fallback guestimate. did the calculation of new size requirements, and /boot sizes are still well enough (up to 10 kernels) release notes updated -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
