Hi,
we have now ruby and it brings a lot of features for free. I want to
write example refactoring and new skeleton for new module. And I would
like to discuss here what we should use. I think that now is good
time, because before conversion we are forced to write it itself, but
now we can choose from existing solution that is already implemented in
ruby.

1) for skeleton I think that skeleton should be as small as possible,
so move all repeating code to own method provided by a module (that is
nice feature of rails, you can start really quickly ). And I think we
should make clear difference between leaf module and module that can be
reused by other modules. Because often there are Yast modules that have
modules, but they use it themself exclusivelly. For such case now should
be "lib" directory where is private Yast module code such us specific
configuration logic or module specific dialogs. Advantage of such step
is that you need not care about backward compatibility, as there is no
public API and we can use all ruby features.

2) When module need to provide API for other modules ( so API should
be based on requirements from other modules ) it should follow simple
ruby
- "Tell, don't ask" [1]. That helps with reducing of data leaks often
seen in Yast ( when you change a map structure, you have problem
because some modules depends on exact map structure ). The second
nice benefit is that API will be easy to go via component system as
there is almost no data flow.

3) No includes. Includes is relict from ycp and it should be moved to
lib as common ruby class or modules. ( perl and python also doesn't
have it )

4) Exceptions. Ruby language provide us exceptions that can really
simplify method code-flow. If there is error and it is reported by
return value, then you need to explicitelly check it and go up if
needed. Exception allow to handle it when you need it and if you don't
handle it, then quickly recognize it[1b]. Current solution is that
ruby-bindings catch exceptions when exception is catch between
languages when calling modules ( so if both modules are in ruby, then it
is passed ) and when use WFM::Call ( in case of exception, it is
catched and return nil ).

5) testing framework. We definitively need new one, old one is really
horrible to use and fragile. Ruby provide a lot of nice test
frameworks, the well known are Test:Unit[2] ( classical test unit
framework with asserts ) and RSpec that is designed to fit nice for TDD
[3]. I personally use for a long time Test:Unit and try RSpec few
months ago and I really like RSpec, especially how tests looks like and
how nice is its output.

6) Documentation. For code documentation we translate comments to
YARD[4]. But there is also documentation that sits around in docbook
format. I found quite hard to write new parts of documentation and keep
it up-to-date. I found tool that can convert docbook to textual based
markdown format[5]. And I also thing that documentation should be
together with code and also examples should live with code. YARD
support it in quite nice way (support inlined markdown). See e.g.
documentation of ActiveRecord::Base which lives together code and how
it can look like [6].

7) Continuous integration. We found that our jenkings node how few
drawbacks, so we should also improve it. Lslezak have nice proposal how
to simplify it. We can just package new commit and and call `osc build`
and if it succeeds then submit new package to YaST:Head. Also if we
improve our testing we can use e.g. travis and integrate it to test all
of our pull request if it breaks test [7]. If we improve it, we can
then verify also our maintenance branches and we can share load between
more runners and dependency is mainly osc and what we need to package
sources.

8) build program. YaST currently use autotools. It has few drawbacks -
it is written in different language then rest of plugins ( M4 versus
ruby now ), not so popular today ( so less people understand it,
especially in ruby community ) and not so easy to share functionality
( currently we use Makefile.am.common and other tricks ). Common ruby
build tool is Rake[8], question is if we want use it.

[1] http://pragprog.com/articles/tell-dont-ask
[1b] http://nedbatchelder.com/text/exceptions-vs-status.html
[2]
http://www.ruby-doc.org/stdlib-2.0/libdoc/test/unit/rdoc/Test/Unit/Assertions.html
[3] http://rspec.info/
[4] http://yardoc.org/
[5] http://daringfireball.net/projects/markdown/syntax
[6] http://api.rubyonrails.org/classes/ActiveRecord/Base.html
[7]
http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more-awesome/
[8] http://rake.rubyforge.org/