# * [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) |
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:
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:
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?
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.
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:
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
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.
Type
column
New Columns Type
and Fs Type
will be merged into a new Type
column on steroids:
- Blk Device without fs: