[yast-devel] Changing the Attitude to Coding YaST
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yasties, Developers and Friends, According to the feedback I've got recently and what I've been feeling for a longer time, there is a chance to make YaST development cleaner, simpler and more enjoyable just with little tricks learned from the other projects we've been working on recently. Here you can see a list of unsorted ideas that came into my mind thinking about the other project and reusing experience with them in the YaST development: Code Reusability - - Usually the code is written for one purpose, but maybe we should start thinking before the development: Isn't the code reusable from anywhere else? Can the code be more generic? Think about CWM. - - Additionally, a lot of the code is in "include"d files or even in "client"s which makes the code almost impossible to be tested. That's also why we get syntax and/or runtime errors. - - Fix|Easy: Develop code in reusable libraries and write simple and understandable tests. Testing - - Connected to the previous point. Most of the current code is not tested because it actually cannot be tested. - - On the other hand, sometimes we think that writing testsuites is for dummies. But untested code causes bugs that need to be fixed later and thus is doesn't save the time at all. - - Fix|Medium: Write tests, make sure they are called during build. Coding Standards - - The code should be not only understandable to ourselves but also to the others. Using the same coding standards make it easier to understand the code structure, parameters, expected return value and so long. - - Examples: * Package::IsValid(package) -> returns boolean (maybe only Valid()) * Package::Install(package) -> do you need to read any documentation? * Using hashes with parameters instead of twelve parameters, eight of them optional * Indentation * No more "include"s if not necessary * Useful comments * Useful documentation of all the public functions * ... other ideas? ... - - Fix|Medium: Define the standards and use them (let's learn from other projects) Cooperation - - When the code has tests and it's mostly in compiled libraries, it's quite easy for more developers to work on the same project in the same time. The only thing they need to define is the API and using the same standards they can understand the API almost instantly. - - Better cooperation is usually useful when someone needs help from the others: too many features and bugs and to few time. - - Fix|Depends: ... Code Reviews - - In the SLMS team, we've found out that all the commits should be reviewed by someone else. This helps to identify potential issues in time. All the commits are public anyway. - - Fix|Easy to Medium: Either someone is always assigned to review everyone's code (takes too much time) or developers usually check code of someone else only. Shared Task List - - There are often even smaller tasks that need to be done by anyone in the team but they don't have their priority high enough (so called easy-hacks) - and that's why we forget them quite easily. - - Fix|Easy to Medium: Use some of the task managers, e.g., http://www.producteev.com/ anyone can pick a task and try to implement / fix it. I believe that you have other ideas how to improve the development - how to make the development and maintenance easier for you and/or the others. Or you maybe have an opinion on the ideas I just presented. Share them with us, please! :) Thanks in advance and Bye Lukas - -- Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o. MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFN73YzVSqMdRCqTiwRAuC2AJsFP391iBGZwiJtbFNeN3FdwfZqRACfQqZZ xvmYF1Ar/q64o1iFMhVImlI= =R8U6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Lukas Ocilka write:
Yasties, Developers and Friends,
According to the feedback I've got recently and what I've been feeling for a longer time, there is a chance to make YaST development cleaner, simpler and more enjoyable just with little tricks learned from the other projects we've been working on recently.
Here you can see a list of unsorted ideas that came into my mind thinking about the other project and reusing experience with them in the YaST development:
Code Reusability - Usually the code is written for one purpose, but maybe we should start thinking before the development: Isn't the code reusable from anywhere else? Can the code be more generic? Think about CWM.
One of my goal for workshop is to introduce well defined api for reusable things in YaST.
- Additionally, a lot of the code is in "include"d files or even in "client"s which makes the code almost impossible to be tested. That's also why we get syntax and/or runtime errors.
Agree, include is pain. Module is better/
- Fix|Easy: Develop code in reusable libraries and write simple and understandable tests.
write simple and understandable tests for ycp is not easy task ;)
Testing - Connected to the previous point. Most of the current code is not tested because it actually cannot be tested. - On the other hand, sometimes we think that writing testsuites is for dummies. But untested code causes bugs that need to be fixed later and thus is doesn't save the time at all. - Fix|Medium: Write tests, make sure they are called during build.
Coding Standards - The code should be not only understandable to ourselves but also to the others. Using the same coding standards make it easier to understand the code structure, parameters, expected return value and so long. - Examples: * Package::IsValid(package) -> returns boolean (maybe only Valid()) * Package::Install(package) -> do you need to read any documentation? * Using hashes with parameters instead of twelve parameters, eight of them optional * Indentation * No more "include"s if not necessary * Useful comments * Useful documentation of all the public functions * ... other ideas? ... - Fix|Medium: Define the standards and use them (let's learn from other projects)
I think we already have some code standards.
Cooperation - When the code has tests and it's mostly in compiled libraries, it's quite easy for more developers to work on the same project in the same time. The only thing they need to define is the API and using the same standards they can understand the API almost instantly. - Better cooperation is usually useful when someone needs help from the others: too many features and bugs and to few time. - Fix|Depends: ...
One of fix is to move to git for easier implementing features for same module and then easy merge it.
Code Reviews - In the SLMS team, we've found out that all the commits should be reviewed by someone else. This helps to identify potential issues in time. All the commits are public anyway.
It helps if commits are reasonable small. If commit is more then 20kB it is hard to review it. and I think that git helps there also, as you can hack in more commits and then sent it in one wave.
- Fix|Easy to Medium: Either someone is always assigned to review everyone's code (takes too much time) or developers usually check code of someone else only.
I think that there should be pairs for module, so second one know module and be backup and also do review.
Shared Task List - There are often even smaller tasks that need to be done by anyone in the team but they don't have their priority high enough (so called easy-hacks) - and that's why we forget them quite easily. - Fix|Easy to Medium: Use some of the task managers, e.g., http://www.producteev.com/ anyone can pick a task and try to implement / fix it.
No, no new program. Just create account in bugzilla, so you can query it for easy (low priority) tasks. This also helps team members who has more then 100 bugs to organize it.
I believe that you have other ideas how to improve the development - how to make the development and maintenance easier for you and/or the others. Or you maybe have an opinion on the ideas I just presented. Share them with us, please! :)
I have prepared something which I want introduce and discuss on workshop. But I think that we should at first try small prototype in real work if it is useful or just nice theory. Of course the biggest idea is to focus on what we do best ( high level configuration ) and try to "outsource" everything else like own language, parsers, RPC, test framework. Split high level configuration and UI presentation. Pepa
Thanks in advance and Bye Lukas
-- Josef Reidinger Appliance Toolkit team maintaining parts of webyast and SLMS author of rubygems - studio_api and net_observer (coauthor) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jun 08. 2011 16:28]:
- Fix|Easy: Develop code in reusable libraries and write simple and understandable tests.
write simple and understandable tests for ycp is not easy task ;)
How about using testing frameworks available in Perl, Python, Ruby and test the YCP code via the respective bindings ? Of course, this still requires testable code in the first place ... Klaus --- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wed, Jun 08, 2011 at 04:30:56PM +0200, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jun 08. 2011 16:28]:
- Fix|Easy: Develop code in reusable libraries and write simple and understandable tests.
write simple and understandable tests for ycp is not easy task ;)
How about using testing frameworks available in Perl, Python, Ruby and test the YCP code via the respective bindings ?
That makes sense.
Of course, this still requires testable code in the first place ...
That is the hard part. - One thing is (re)writing the code so that mocking and stubbing is possible, - another thing is that it may be necessary to enhance the YCP runtime to allow mocking and stubbing at all - at the moment we can only mock SCR via ag_dummy. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 8.6.2011 16:28, Josef Reidinger napsal(a):
Lukas Ocilka write:
- Fix|Easy: Develop code in reusable libraries and write simple and understandable tests.
write simple and understandable tests for ycp is not easy task ;)
Yes, it's not. But we can start changing the coding style that would make it easier. For instance, imagine you have to implement a new feature in an existent code written in YCP. 1.) Write as much code as possible in a testable way (library) 2.) Write test for the functionality 3.) Make sure the test is called during build
Coding Standards - The code should be not only understandable to ourselves but also to the others. Using the same coding standards make it easier to understand the code structure, parameters, expected return value and so long. I think we already have some code standards.
Yes, we do: http://doc.opensuse.org/projects/YaST/SLES11/codingrules/index.html But does everybody use them? Have you seen, e.g., yast2-network code? (Please don't blame Martin for that)... If developers do not use the current standards, maybe they don't know we have some, or they don't care, or they don't like them. Maybe it's time to fix/change the standards first?
Cooperation - When the code has tests and it's mostly in compiled libraries, it's quite easy for more developers to work on the same project in the same time. The only thing they need to define is the API and using the same standards they can understand the API almost instantly. - Better cooperation is usually useful when someone needs help from the others: too many features and bugs and to few time. - Fix|Depends: ...
One of fix is to move to git for easier implementing features for same module and then easy merge it.
Yes, moving to git would help a lot, IMO.
Code Reviews - In the SLMS team, we've found out that all the commits should be reviewed by someone else. This helps to identify potential issues in time. All the commits are public anyway.
It helps if commits are reasonable small. If commit is more then 20kB it is hard to review it. and I think that git helps there also, as you can hack in more commits and then sent it in one wave.
Sounds like a plan ;)
- Fix|Easy to Medium: Either someone is always assigned to review everyone's code (takes too much time) or developers usually check code of someone else only.
I think that there should be pairs for module, so second one know module and be backup and also do review.
Good idea.
Shared Task List - There are often even smaller tasks that need to be done by anyone in the team but they don't have their priority high enough (so called easy-hacks) - and that's why we forget them quite easily. - Fix|Easy to Medium: Use some of the task managers, e.g., http://www.producteev.com/ anyone can pick a task and try to implement / fix it.
No, no new program. Just create account in bugzilla, so you can query it for easy (low priority) tasks. This also helps team members who has more then 100 bugs to organize it.
Also possible. I use producteev for personal and also company TODOs, it's connected to my HTC and makes my life easier ;) It was just an example...
I believe that you have other ideas how to improve the development - how to make the development and maintenance easier for you and/or the others. Or you maybe have an opinion on the ideas I just presented. Share them with us, please! :)
I have prepared something which I want introduce and discuss on workshop. But I think that we should at first try small prototype in real work if it is useful or just nice theory.
Of course the biggest idea is to focus on what we do best ( high level configuration ) and try to "outsource" everything else like own language, parsers, RPC, test framework. Split high level configuration and UI presentation.
OK, let's invest some time in research in this area. Lukas - -- Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o. MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFN8I6SVSqMdRCqTiwRAnp8AJ93tpjbohkIlzHlqPAdFijq0xaQfgCgiFf6 ULJVFJ3axk3d3IbQtriuWfc= =ie5U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Jun 09, 2011 at 11:12:50AM +0200, Lukas Ocilka wrote:
Dne 8.6.2011 16:28, Josef Reidinger napsal(a):
Lukas Ocilka write:
Shared Task List - There are often even smaller tasks that need to be done by anyone in the team but they don't have their priority high enough (so called easy-hacks) - and that's why we forget them quite easily.
There is an established convention for this already, the Junior Jobs: http://en.opensuse.org/openSUSE:Junior_jobs with a corresponding Bugzilla query: http://tr.im/opensusejj (LibreOffice calls them Easy Hacks: http://wiki.documentfoundation.org/Development/Easy_Hacks ) Please take some time to scan your bug list (or mine ;-) ) and mark some bugs JJ.
- Fix|Easy to Medium: Use some of the task managers, e.g., http://www.producteev.com/ anyone can pick a task and try to implement / fix it.
No, no new program. Just create account in bugzilla, so you can query it for easy (low priority) tasks. This also helps team members who has more then 100 bugs to organize it.
Also possible. I use producteev for personal and also company TODOs, it's connected to my HTC and makes my life easier ;) It was just an example...
Producteev is actually a web service, and I am using it to sync my personal task list to the cloud(*). For 3 and more poeple accessing a task list, it costs $20/month, so if Bugzilla is not enough, I'd look for alternatives *) BUZZWORD!!1! See also http://xkcd.com/908/ -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 9.6.2011 15:51, Martin Vidner napsal(a):
There is an established convention for this already, the Junior Jobs: http://en.opensuse.org/openSUSE:Junior_jobs with a corresponding Bugzilla query: http://tr.im/opensusejj
(LibreOffice calls them Easy Hacks: http://wiki.documentfoundation.org/Development/Easy_Hacks )
Please take some time to scan your bug list (or mine ;-) ) and mark some bugs JJ.
I've found out this is really useful, especially the http://tr.im/opensusejj query. Just prepend your bugs/enhancements with "JJ:" in the summary and that's it. People actually really use it.
Producteev is actually a web service, and I am using it to sync my personal task list to the cloud(*). For 3 and more poeple accessing a task list, it costs $20/month, so if Bugzilla is not enough, I'd look for alternatives
*) BUZZWORD!!1! See also http://xkcd.com/908/
We actually already use another web-based service for that but I found it too complicated. I use Producteev as it works with my HTC and web-browser anywhere else (with google ID), but it's just a helper tool for tasks - if you don't need any helper tool for TODOs, than you're a lucky man :D Bye Lukas - -- Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o. MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFN/wqnVSqMdRCqTiwRAjQKAJ9ERPJKcDPcq/C1bfHSuAUfukq9TQCeJNHT eB3xbFLkkZzC9ylOINsEPFc= =SBQa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
I believe that you have other ideas how to improve the development - how to make the development and maintenance easier for you and/or the others. Or you maybe have an opinion on the ideas I just presented. Share them with us, please! :)
I have a suggestion that would make supporting yast way easier: Yast D E B U G G E R!!!!! Most successful computer languages have debuggers. Why doesn't Yast have one? ---- Roberto Angelino Dedicated Partner Engineer Developer Support (310) 529-3527 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Roberto Angelino <rangelino@novell.com> [Jun 08. 2011 16:53]:
I believe that you have other ideas how to improve the development - how to make the development and maintenance easier for you and/or the others. Or you maybe have an opinion on the ideas I just presented. Share them with us, please! :)
I have a suggestion that would make supporting yast way easier:
Yast D E B U G G E R!!!!!
Most successful computer languages have debuggers. Why doesn't Yast have one?
YaST developers are real hackers, doing debug prints only. SCNR ! Actually, there never was a strong need for a debugger. It was discussed a few times, but never got sufficient traction/priority to get implemented. Klaus --- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Klaus Kaempf write:
* Roberto Angelino <rangelino@novell.com> [Jun 08. 2011 16:53]:
I believe that you have other ideas how to improve the development - how to make the development and maintenance easier for you and/or the others. Or you maybe have an opinion on the ideas I just presented. Share them with us, please! :)
I have a suggestion that would make supporting yast way easier:
Yast D E B U G G E R!!!!!
Most successful computer languages have debuggers. Why doesn't Yast have one?
YaST developers are real hackers, doing debug prints only.
SCNR !
Actually, there never was a strong need for a debugger. It was discussed a few times, but never got sufficient traction/priority to get implemented.
For me debugger and profiller is also critical things, because debug prints is just what is set, but doesn't say why and who the hell change extra freecoolin global variable which cause my L3 incident. But as I said, we should focus on our goal and not reinvent wheel.
Klaus --- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany
-- Josef Reidinger Appliance Toolkit team maintaining parts of webyast and SLMS author of rubygems - studio_api and net_observer (coauthor) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wed, Jun 08, 2011 at 04:57:18PM +0200, Klaus Kaempf wrote:
* Roberto Angelino <rangelino@novell.com> [Jun 08. 2011 16:53]:
I have a suggestion that would make supporting yast way easier:
Yast D E B U G G E R!!!!!
Most successful computer languages have debuggers. Why doesn't Yast have one?
Because it's not a successful language, SCNR.
YaST developers are real hackers, doing debug prints only.
SCNR !
Actually, there never was a strong need for a debugger. It was discussed a few times, but never got sufficient traction/priority to get implemented.
Actually, there *was* a debugger, but with the great interpreter rewrite for SLES9, it got neglected and dropped. Anyway, YCP is still going to be around for some time, and adding some debugging facilities may be worth the effort. Roberto, what would you find useful? Please keep in mind that our focus will be elsewhere, so distill what is most important. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
Because it's not a successful language, SCNR.
Yeah. I stopped tracking computer acronyms 15 years ago. SCNR: Southern California Nano-Reef Society ? South Carolina Natural Resources Society ? Source Code No Response ? ---- Roberto Angelino Dedicated Partner Engineer Developer Support (310) 529-3527 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday, June 08, 2011 05:49:14 PM Roberto Angelino wrote:
Because it's not a successful language, SCNR.
Yeah. I stopped tracking computer acronyms 15 years ago.
SCNR:
Southern California Nano-Reef Society ? South Carolina Natural Resources Society ? Source Code No Response ?
http://en.wiktionary.org/wiki/SCNR Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> SUSE LINUX Products GmbH Research & Development Maxfeldstr. 5 HRB 16746 (AG Nürnberg) D-90409 Nürnberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Anyway, YCP is still going to be around for some time, and adding some debugging facilities may be worth the effort.
Each and every discussion on YaST becomes to a discussion why YCP is a bad language. I agree, YCP has its limitations from a programmer point of view. For a user it doesn't make any difference which programming or scripting language is used as long as YaST installs and configures the user's workstation the right way. From a programmer's perspective it makes a difference. And "just" adding a debugger won't make YCP the best language everyone loves, I guess. That's the reason why I think we should put YCP into maintenance mode and fix critical/major bugs only and focus on real improvements at the same time. An interesting research project would be a YaST module which is written in a popular language that doesn't use YCP at all. When this works out a lot of module authors will also rewrite their YaST modules. And in a couple of centuries YaST will be 100% YCP free. :-) That's my vision. Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hello, On Jun 15 18:32 Thomas Goettlicher wrote (excerpt):
Each and every discussion on YaST becomes to a discussion why YCP is a bad language.
This may reveal what the central issue is with YaST for developers.
An interesting research project would be a YaST module which is written in a popular language that doesn't use YCP at all.
Unless such a YaST module exists, any discussion on YaST (i.e. any discussion on YCP - see above) leads to nowhere.
When this works out a lot of module authors will also rewrite their YaST modules.
I don't think so. At least I would only do a complete rewrite if there is at least one additional real advantage for me. A rewrite only because "YCP is bad" would not make sense for me. For example such an additional real advantage for me could be when it is much simpler/faster/easier/unrestricted to implement the same functionality in the new language.
And in a couple of centuries YaST will be 100% YCP free. :-)
Not so fast! ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wed, Jun 15, 2011 at 06:32:55PM +0200, Thomas Goettlicher wrote:
From a programmer's perspective it makes a difference. And "just" adding a debugger won't make YCP the best language everyone loves, I guess. That's the reason why I think we should put YCP into maintenance mode and fix critical/major bugs only and focus on real improvements at the same time.
The point is not to fix YCP to the point we would love it. That would be futile. The point is realizing that even though we strive for refactoring YaST into a better shape using a better language, we are still left with maintaining the enterprise releases. And they use YCP and the more or less horrible code. That's why I think investing a limited effort in a debugger will pay off.
An interesting research project would be a YaST module which is written in a popular language that doesn't use YCP at all.
That's not merely interesting. That is a fundamental requirement to keep YaST healthy.
When this works out a lot of module authors will also rewrite their YaST modules. And in a couple of centuries YaST will be 100% YCP free. :-)
As Johannes said, people are not eager to completely rewrite software just for fun. I think we will see a gradual refactoring where it makes sense. Given the shape of YCP libraries, I think it will make sense in an awful lot of places ;-) -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 17.6.2011 18:35, Martin Vidner napsal(a):
The point is realizing that even though we strive for refactoring YaST into a better shape using a better language, we are still left with maintaining the enterprise releases. And they use YCP and the more or less horrible code.
That's why I think investing a limited effort in a debugger will pay off.
A limited effort is actually the maximum. On the other hand, it sounds like a nice HackWeek or Workshop project. If we had a (good) debugger, YaST developers would definitely use it.
An interesting research project would be a YaST module which is written in a popular language that doesn't use YCP at all.
That's not merely interesting. That is a fundamental requirement to keep YaST healthy.
What we want to achieve is not only to be able to write YaST module in a popular language, but to be able to write it without hacks, in an easy and understandable way. With tests, etc.
When this works out a lot of module authors will also rewrite their YaST modules. And in a couple of centuries YaST will be 100% YCP free. :-)
As Johannes said, people are not eager to completely rewrite software just for fun. I think we will see a gradual refactoring where it makes sense. Given the shape of YCP libraries, I think it will make sense in an awful lot of places ;-)
Yes, sometimes it also makes sense to drop YCP library and use some upstream one instead. We don't need to write everything by ourselves. I don't expect anyone (ehm) to rewrite their working code into a different language /just/ because it's possible. However, we sometimes need to refactor the code or implement a new feature and writing it in some popular language might be better for the future. YCP itself is not a bad language. It has its own pros and cons, but it's hard to find someone who "knows" that language. Nobody's going to learn it /just/ because they can. It has no other usage than for YaST development and that's usually not enough. Lukas - -- Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o. MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFOCJ3RVSqMdRCqTiwRAuzBAKCdUMdts9Pm2lgrXnRvn+3n6fDO/ACbB4vj XmRhCPsh3kv6QjOkvn5gM1o= =S6gX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
>>> On 6/8/2011 at 07:57 AM, in message <20110608145718.GC12470@heron.suse.de>, Klaus Kaempf <kkaempf@suse.de> wrote: > * Roberto Angelino <rangelino@novell.com> [Jun 08. 2011 16:53]: >> > I believe that you have other ideas how to improve the development - how >> > to make the development and maintenance easier for you and/or the >> > others. Or you maybe have an opinion on the ideas I just presented. >> > Share them with us, please! :) >> >> I have a suggestion that would make supporting yast way easier: >> >> Yast D E B U G G E R!!!!! >> >> Most successful computer languages have debuggers. Why doesn't Yast >> have one? > > YaST developers are real hackers, doing debug prints only. > > SCNR ! > > Actually, there never was a strong need for a debugger. It was > discussed a few times, but never got sufficient traction/priority > to get implemented. Response from the support perspective: I can see how within the "yast circle of developers", you don't think you need it. But if you want to make yast more main stream and you want people like me supporting it (and like supporting it) and making it so SuSE Yast developers spend more time doing yast development rather than spending valuable time helping debug a yast issue. Yast is complex. Yast is big. Too big to not have a debugger. It would be nice in situations where the customer says I'm having an issue and I do not have the hardware, nor the environment to help them. Response from the developer in me: You crazy. I will never pick up a language without a debugger. Life is too short to be using print statements. I don't have the time or bandwidth to even figure out where I would need to put a print statement? If I run into a problem, I would love to attach to a process and figure out what it's doing. It's the fastest way to learn a complex system like Yast without having to spend hours and hours walking code. ---- Roberto Angelino Dedicated Partner Engineer Developer Support (310) 529-3527 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday, June 08, 2011 05:45:41 PM Roberto Angelino wrote:
Response from the developer in me:
You crazy. I will never pick up a language without a debugger. Life is too short to be using print statements. I don't have the time or bandwidth to even figure out where I would need to put a print statement? If I run into a problem, I would love to attach to a process and figure out what it's doing. It's the fastest way to learn a complex system like Yast without having to spend hours and hours walking code.
The dilemma we are in right now is: On the one hand we want to attract more people to develop YaST modules, we want to make it easy for them so they love to code YaST modules. On the other hand we want to switch our own language YCP and stick to a common used language and gain their debugger, testing infrastructure ... aso. Now we need to figure out how much time we want to spend on both of this (without making anyone angry because he had hard time learning YCP and then we drop it in favour of the new language). Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> SUSE LINUX Products GmbH Research & Development Maxfeldstr. 5 HRB 16746 (AG Nürnberg) D-90409 Nürnberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
You crazy. I will never pick up a language without a debugger. Life is too short to be using print statements. I don't have the time or bandwidth to even figure out where I would need to put a print statement? If I run into a problem, I would love to attach to a process and figure out what it's doing. It's the fastest way to learn a complex system like Yast without having to spend hours and hours walking code.
The dilemma we are in right now is: On the one hand we want to attract more people to develop YaST modules, we want to make it easy for them so they love to code YaST modules. On the other hand we want to switch our own language YCP and stick to a common used language and gain their debugger, testing infrastructure ... aso.
OK. So why not extend an EXISTING language that already has a debugger/profiler, IDE, whatever. I remember seeing a while back on this list talk about using ruby? And hey look ruby has a debugger (http://bashdb.sourceforge.net/ruby-debug.html) !!!
Now we need to figure out how much time we want to spend on both of this (without making anyone angry because he had hard time learning YCP and then we drop it in favour of the new language).
Gotcha. Well, you guys have a big decision to make then. But this is the next step to make if Yast is to grow beyond SuSE and make it more attractive to the masses. ---- Roberto Angelino Dedicated Partner Engineer Developer Support (310) 529-3527 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Roberto Angelino <rangelino@novell.com> [Jun 08. 2011 17:50]:
Response from the developer in me:
You crazy.
LOL - And fully agreed ! But in those dark ages back then, it was not a priority. As you can see from the current discussion, the viewpoint has changed and supporting a community of YaST developers actually has a very high priority today. Klaus --- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 06/08/2011 01:54 PM, Klaus Kaempf wrote:
* Roberto Angelino<rangelino@novell.com> [Jun 08. 2011 17:50]:
Response from the developer in me:
You crazy.
LOL - And fully agreed !
But in those dark ages back then, it was not a priority.
As you can see from the current discussion, the viewpoint has changed and supporting a community of YaST developers actually has a very high priority today.
And I think we mostly agree that we are not going to get there with ycp ;) -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi! Just my 2 cents to this discussion: I think that because of lack of resources, we should concentrate on Amaranth prototyping instead of enhancing current YCP development ecosystem. Of course, when new ycp code is written, it should follow current style guides and contain testsuites. But I would not invest into new tools. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi all, just my 2 cents as a translator since I want to point out some problem I find when I translate (not specific for YaST, but I think you should consider also such problems in your discussion about coding attitude). 2011/6/8 Lukas Ocilka <lukas.ocilka@suse.cz>:
Coding Standards - The code should be not only understandable to ourselves but also to the others.
In particular messages should be easily understandable also to translators.
- Examples:
* avoid string concatenation For translators it is difficult to write good sentences when the original message is split in several parts as a consequence of concatenation of strings and parameters. This affects in particular languages that distinguish genre as well as singular/plural. For me (but I think it is the same for other translators), it is better to have more strings (with placeholders) and repeated parts than short but split strings. For instance, the msgid "should not be empty" can be translated in Italian in several ways, depending on the actual subject.
* Useful comments
Please consider to add useful comments also for translators: sometimes it is difficult to translate in a right way some message involving placeholders since it is not so easy to guess the term that replaces the placeholder, so there can be a genre or singular/plural mismatch in the resulting translation. Moreover, the order of placeholders should not be imposed. Similarly, since usually translators are not familiar as you with the message context, sometimes it is difficult to parse correctly complex messages, in particular when there is a quite long sequence of adjectives and nouns that can be bound in different ways such that the correct one depends on the context. Regards, Andrea -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 8.6.2011 15:16, Lukas Ocilka napsal(a):
Code Reviews - In the SLMS team, we've found out that all the commits should be reviewed by someone else. This helps to identify potential issues in time. All the commits are public anyway. - Fix|Easy to Medium: Either someone is always assigned to review everyone's code (takes too much time) or developers usually check code of someone else only.
Martin, thank you for the reviews you do. They've already helped to find several bugs or possible issues even before they reached our users and made some harm. - From my POV, this looks very promising. Others will hopefully help with the reviews later ;) Bye Lukas - -- Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o. MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFN/xFNVSqMdRCqTiwRAhKvAJ961eYyhID4nHOs3/y4pS78j26WyACaA+QS ovaXS/nHWeIcDEkUEZ4oBZQ= =kG4e -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Lukas Ocilka write:
Dne 8.6.2011 15:16, Lukas Ocilka napsal(a):
Code Reviews - In the SLMS team, we've found out that all the commits should be reviewed by someone else. This helps to identify potential issues in time. All the commits are public anyway. - Fix|Easy to Medium: Either someone is always assigned to review everyone's code (takes too much time) or developers usually check code of someone else only.
Martin, thank you for the reviews you do. They've already helped to find several bugs or possible issues even before they reached our users and made some harm.
From my POV, this looks very promising. Others will hopefully help with the reviews later ;)
Bye Lukas
Well, actually I think that we should connect it with git. Git allows to have official git repository and a lot of development git repository, so we can do it same way like kernel, wine or other projects. see e.g. http://help.github.com/fork-a-repo/ and http://help.github.com/send-pull-requests/ I really like this workflow, as it allows to easy checkout your modified repository and then test it, comment each line. So you can work in branches on different features, bug fixes etc ( in git really easy, I hope we have for non-git users presentation on workshop ), do it and then send pull request which is reviewed by authorized reviewer and if everything is fine, then accept it. If there is problems, you can discuss it under pull request and improve branch ( fix issues ) and send again. Advantages: - centralized place for reviews - well defined group which is responsible for accepting patches - you review whole functionality, not just one commit, but whole set ( so you can check if it is tested, documented, API looks reasonable, code is readable, follow style guide etc. ). We can e.g. create process that module backup need to review it for module specific things ( as side effect he also know how module changed, so in case of vacation he know code ) and general reviewer check general rules. Disadvantages: - need some time, quick hackish solution will not be so quick and easy - we need to somehow force use of for packages only code from official repo ( e.g. new services for OBS could help as, as we can have hudson which observe this repo and send to devel repo packages with recent changes ) I think we should discuss it now and what is more important decide it on workshop where is everyone and we should decide future direction of YaST. Pepa -- Josef Reidinger Appliance Toolkit team maintaining parts of webyast and SLMS author of rubygems - studio_api and net_observer (coauthor) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
This actually relates to 'Changing the Attitude to Coding YaST' topic. I wanted to cover some of the new ycp code with tests, but I failed because my new functions rely on Pkg:: interface. And, guess what - we do not have a way to mock Pkg. In the old days, this was (kind of) possible, see Pkg.ycp in testsuite/src which defined basically empty return values: global define boolean ActivateSelections () { return true;} Well, it did not allow us to let it return specific values, which would be really the best option. But at least it did not start package manager during testing. Would it make sense to revive this? Or to even enable real mocking of Pkg? Or is it waste of the effort, which we should rather invest into the new YaST++ project? Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Dne 21.6.2011 16:21, Jiri Suchomel napsal(a):
Would it make sense to revive this? Or to even enable real mocking of Pkg? Or is it waste of the effort, which we should rather invest into the new YaST++ project?
I'd rather invest the effort into YaST++, making Pkg bindings mockable won't help us in YaST++ anyway. As a workaround for now you can replace e.g. boolean installed = Pkg::IsInstalled("foo"); by this boolean installed = Mode::testMode() ? true : Pkg::IsInstalled("foo"); or wrap the Pkg:: call in a local function. It's not a nice solution but should be sufficient in the current state... -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Ut 21. Jún 2011 16:36:01 Ladislav Slezak wrote:
Dne 21.6.2011 16:21, Jiri Suchomel napsal(a):
Would it make sense to revive this? Or to even enable real mocking of Pkg? Or is it waste of the effort, which we should rather invest into the new YaST++ project?
I'd rather invest the effort into YaST++, making Pkg bindings mockable won't help us in YaST++ anyway.
As a workaround for now you can replace e.g.
boolean installed = Pkg::IsInstalled("foo");
by this
boolean installed = Mode::testMode() ? true : Pkg::IsInstalled("foo");
or wrap the Pkg:: call in a local function.
It's not a nice solution but should be sufficient in the current state...
This still should be possible. Did you try to use y2base -M option (namespace overloading)? Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Dne Út 21. června 2011 16:43:06 Stanislav Visnovsky napsal(a):
On Ut 21. Jún 2011 16:36:01 Ladislav Slezak wrote:
Dne 21.6.2011 16:21, Jiri Suchomel napsal(a):
Would it make sense to revive this? Or to even enable real mocking of Pkg? Or is it waste of the effort, which we should rather invest into the new YaST++ project?
This still should be possible. Did you try to use y2base -M option (namespace overloading)?
Stano
Thanks, this works (with -n, not -M): /usr/lib/YaST2/bin/y2base -l - -n Pkg=WFM -M . tests/ProductProfile.ycp testsuite where Pkg.y* exists in current directory ("-M .") -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wed, Jun 22, 2011 at 09:42:25AM +0200, Jiri Suchomel wrote:
Dne Út 21. června 2011 16:43:06 Stanislav Visnovsky napsal(a):
On Ut 21. Jún 2011 16:36:01 Ladislav Slezak wrote:
Dne 21.6.2011 16:21, Jiri Suchomel napsal(a):
Would it make sense to revive this? Or to even enable real mocking of Pkg? Or is it waste of the effort, which we should rather invest into the new YaST++ project?
This still should be possible. Did you try to use y2base -M option (namespace overloading)?
Stano
Thanks, this works (with -n, not -M):
/usr/lib/YaST2/bin/y2base -l - -n Pkg=WFM -M . tests/ProductProfile.ycp testsuite
where Pkg.y* exists in current directory ("-M .")
I think this is a good direction to approach this, except that the test runner script is a bad place to specify the namespace exceptions. I think that it should be doable from inside the yast runtime, something like import "Pkg" from "WFM"; or even import "Pkg", $["from": "WFM", "dir": "."]; // combine -n, -M which is more flexible and does not need special syntax so it will be acceesible even from other languages. The improved import statement should enable mocking on a wider scale. For now you could use the -n and -M options, but I am afraid that the test harness will by default overwrite your changes to runtest.sh. Changing that is hacky, but you can look to mail/testsuite/Makefile.am for inspiration. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
* Martin Vidner <mvidner@suse.cz> [Jun 27. 2011 12:46]:
I think this is a good direction to approach this, except that the test runner script is a bad place to specify the namespace exceptions. I think that it should be doable from inside the yast runtime, something like import "Pkg" from "WFM"; or even
import "Pkg", $["from": "WFM", "dir": "."]; // combine -n, -M
which is more flexible and does not need special syntax so it will be acceesible even from other languages.
Are you suggesting an enhanced 'import' syntax here ? Wouldn't changing the search path be sufficient ? Klaus --- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (13)
-
Andrea Turrini -
J. Daniel Schmidt -
Jiri Suchomel -
Johannes Meixner -
Josef Reidinger -
Klaus Kaempf -
Ladislav Slezak -
Lukas Ocilka -
Martin Vidner -
Robert Schweikert -
Roberto Angelino -
Stanislav Visnovsky -
Thomas Goettlicher