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