Mailinglist Archive: yast-devel (62 mails)

< Previous Next >
Re: [yast-devel] Ideas for YaST Hackweek project
  • From: Ancor Gonzalez Sosa <ancor@xxxxxxx>
  • Date: Tue, 12 Nov 2013 19:03:38 +0100
  • Message-id: <>
On 11/04/2013 11:09 AM, Josef Reidinger wrote:
On Mon, 04 Nov 2013 09:45:04 +0100
Ancor Gonzalez Sosa <ancor@xxxxxxx> wrote:

As some of you may be aware of, openSUSE Team members were not able to
take part in the last Hackweek because we were working in the 13.1
release. It has been decided that we will have our own Hackweek the
last week of November. I would really like to do something related to
YaST, so this is a call for ideas for my YaST related Hackweek

I have more than 10 years of experience with Ruby. I started using it
for developing management applications with QtRuby3. At some point I
started using Rails and since then I have become more and more a web
developer. YaST looks like the perfect choice for my Hackweek: I can
do what I do best (coding Ruby) staying away from Rails, CSS, etc.

So, is there something that needs to be done, that fits in one week
and that requires some Ruby knowledge and not so much knowledge about
YaST internals/legacy?


Hi ancor,
we are really glad that you want to hack on YaST. From your
requirements it is not so easy to decide exact part as whole yast
codebase is automatic transpiled, so it contain some tricky parts to
not loose any functionality. Few ideas I have in mind where your
experiences would really help:

- write really nice example rspec test suite on real module. Members of
YaST team already try it, but noone have so big ruby experience and
it would be nice to compare it.

- Look at libyui and its attempts for ruby bindings [1,2] and move it
forward, because current way where it goes to Yast terms and then to
libyui is not much nice. Or you can propose any other reasonable API
for creating UI for all supported GUI/TUI ( gtk, qt, ncurses ).

- Improve access system. Currently we use SCR[3] with its agents which
seems little outdated when you compare it with other solutions. You
can improve current one or propose new API which make sense and we
can implement various backends for it ( current agents for some
tasks, augeas for others, etc. )

All those ideas about improving bindings, testing are APIs looks perfect
for a second stage, once I have become familiar with YaST development.
I'm really willing to help in those areas, but first I need a more
"introductory" Hackweek project. Proposing the right approach without
having experience with the problem sounds too ambitious to me.

- Take simple module and make it nice module that looks like real ruby
that is intuitive for ruby programmer. I recommend to choose module
that is not so hard or where you know how to setup given component,
so you understand what happen here.

I have a reasonable knowledge and some interest in sound systems, Samba,
Linux containers and databases. Is any of those areas looking for some
more love?

- Alternative is that you can choose part of configuration that is not
yet covered by yast and write new module that looks like real ruby
and report any obstacle you have ( we try to improve documentation,
make some shortcuts or facades, but there is still lot of work ).

- As I write above you cna also improve documentation, try to fix the
most annoying bugs, etc. but it usually require some problem
specific knowledge

If you choose any idea or have your own, do not hesitate to contact us
here or on IRC freenode#yast. It would be also nice if you can write at
the end report what obstacles you see as contributor, so we can try to
remove it.

Yes, of course. That would be one of the main goals, in fact.


Ancor González Sosa
openSUSE Team at SUSE Linux GmbH

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >