I realised when creating the blueprints that there was perhaps room for further discussion. :-)
On 05/17/2017 12:38 AM, eylul wrote: > Ross, > > Thanks so much, for doing this. I am adding some comments here in this > email. I can also reflect changes to the blueprints accordingly, but > posting them here first, in case there is anything else that needs to be > discussed before changing. I hope this helps. :) > > Best > > Eylul > > ------ > > 1) > https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/auto-mounting-a > > This looks mostly good to me. My original comment was that it is more > intuitive for non-audio users to auto-mount but that if this causes > errors for the audio users (rather than a minor inconvenience or extra > step) then we should remove it. > > I also mentioned ability to turn auto-mount on and off easily would be a > good addition to ubuntustudio-controls. which could be its own blueprint > if we accept it, or added to the -controls blueprint. > Common for most of the blueprints was a possible need to provide an on/off toggle in -controls. I think it is OK that the -controls work is scattered across different blueprints (but then I am new to creating these things, so I am blissfully unaware of any future complications :-) ). > 2) > https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/auto-updating-a > This needs revision. > > Disabling auto-updates should NEVER be the default, period. It would > leave users system vulnerable to attacks. Fair enough (considering there are other use cases for US than audio work). > > Users can turn off the auto-updates if they want to.(Go to > "software&Updates" -> "Updates". You can change how often the system > checks for updates, it currently only downloads and installs > automatically security updates, and displays the rest.) Advanced users > can make that choice. It is not ours to make. It would be nice to have a -controls option though. Because it is really frustrating when I have my first chance for a music studio session for ages, and I have to wait for the last months updates to be checked, before I can click "later", and get on with some jamming. In my old Windows XP days, I had the updates completely disabled, and manually checked for them when I had time. The Windows updates were more disruptive though - always wanting a reboot. It could also fall to the documentation team as well, or even the classic "10 things to do for audio work after you install Ubuntu Studio" blog. > > The issue is the leftover kernels, and how to clean them. (so the > blueprint should probably reflect that, rather than being about > auto-updating) > > Len asked me before what is my current efi is looking like: my /boot/efi > section is currently using 29mb out of a much bigger area. I cannot look > inside at the moment (I need to look up how to do that) > > I recently ran autoremove through. It looked like it was removing some > of the old kernels. (I am not sure if running autoremove risks breaking > the system by accidentally deleting another package, assuming this works). I normally leave the old kernels there for a while before autoremoving them, just in case there is some incompatibility and I want to go back to them. But eventually you need to, or apt-get starts to have trouble working out what to do, and gets slow at updating the grub menu. > Either way never ran into any issue related to this nor did I hear > anyone ever having any problem with this. So my suggestion is to really > let this be. (unless we happen to stumble upon an elegant solution to > remove them) > > Either way, not everybody who uses this distro are developers or very > experienced users. So pllease no disabling auto-updates for security > updates, that is a VERY bad idea. Well - I prefer to check what the updates are before installing them. Sometimes, they can be quite disruptive (e.g. temporarily disabling something). It might be better to pull the internet cable out instead ;-) > > 3) > https://blueprints.launchpad.net/ubuntustudio-dev-tools/+spec/package-tracker-a > No problems that I can see (does this also mean we are moving our > package versioning system to git, or is that separate?) > There is a general move towards git in launchpad, but this is not ready yet. Some new tools that we design that we don't intend to package (at least yet), are already placed in a git repo (well actually only one): https://code.launchpad.net/~ubuntustudio-dev/+git If there was a unanimous preference, we could move all of what we have (that is alive) in bzr over there, but I would wait until there is a bit more general momentum in that direction in Launchpad. > 4) > https://blueprints.launchpad.net/ubuntustudio-controls/+spec/improve-controls-a > This looks like what Len recommended we do before, but then again, not > my expertise area. > > > 5) https://blueprints.launchpad.net/ubuntustudio-look/+spec/new-wallpaper-a > This looks good to me. I volunteered for doing this (unless somebody > desperately wants to) > Original discussion was to have these ready for 18.04, but I can adjust > to have them ready > by 17.10. Just let me know which deadline I am working toward and I'll > make it. Well - Lens recommendation to avoid the rush for 18.04 and start now, which seems like a good idea. We have a bit of a bad record recently for getting things done (on time) :-) But 1804 is the real deadline. > > 6) > https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/change-default-theme > This looks good to me. > > In terms of HiDPI, we can add a separate blueprint about reviewing other > problems encountered in HiDPI. (in preparation for solving them by 18.04 > latest) > > the discussion earlier was a more long term issue review: > - Lack of scaling on OS level by application means many programs are > nearly unusuable. (old GTK2 software that is not maintained, and > anything java > based being the biggest problems right now - and no avoiding them is not > a viable option at the moment :) ) > - GTK3 has better support for HiDPI > - GTK2 has SOME support for HiDPI (and ardour is not switching to GTK3) > > All I can think in terms of actionable items is that > > a) we should probably use GTK3 for any new code we write/maintain as > UbuntuStudio > b) keep an eye on ardour and any other software that uses GTK2 to file > bugs if they are well maintained, or find replacements. > > Anything beyond that is probably out of the scope of what we can do. > > -------- Good idea - I nearly created a separate blueprint - but I wouldn't have been able to summarise the problem and actions so succinctly :-) Thanks for the feedback. If there is no further feedback, we should just continue finalising them, and then someone for the core team can approve them. [snip] -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel