Mailinglist Archive: yast-devel (80 mails)

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



yast++
====
https://github.com/yast/yast--

Date:
-----
13-02-2012

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

Minutes
---------
Vladimir Moravec



ToC:
=======

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

Proposals
----------
+ 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

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

Cons
----
+ 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 )

Questions
---------
+ What are the criteria for the name?

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

Results
-------
+ 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`

Discussion
--------
+ 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

Questions
---------
+ 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

Suggestions
-----------
+ 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

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

Proposals
---------
+ 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 >