[ubuntu-studio-devel] Next cycle

[Ross Gammon]

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]