Mailinglist Archive: yast-devel (80 mails)

< Previous Next >
[yast-devel] yast++ minutes -- 2012-02-13
below you find minutes of the meeting from this monday.



Jiri Srain, Lukas Ocilka, Martin Vidner, Josef Reidinger, Jiri Suchomel, Vladimir Moravec

Vladimir Moravec


1. Packaging
2. File structure
3. Name
4. Portability
5. Play & test out of the Git
6. GSoC
7. Logging
8. What's next

1. Packaging

Main idea
+ how to distribute the code

+ gem directory structure if gem
+ check of local system dependencies
+ native extensions
+ stay with current rpm building and lets make it available for other distros via buildservice

2. File structure
+ use of gem directory structure conventions

3. Name of the lib

Main idea
+ to use or not to use 'yast' as a part of the name

+ established name and community, descendant of Yast
+ well known and easy to distinguish from others

+ not suitable if we target multiple distros
+ hard to find on google
+ hard to distinguish the name from yast
+ has association with 'suse only'
+ possible problem in the mind, with trademarked work 'yast'
+ makes impression that it is successor of YaST, but it is actually
only extraction of part of YaST ( data processing )

+ What are the criteria for the name?

Suggestions for the name
+ ylib
+ anything with 'y' letter
+ liby
+ libyast

+ use yast++ name as before in the meantime
+ change is however expected in the course of further development

4. Portability

Main idea
+ make the lib available & popular for non-suse developers

What are the means to achieve this
+ distro specific config / package script calls
+ other distros to be considered: Fedora, Debian, Ubuntu

Random ideas
+ what changes are needed to include other distros as target systems
+ focus on other distros not from the beginning, only later after some point
in development has been reached
+ focus from the early stage on development; past experience shows this as reasonable
+ talk/blog about the lib development in the public to make it aware of the project existence
+ show simple examples for using on other distros
+ currently no check for running distro
+ autodetection as the best way
+ use of plugins would be fine
+ distro autodetection, e.g. `cat /proc/version`

+ too wide scope for beginning of such project (too many specifications,
different needs for various distros)
+ too much work for small team -> rather focus on making happy well known users
(studio,webyast), then use resources for others
+ imaginary users of debian/fedora as a too blury concept for the expected change
+ we need a proof of concept that it might run on different distros anyway

+ should the portability the a feature of the lib?
+ is the multi-distro focus meaningful?
+ would it be possible running it on Fedora at all?
+ What is needed to make the development focused on more distros?
+ where to implement the distro-specific configuration
+ how to avoid forking the lib from others and keep devs in one place =>
avoid splitting the community

+ ylib as ideal level for customizing configuration of the lib for this

5. Play & test out of Github

Main idea
+ make the lib developer friendly from the first touch

How to achieve this
+ directory with example files
+ using chroot for not breaking the running system (root needed)
+ scripts for chrooting available
+ alternatives for chroot:
+ good tutorial for developers
+ make appliances available

Random ideas
+ devel-pattern for rpm packaging
+ appliances of other distros to play with the code
+ `git clone` into the pre-build VM
+ project on OBS / install from here
+ ensure modifying the local system (remounting)
+ using testing data (from testsuite) for development

+ how skilled is the developer who is going to use the lib?
+ how make the repo available for playing for other distros' developers

+ look on other projects how they solve the system configuration change

6. GSoC

Main ideas
+ portability feature
+ C binding for Python
+ support of Openstack => not needed currently
+ get in touch with Michal Hrusecky (GSoC/openSUSE wiki)

7. Logging

Main ideas
+ full logging in/out
+ filter passwords => results in slower performance
+ dry run
- diffs in chroot
- scripts
+ conventions for parameters
+ use of the test-suite to avoid wrong using of scripts
+ create/support official API
+ undef methods to block improper use of the lib

8. What's next?

+ finish one or several modules and show the use case:
+ port it to to other distros
+ use it in the webyast

Vladimir Moravec
Appliances Department
SUSE LINUX s.r.o., Praha

< Previous Next >