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