joseivanlopez

Layouts

Mode: LeftTitle, Banner: Yes

Mode: LeftTitle, Banner: No

joseivanlopez

# * [ok] Allow to select more than one item.
# * [ok] Multi state: no selected, selected, auto selected.
# * [ok] Enable/disable items.
# * [ok] Event over item title.
# * [ok] Automatic text wrapping.
# * [No] Auto-focus to the selected item.
# * [No] Event when moving with arrow up/down.

class MultiStateSelectionBox < CWM::RichText
  def item(id)

joseivanlopez

Problem

SUSE Linux is moving from using single configuration files to using multiple files. Moreover, some typical configuration files placed at /etc are being moved to /usr/etc, see https://github.com/thkukuk/atomic-updates_and_etc/.

All those changes could make YaST fails. For example, when a YaST module tries to reads/writes a file from /etc but that file is not there anymore.

The main problem for the YaST team is that nobody is noticing in advance when a package configured by YaST changes the location of its configuration files. Simply a new bug is reported to YaST when a YaST module fails because that. This approach would not be a big deal if all that kind of errors are detected by openQA, but we cannot ensure that is the case. Therefore, YaST needs an early defense barrier in order to prevent bug reports from final users as much as possible.

To fix this issue we would need:

joseivanlopez

Goal

The goal is to be able to add unit-test for snapper CLI commands. For example, check that user-given parameters are right, check that correct libsnapper calls are performed (e.g., a call for creating a snapshot would be perfomed), and check that commands returns expected output (e.g., with csv format, etc).

How to do it

To support unit-test we need to prepare the code for that. And we can do it at different layers. Very roughly, we can see these layers in the snapper code:

joseivanlopez

Vision

• We cant to stay relevant
• We want to be useful
• We want to make things simple for our customers

Current status

• Is YaST relevant yet? Why?
• Nowadays, what is YaST most useful for?

joseivanlopez

Team Charter Template

Team Purpose (Mission)

A statement describing the reason that the team was created.

The YaST team was created to develop and maintain YaST2, the installation and configuration tool of openSUSE and the SUSE Linux Enterprise distributions.

joseivanlopez

A Team Charter Template is proposed here to help YaST team members to define the team chapter. Please, feel free to add/remove/modify the points in this team charter if you consider it.

Why a Team Charter

That is the first question everyone of us make to ourselves. But there are some good reasons to have one:

joseivanlopez

MD

• no dasds, bios raids, mds, strays, encryptions, bcaches, lvs

• disks, multipaths

  • no partitions
  • not in vg, md, multipath, bcache, cset [+ btrfs]
  • not formatted
  • not mounted

joseivanlopez

Partitioner with multidevice BTRFS

• Show multidevice BTRFS in the general list of devices.
• Mount point and label is empty for the devices belonging to a multidevice BTRFS.

New Type column

Columns Type and Fs Type will be merged into a new Type column on steroids:

• Blk Device without fs:

joseivanlopez

New icons