On 11/04/2013 11:09 AM, Josef Reidinger wrote: > On Mon, 04 Nov 2013 09:45:04 +0100 > Ancor Gonzalez Sosa <[email protected]> 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 >> project. >> >> 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? >> >> Cheers >> > 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. Cheers. -- Ancor González Sosa openSUSE Team at SUSE Linux GmbH -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
