[yast-devel] Yast and Rubocop?
Hi all, I looked at Rubocop (a Ruby code scanner) [1] and tried to use it in the registration module to see if it could be used in Yast to improve the code quality. I have summarized my findings in a blog post [2], in short: - it is highly configurable - it can find also some semantic issues - it suggests how to fix the found issues - it can auto correct many issues (esp. indentation and white space) You can see the found issues and fixes in this pull request [3]. Many issues were just harmless indentation or white space issues, but some were quite critical like this "private" attribute misuse [4]. Majority of the issues were autocorrected by Rubocop itself, I just reviewed the changes and committed each fix in a separate commit to see what was the problem and how it was fixed. What do you think about Rubocop and Yast? Would it make sense to use it globally for all modules? What would be the pros and cons for you? Would you like to fix the coding issues in the existing code? Thanks for your feedback! [1] https://github.com/bbatsov/rubocop [2] http://lslezak.blogspot.cz/2014/11/using-rubocop.html [3] https://github.com/yast/yast-registration/pull/177 [4] https://github.com/yast/yast-registration/commit/4f4819838723e7ddd7598976db2... -- 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 To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 24.11.2014 v 19:56 Ladislav Slezak napsal(a):
I looked at Rubocop (a Ruby code scanner) [1] and tried to use it in the registration module to see if it could be used in Yast to improve the code quality.
[...]
- it can auto correct many issues (esp. indentation and white space)
Rubocop can be extended via plugins, e.g. there is an extra plugin for additional RSpec checks [1]. The interesting feature is the "--auto-correct" option which enables auto fixing of the found issues (if supported by the respective check). That means Rubocop can parse, analyze, edit the parsed tree and serialize it back to a Ruby source. My question is: Could be the Rubocop infrastructure used for the YCP Zombie Killer? Could it be changed to a Rubocop plugin? (Maybe it's not possible, I do not know the Rubocop neither the YCP ZK internals...) Then it could check for deprecated Builtins.* and Ops.* method calls, it could even check for deprecated Yast modules like Yast::String, Yast::URL which should be replaced by a native Ruby code (IIRC that's WIP by Christopher). The deprecated method check in Rubocop looks quite easy [2], but there is no context which is probably needed for ZK... Martin? [1] https://github.com/nevir/rubocop-rspec [2] https://github.com/bbatsov/rubocop/blob/master/lib/rubocop/cop/lint/deprecat... -- 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 To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, Nov 24, 2014 at 11:02:32PM +0100, Ladislav Slezak wrote:
My question is: Could be the Rubocop infrastructure used for the YCP Zombie Killer? Could it be changed to a Rubocop plugin? (Maybe it's not possible, I do not know the Rubocop neither the YCP ZK internals...)
The quick answer is that it is likely possible because both Rubocop and ZombieKiller use parser.gem :-) -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
Hi, do we want it to rename functions? (from your PR:) - def self.is_registered? + def self.registered? It has a potential to break modules which are not passed through rubocop yet and use such functions, or? What am I missing? Jiri On 11/24/2014 07:56 PM, Ladislav Slezak wrote:
Hi all,
I looked at Rubocop (a Ruby code scanner) [1] and tried to use it in the registration module to see if it could be used in Yast to improve the code quality.
I have summarized my findings in a blog post [2], in short:
- it is highly configurable - it can find also some semantic issues - it suggests how to fix the found issues - it can auto correct many issues (esp. indentation and white space)
You can see the found issues and fixes in this pull request [3]. Many issues were just harmless indentation or white space issues, but some were quite critical like this "private" attribute misuse [4]. Majority of the issues were autocorrected by Rubocop itself, I just reviewed the changes and committed each fix in a separate commit to see what was the problem and how it was fixed.
What do you think about Rubocop and Yast? Would it make sense to use it globally for all modules? What would be the pros and cons for you? Would you like to fix the coding issues in the existing code?
Thanks for your feedback!
[1] https://github.com/bbatsov/rubocop [2] http://lslezak.blogspot.cz/2014/11/using-rubocop.html [3] https://github.com/yast/yast-registration/pull/177 [4] https://github.com/yast/yast-registration/commit/4f4819838723e7ddd7598976db2...
--
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/
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 25.11.2014 v 07:55 Jiri Srain napsal(a):
Hi,
do we want it to rename functions? (from your PR:)
- def self.is_registered? + def self.registered?
Oh, good point, this change should not go to SLE-12-GA branch, only to the "master" as this changes the API... I'll remove that commit, thanks for reporting this!
It has a potential to break modules which are not passed through rubocop yet and use such functions, or? What am I missing?
Yes, we will need to disable some checks in the SLE-12 branch (and some need to be disabled also in the "master", e.g we need to enable the CamelCase method names which are used in modules). -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 11/25/2014 08:44 AM, Ladislav Slezak wrote:
Dne 25.11.2014 v 07:55 Jiri Srain napsal(a):
Hi,
do we want it to rename functions? (from your PR:)
- def self.is_registered? + def self.registered?
Oh, good point, this change should not go to SLE-12-GA branch, only to the "master" as this changes the API... I'll remove that commit, thanks for reporting this!
Thinking of this even further, can it lead to having two functions with the same name (even if only in master)? Does rubocop look at the function names in full context to prevent it? Jiri
It has a potential to break modules which are not passed through rubocop yet and use such functions, or? What am I missing?
Yes, we will need to disable some checks in the SLE-12 branch (and some need to be disabled also in the "master", e.g we need to enable the CamelCase method names which are used in modules).
--
Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 25 Nov 2014 07:55:21 +0100 Jiri Srain <jsrain@suse.cz> wrote:
Hi,
do we want it to rename functions? (from your PR:)
- def self.is_registered? + def self.registered?
It has a potential to break modules which are not passed through rubocop yet and use such functions, or? What am I missing?
I think it is up to all people to decide and check it. I worry that this check need to be disabled for a lot of yast modules as there is a lot of non ruby names. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 24 Nov 2014 19:56:00 +0100 Ladislav Slezak <lslezak@suse.cz> wrote:
Hi all,
I looked at Rubocop (a Ruby code scanner) [1] and tried to use it in the registration module to see if it could be used in Yast to improve the code quality.
I have summarized my findings in a blog post [2], in short:
- it is highly configurable - it can find also some semantic issues - it suggests how to fix the found issues - it can auto correct many issues (esp. indentation and white space)
You can see the found issues and fixes in this pull request [3]. Many issues were just harmless indentation or white space issues, but some were quite critical like this "private" attribute misuse [4]. Majority of the issues were autocorrected by Rubocop itself, I just reviewed the changes and committed each fix in a separate commit to see what was the problem and how it was fixed.
What do you think about Rubocop and Yast? Would it make sense to use it globally for all modules? What would be the pros and cons for you? Would you like to fix the coding issues in the existing code?
Thanks for your feedback!
I think it is really interesting, but for bigger modules it is quite lot work to fix all warnings. Is it possible to limit check only to some files? Like when I do refactoring in bootloader, I want to have all refactored code to follow ruby conventions, but old code still need cleaning, so it do not make much sense to do all changes just to throw it away when I refactor it. I also considering code that use ruby C-part that maybe need to use methods from such binding that does not follow conventions, if it is possible to disable check there. I also see that you set line lenght to 140 characters. This looks too much for me, especially if we need to modify code for debuging purpose during installation where is limited console. But we can use it similar like metrics ( see below ). I also found quite confusing this commit https://github.com/yast/yast-registration/commit/f0882e005ede24e7df747f803f2... why not simple `expect(fp1).not_to eq nil` ? https://github.com/yast/yast-registration/commit/f1380e4586897aaa23cfb20ab0f... similar here. I expect something like `expect(fp1).to eq fp1` Also I am not sure if it is good idea to name attributes that is throwed out. For me better convention is to use simple "_" for such variables, so it is clear that we do not care: _, _, a, _ = [0,1,2,3] a => 2 ( I mean this commit https://github.com/yast/yast-registration/commit/42a9b37e83540e4c93baf53abd5... ) Another question why do you disable align of Arrays and Hashes? Converted code use it and I found it quite helpful when reading code: https://github.com/yast/yast-registration/commit/b814d2b7b1351343cc71ad6ad9e... similar question for aligning function calls. If you have Align plugin in vim, it is really trivial to make it aligned. Is there reason to use new lambda syntax? I found it harder to read then lambda one. When using lambda it is for me tight with lambda calculus, syntax with ->() is quite confusing for me and not so easy to follow. https://github.com/yast/yast-registration/commit/8c9b333fcc347335da94196d6c9... I also think that we should not disable unless check https://github.com/yast/yast-registration/commit/fc7efc4dc8e294cb79574e4c3f8... it is often hard to read and I think also in suse style guide we have using unless only in trailing form and only with single argument, otherwise it is quite hard to read it as you need to think how logical operators works with global negotiation. For me it is more familiar to use if with negotiation in more complex expressions. Also what is reason to not check extra indentation for multiline operators? I think it really helps with code readability and with coupling lines together. https://github.com/yast/yast-registration/commit/19df8cbd13e677bfb52384f2959... when I see this change ( https://github.com/yast/yast-registration/commit/3e89195d3938d04c3de39b2a5a9... ), I am not sure if it helps with readability. I think better change is to change it to if ret == :skip && confirm_skipping log.info "Skipping registration on user request" @registration_skipped = true break end end in general I am not sure if it is wrong to use return in loops. What is rationale behind? This commit is interesting: https://github.com/yast/yast-registration/commit/9c41a8eb25f6ee1da0bade91eb8... I think it can help to set it to max number that pass to ensure we do not increase complexity when changing code and when refactoring then decrease numbers, so we are sure we are going forward with our goal with improved code and do not make steps back. In general I think it is really interesting project and what we need is agreement which rules we want to follow and if we want follow same think for all modules or if we allow module specific checks ( like method names only for specific modules ). Also I think we should document all style rules we use as there is a lot of decisions in pull request. What I really like is that automatic checks allow us to not go back with our goal to improve code quality/ ruby style compliance. So if someone else need to touch your code, (s-)he cannot make it worse. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 25.11.2014 v 10:51 Josef Reidinger napsal(a):
I think it is really interesting, but for bigger modules it is quite lot work to fix all warnings. Is it possible to limit check only to some files?
Yes, you can include/exclude files which are checked, see https://github.com/bbatsov/rubocop/blob/master/README.md#includingexcluding-... So you could include "lib/*" (I guess the most of the new code will be there) and exclude the rest (you can even list specific files). Or you could enable just some checks for the old code, like check indentation and disable checks which require variable or method renames or some refactoring.
Like when I do refactoring in bootloader, I want to have all refactored code to follow ruby conventions, but old code still need cleaning, so it do not make much sense to do all changes just to throw it away when I refactor it.
You could also disable warnings and just check for errors (or worse) or you could enable only the checks which can be autocorrected and run autocorrection to fix them automatically... There are many possibilities how to deal with the old code, see the doc link above.
I also see that you set line lenght to 140 characters. This looks too much for me, especially if we need to modify code for debuging purpose during installation where is limited console. But we can use it similar like metrics ( see below ).
Ok, that's probably too much... What about 120? Personally I think the 80 chars limit does not make much sense with wide screen LCDs anymore...
I also found quite confusing this commit https://github.com/yast/yast-registration/commit/f0882e005ede24e7df747f803f2...
why not simple `expect(fp1).not_to eq nil` ?
https://github.com/yast/yast-registration/commit/f1380e4586897aaa23cfb20ab0f...
similar here. I expect something like `expect(fp1).to eq fp1`
Oh, good point, that's a better fix, thanks!
Also I am not sure if it is good idea to name attributes that is throwed out. For me better convention is to use simple "_" for such variables, so it is clear that we do not care:
_, _, a, _ = [0,1,2,3] a => 2
Um, I was little bit worried here about possible conflict with _ function (_() is a gettext translation function). Is it safe? In all contexts? The upstream style guide on the other hand prefers prefixing to plain _, see https://github.com/bbatsov/ruby-style-guide#underscore-unused-vars
Another question why do you disable align of Arrays and Hashes? Converted code use it and I found it quite helpful when reading code: https://github.com/yast/yast-registration/commit/b814d2b7b1351343cc71ad6ad9e...
similar question for aligning function calls. If you have Align plugin in vim, it is really trivial to make it aligned.
Um, there was some problem with it, I'll look at it again...
Is there reason to use new lambda syntax?
Not really, our style guide does not mention this and the upstream style guide (https://github.com/bbatsov/ruby-style-guide#lambda-multi-line) suggests using ->() for single line functions and "lambda" for multi-line. My approach here is: if it is not in our style guide, lets use the upstream one. And if we don't like the upstream default then adapt our style... I'm not strict here, if we decide to not use ->() at all I'm fine with that....
https://github.com/yast/yast-registration/commit/8c9b333fcc347335da94196d6c9...
I also think that we should not disable unless check https://github.com/yast/yast-registration/commit/fc7efc4dc8e294cb79574e4c3f8...
it is often hard to read and I think also in suse style guide we have using unless only in trailing form and only with single argument, otherwise it is quite hard to read it as you need to think how logical operators works with global negotiation. For me it is more familiar to use if with negotiation in more complex expressions.
The check works the other way round, it *requires* to use "unless" instead of "if !" so disabling that check is OK :-)
Also what is reason to not check extra indentation for multiline operators? I think it really helps with code readability and with coupling lines together.
I'll recheck this...
https://github.com/yast/yast-registration/commit/19df8cbd13e677bfb52384f2959...
when I see this change ( https://github.com/yast/yast-registration/commit/3e89195d3938d04c3de39b2a5a9...
), I am not sure if it helps with readability. I think better change is to change it to
if ret == :skip && confirm_skipping log.info "Skipping registration on user request" @registration_skipped = true break end end
in general I am not sure if it is wrong to use return in loops. What is rationale behind?
Again, I'll recheck this...
This commit is interesting: https://github.com/yast/yast-registration/commit/9c41a8eb25f6ee1da0bade91eb8...
I think it can help to set it to max number that pass to ensure we do not increase complexity when changing code and when refactoring then decrease numbers, so we are sure we are going forward with our goal with improved code and do not make steps back.
Yes, these numbers were automatically set to the highest found and should be gradually decreased with each refactoring.
In general I think it is really interesting project and what we need is agreement which rules we want to follow and if we want follow same think for all modules or if we allow module specific checks ( like method names only for specific modules).
Maybe we should create two default configs, one more strict for new modules/files and one less strict for the legacy (converted) code. We will need to adapt the config for each repository anyway, for example the maximum code complexity or max. method length will be different in each repo.
Also I think we should document all style rules we use as there is a lot of decisions in pull request.
Yes, once we agree on the final checks and style we should document our decisions. (and adapt our style guide if needed).
What I really like is that automatic checks allow us to not go back with our goal to improve code quality/ ruby style compliance. So if someone else need to touch your code, (s-)he cannot make it worse.
Yes and these checks will help us to avoid nitpicking comments in reviews as the style checks will be already done by Rubocop ;-) And if we use the same Rubocop config file (or base it on the same) in all repositories we can ensure that the coding style is uniform across all Yast modules. -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 25 Nov 2014 13:14:32 +0100 Ladislav Slezak <lslezak@suse.cz> wrote:
Dne 25.11.2014 v 10:51 Josef Reidinger napsal(a):
I think it is really interesting, but for bigger modules it is quite lot work to fix all warnings. Is it possible to limit check only to some files?
Yes, you can include/exclude files which are checked, see https://github.com/bbatsov/rubocop/blob/master/README.md#includingexcluding-...
So you could include "lib/*" (I guess the most of the new code will be there) and exclude the rest (you can even list specific files). Or you could enable just some checks for the old code, like check indentation and disable checks which require variable or method renames or some refactoring.
Like when I do refactoring in bootloader, I want to have all refactored code to follow ruby conventions, but old code still need cleaning, so it do not make much sense to do all changes just to throw it away when I refactor it.
You could also disable warnings and just check for errors (or worse) or you could enable only the checks which can be autocorrected and run autocorrection to fix them automatically...
There are many possibilities how to deal with the old code, see the doc link above.
Thanks for link. It looks good.
I also see that you set line lenght to 140 characters. This looks too much for me, especially if we need to modify code for debuging purpose during installation where is limited console. But we can use it similar like metrics ( see below ).
Ok, that's probably too much... What about 120? Personally I think the 80 chars limit does not make much sense with wide screen LCDs anymore...
wide screen LCD do not help you in textmode with 80 chars width terminal. Also it is not so easy to get code that is on so long line. In general need for such long line is code smell :)
I also found quite confusing this commit https://github.com/yast/yast-registration/commit/f0882e005ede24e7df747f803f2...
why not simple `expect(fp1).not_to eq nil` ?
https://github.com/yast/yast-registration/commit/f1380e4586897aaa23cfb20ab0f...
similar here. I expect something like `expect(fp1).to eq fp1`
Oh, good point, that's a better fix, thanks!
Also I am not sure if it is good idea to name attributes that is throwed out. For me better convention is to use simple "_" for such variables, so it is clear that we do not care:
_, _, a, _ = [0,1,2,3] a => 2
Um, I was little bit worried here about possible conflict with _ function (_() is a gettext translation function). Is it safe? In all contexts?
yes, as you only use it in assign.
The upstream style guide on the other hand prefers prefixing to plain _, see https://github.com/bbatsov/ruby-style-guide#underscore-unused-vars
OK, it depends what you need. In some case it make sense, if it is not obvious what is other parts of response.
Another question why do you disable align of Arrays and Hashes? Converted code use it and I found it quite helpful when reading code: https://github.com/yast/yast-registration/commit/b814d2b7b1351343cc71ad6ad9e...
similar question for aligning function calls. If you have Align plugin in vim, it is really trivial to make it aligned.
Um, there was some problem with it, I'll look at it again...
If there is problem if would be nice to document what exactly.
Is there reason to use new lambda syntax?
Not really, our style guide does not mention this and the upstream style guide (https://github.com/bbatsov/ruby-style-guide#lambda-multi-line) suggests using ->() for single line functions and "lambda" for multi-line.
My approach here is: if it is not in our style guide, lets use the upstream one. And if we don't like the upstream default then adapt our style...
I'm not strict here, if we decide to not use ->() at all I'm fine with that....
It can be intersting how others see it.
https://github.com/yast/yast-registration/commit/8c9b333fcc347335da94196d6c9...
I also think that we should not disable unless check https://github.com/yast/yast-registration/commit/fc7efc4dc8e294cb79574e4c3f8...
it is often hard to read and I think also in suse style guide we have using unless only in trailing form and only with single argument, otherwise it is quite hard to read it as you need to think how logical operators works with global negotiation. For me it is more familiar to use if with negotiation in more complex expressions.
The check works the other way round, it *requires* to use "unless" instead of "if !" so disabling that check is OK :-)
Ah, ok, it make sense.
Also what is reason to not check extra indentation for multiline operators? I think it really helps with code readability and with coupling lines together.
I'll recheck this...
https://github.com/yast/yast-registration/commit/19df8cbd13e677bfb52384f2959...
when I see this change ( https://github.com/yast/yast-registration/commit/3e89195d3938d04c3de39b2a5a9...
), I am not sure if it helps with readability. I think better change is to change it to
if ret == :skip && confirm_skipping log.info "Skipping registration on user request" @registration_skipped = true break end end
in general I am not sure if it is wrong to use return in loops. What is rationale behind?
Again, I'll recheck this...
This commit is interesting: https://github.com/yast/yast-registration/commit/9c41a8eb25f6ee1da0bade91eb8...
I think it can help to set it to max number that pass to ensure we do not increase complexity when changing code and when refactoring then decrease numbers, so we are sure we are going forward with our goal with improved code and do not make steps back.
Yes, these numbers were automatically set to the highest found and should be gradually decreased with each refactoring.
In general I think it is really interesting project and what we need is agreement which rules we want to follow and if we want follow same think for all modules or if we allow module specific checks ( like method names only for specific modules).
Maybe we should create two default configs, one more strict for new modules/files and one less strict for the legacy (converted) code.
It make sense. For old code add checks for ruby style problems that is not in translated code. And for new more checks, that can even conflict with translated code like
We will need to adapt the config for each repository anyway, for example the maximum code complexity or max. method length will be different in each repo.
agreed. But it would be good to define goal which we want reach. Like complexity smaller then 7 do not make sense.
Also I think we should document all style rules we use as there is a lot of decisions in pull request.
Yes, once we agree on the final checks and style we should document our decisions. (and adapt our style guide if needed).
What I really like is that automatic checks allow us to not go back with our goal to improve code quality/ ruby style compliance. So if someone else need to touch your code, (s-)he cannot make it worse.
Yes and these checks will help us to avoid nitpicking comments in reviews as the style checks will be already done by Rubocop ;-)
And if we use the same Rubocop config file (or base it on the same) in all repositories we can ensure that the coding style is uniform across all Yast modules.
Yes, it would be nice. I probably try to configure it for bootloader and see what I see. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 25.11.2014 v 13:27 Josef Reidinger napsal(a):
Ok, that's probably too much... What about 120? Personally I think the 80 chars limit does not make much sense with wide screen LCDs anymore...
wide screen LCD do not help you in textmode with 80 chars width terminal. Also it is not so easy to get code that is on so long line. In general need for such long line is code smell :)
OK, I limited the length to 100 and fixed few longer lines. Going down to 80 is not that easy, rubocop reports 320 errors...
Another question why do you disable align of Arrays and Hashes? [...] Um, there was some problem with it, I'll look at it again...
If there is problem if would be nice to document what exactly.
Ok, found it, I had to set a different default style as I didn't like the rubocop's default. PR updated.
Is there reason to use new lambda syntax?
Not really, our style guide does not mention this and the upstream style guide (https://github.com/bbatsov/ruby-style-guide#lambda-multi-line) suggests using ->() for single line functions and "lambda" for multi-line. [...] It can be intersting how others see it.
Any other opinions about this? I think this is not a critical decision as lambdas are not used much often... (My quick grep shows that there are ~3700 lambdas in all Yast code, but ~2700 out of them are in the old tests which should be replaced anyway. The rest is usually workflow sequence definition...)
Also what is reason to not check extra indentation for multiline operators? I think it really helps with code readability and with coupling lines together.
OK, enabled, there was actually no problem with it... [...]
We will need to adapt the config for each repository anyway, for example the maximum code complexity or max. method length will be different in each repo.
agreed. But it would be good to define goal which we want reach. Like complexity smaller then 7 do not make sense.
I think we should use common sense and decide case by case. The tool should work for us, not the other way round... For new code we could use stricter limits while for the old (converted) code we could use relaxed settings to just make sure we do not make the code worse. As it depends on the specific repository (how "good" the current code is) there cannot be a global goal. For the new code the goal could be to pass using the default rubocop code metric limits (i.e. without need to override/raise the defaults). - -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUdK59AAoJEHHp6jkF1zbPapUH/19Rx2RYsW3pVrHN5hQFAf9O U/PreqQqJT82zBSiuGWIqj+oAlOXXFaQFd8bZgAQ/8iMJWbGyclXcCXt2K6+aPsX gMR+KurP8ugdCvYGOZ6g5SJsEGPC4JqfItlTc1Bhlxn7BB25Pxkj5zgIR0OOGYmY qzI5hspt50S/Q5bvx98PQyY4nZ1jEmdqlklLMIFB5CnaaCOUwGBTqT147L974LHO wheP/Xfcr4rFB7fGiNzjcfeTQ3HEf8Xujrx2nuCjUZpA/CQOq8TtmlfqTyMSRhbq 5tWl/sURZCzeyI+1DexGL1DaDJlaHJg/VrFYERGOKkrub1gSLnLtFJld7wnYENY= =p1df -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Nov 25, 2014 at 05:29:50PM +0100, Ladislav Slezak wrote:
Dne 25.11.2014 v 13:27 Josef Reidinger napsal(a):
Ok, that's probably too much... What about 120? Personally I think the 80 chars limit does not make much sense with wide screen LCDs anymore...
wide screen LCD do not help you in textmode with 80 chars width terminal. Also it is not so easy to get code that is on so long line. In general need for such long line is code smell :)
OK, I limited the length to 100 and fixed few longer lines. Going down to 80 is not that easy, rubocop reports 320 errors...
Yes, for existing code which uses too many too long lines we may need to relax a bit, but in general, let me quote https://github.com/SUSE/style-guides/blob/master/Ruby.md#code-layout
Wrap lines at 80 columns. This is not a hard rule, but if you break it, it should be only because the code would be less readable otherwise (e.g. you are embedding a long URL).
Rationale: While long lines are not a problem on wide-screen displays, many people look at the code on terminals, e-mail clients, etc. where the viewport isn’t that wide. People also use multiple editor windows side-by-side (e.g. when writing code and tests for it simultaneously) or viewing diffs.
-- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On Wed, Nov 26, 2014 at 11:29:57AM +0100, Martin Vidner wrote:
On Tue, Nov 25, 2014 at 05:29:50PM +0100, Ladislav Slezak wrote:
Dne 25.11.2014 v 13:27 Josef Reidinger napsal(a):
Ok, that's probably too much... What about 120? Personally I think the 80 chars limit does not make much sense with wide screen LCDs anymore...
wide screen LCD do not help you in textmode with 80 chars width terminal. Also it is not so easy to get code that is on so long line. In general need for such long line is code smell :)
OK, I limited the length to 100 and fixed few longer lines. Going down to 80 is not that easy, rubocop reports 320 errors...
Yes, for existing code which uses too many too long lines we may need to relax a bit, but in general, let me quote https://github.com/SUSE/style-guides/blob/master/Ruby.md#code-layout
Suppose there is an advantage when using longer lines, e.g. there are less lines or the formatting is just "nicer". Then the 80 columns rule comes at a cost for developers having a "modern" environment. The "rationale" in the coding style surely avoids such balancing and thus should just be burned. Regards, Arvin -- Arvin Schnell, <aschnell@suse.de> Senior Software Engineer, Research & Development SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 28.11.2014 11:16, Arvin Schnell wrote:
Suppose there is an advantage when using longer lines, e.g. there are less lines or the formatting is just "nicer". Then the 80 columns rule comes at a cost for developers having a "modern" environment.
The "rationale" in the coding style surely avoids such balancing and thus should just be burned.
I often try to reach those 80 cols rule, but I prefer descriptive class, method and variable names. This rule made a lot of sense when there were 1024x768 displays all over the place. IMO it's good to have "some" limit, but 80 is insanely low. Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 28.11.2014 v 14:05 Lukas Ocilka napsal(a):
I often try to reach those 80 cols rule, but I prefer descriptive class, method and variable names.
This rule made a lot of sense when there were 1024x768 displays all over the place.
BTW the rule is much older than 1024x768 displays, it is a legacy from 9-pin dot matrix printers and the first text terminals... -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Fri, Nov 28, 2014 at 02:05:37PM +0100, Lukas Ocilka wrote:
On 28.11.2014 11:16, Arvin Schnell wrote:
Suppose there is an advantage when using longer lines, e.g. there are less lines or the formatting is just "nicer". Then the 80 columns rule comes at a cost for developers having a "modern" environment.
The "rationale" in the coding style surely avoids such balancing and thus should just be burned.
I often try to reach those 80 cols rule, but I prefer descriptive class, method and variable names.
This rule made a lot of sense when there were 1024x768 displays all over the place. IMO it's good to have "some" limit, but 80 is insanely low.
I have already pointed out the SUSE style guide. Let us see what the community Ruby style guide says: - Limit lines to 80 characters. https://github.com/bbatsov/ruby-style-guide#80-character-limits I don't want to be dogmatic. Whatever we agree on. A practical example that I encountered last week: https://github.com/yast/yast-yast2/commit/b3ff10aebd39aa0a446e6d7004fbe5821e... As you can see, you cannot see the text because the GitHub formatting cuts it off. (On my 1920 pixel wide display, the diff viewport is 820 pixels no matter how I resize the browser window.) I solved it by applying the style guide rule and made it fit to 80 columns, since I was editing the text anyway. If not "80 columns", what rule should we use, if any? -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On 1.12.2014 10:01, Martin Vidner wrote:
A practical example that I encountered last week:
https://github.com/yast/yast-yast2/commit/b3ff10aebd39aa0a446e6d7004fbe5821e...
As you can see, you cannot see the text because the GitHub formatting cuts it off. (On my 1920 pixel wide display, the diff viewport is 820 pixels no matter how I resize the browser window.) I solved it by applying the style guide rule and made it fit to 80 columns, since I was editing the text anyway.
If not "80 columns", what rule should we use, if any?
1. Use common sense 2. IMO 80 columns should be a recommendation not a hard-stop 3. Sometimes it makes sense to have more than 80 columns, obviously, as we now use GitHub, it might make sense to "limit" number of columns to fit the tool view. Although this sounds a little bit illogically :) In other words: 80 is NTH, not REQ Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 01 Dec 2014 10:52:06 +0100 Lukas Ocilka <lukas.ocilka@suse.com> wrote:
On 1.12.2014 10:01, Martin Vidner wrote:
A practical example that I encountered last week:
https://github.com/yast/yast-yast2/commit/b3ff10aebd39aa0a446e6d7004fbe5821e...
As you can see, you cannot see the text because the GitHub formatting cuts it off. (On my 1920 pixel wide display, the diff viewport is 820 pixels no matter how I resize the browser window.) I solved it by applying the style guide rule and made it fit to 80 columns, since I was editing the text anyway.
If not "80 columns", what rule should we use, if any?
1. Use common sense
2. IMO 80 columns should be a recommendation not a hard-stop
3. Sometimes it makes sense to have more than 80 columns, obviously, as we now use GitHub, it might make sense to "limit" number of columns to fit the tool view. Although this sounds a little bit illogically :)
In other words: 80 is NTH, not REQ
Bye Lukas
I agree that 80 should be NTH, but rubocop require hard rule. I think we should also have hard rule, otherwise we can end up like in bootloader where is line with 299 chars and it is very very hard to read such line. For me hard rule should be something between 100-120 chars and only when it make sense as it is hard to read such line. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, Dec 01, 2014 at 10:57:16AM +0100, Josef Reidinger wrote:
On Mon, 01 Dec 2014 10:52:06 +0100 Lukas Ocilka <lukas.ocilka@suse.com> wrote:
On 1.12.2014 10:01, Martin Vidner wrote:
If not "80 columns", what rule should we use, if any?
1. Use common sense
2. IMO 80 columns should be a recommendation not a hard-stop
3. Sometimes it makes sense to have more than 80 columns, obviously, as we now use GitHub, it might make sense to "limit" number of columns to fit the tool view. Although this sounds a little bit illogically :)
In other words: 80 is NTH, not REQ
For the record, I can see 107 characters in the GitHub view ;-)
I agree that 80 should be NTH, but rubocop require hard rule.
That is customizable: "Cops can customize their severity level. All cops support the Severity param. Allowed params are refactor, convention, warning, error and fatal." rubocop --fail-level Minimum severity for exit with error code Metrics/LineLength has "convention" severity.
I think we should also have hard rule, otherwise we can end up like in bootloader where is line with 299 chars and it is very very hard to read such line. For me hard rule should be something between 100-120 chars and only when it make sense as it is hard to read such line.
-- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On Mon, 1 Dec 2014 11:18:04 +0100 Martin Vidner <mvidner@suse.cz> wrote:
On Mon, Dec 01, 2014 at 10:57:16AM +0100, Josef Reidinger wrote:
On Mon, 01 Dec 2014 10:52:06 +0100 Lukas Ocilka <lukas.ocilka@suse.com> wrote:
On 1.12.2014 10:01, Martin Vidner wrote:
If not "80 columns", what rule should we use, if any?
1. Use common sense
2. IMO 80 columns should be a recommendation not a hard-stop
3. Sometimes it makes sense to have more than 80 columns, obviously, as we now use GitHub, it might make sense to "limit" number of columns to fit the tool view. Although this sounds a little bit illogically :)
In other words: 80 is NTH, not REQ
For the record, I can see 107 characters in the GitHub view ;-)
I agree that 80 should be NTH, but rubocop require hard rule.
That is customizable:
"Cops can customize their severity level. All cops support the Severity param. Allowed params are refactor, convention, warning, error and fatal."
rubocop --fail-level Minimum severity for exit with error code
Metrics/LineLength has "convention" severity.
Interesting. Can we have something like 80 convention and 105 error, so separated severity? Josef
I think we should also have hard rule, otherwise we can end up like in bootloader where is line with 299 chars and it is very very hard to read such line. For me hard rule should be something between 100-120 chars and only when it make sense as it is hard to read such line.
Hello, On Dec 1 10:01 Martin Vidner wrote (excerpt):
https://github.com/yast/yast-yast2/commit/b3ff10aebd39aa0a446e6d7004fbe5821e...
As you can see, you cannot see the text because the GitHub formatting cuts it off.
Webdesign with fixed width results inappropriate usability. When the design cuts off content the desing is plain broken. In this case the design does not actually cut off content because there is a horizontal scroll bar at the bottom but its usability is bad. FYI: For comparison and fun, see http://motherfuckingwebsite.com/ ;-)
If not "80 columns", what rule should we use, if any?
For me https://github.com/SUSE/style-guides/blob/master/Ruby.md looks perfectly reasonable: ---------------------------------------------------------------------- For every rule there is a situation when it makes sense to break it. ... Wrap lines at 80 columns. This is not a hard rule... (e.g. you are embedding a long URL). ---------------------------------------------------------------------- There cannot be hardcoded tests for "rules" that are not hard rules because any hardcoded test would be an annoyance when it falsely complains about situations where it makes sense to break the rules. Even if a hardcoded test would only complain about lines > 200 chars, that test would be an annoyance for all fixed strings > 200 chars like long URLs, long paths, long IDs, and so on. Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 1.12.2014 v 10:01 Martin Vidner napsal(a):
- Limit lines to 80 characters. https://github.com/bbatsov/ruby-style-guide#80-character-limits
Unfortunately there is no rationale for it or any details why... [...]
https://github.com/yast/yast-yast2/commit/b3ff10aebd39aa0a446e6d7004fbe5821e...
As you can see, you cannot see the text because the GitHub formatting cuts it off. (On my 1920 pixel wide display, the diff viewport is 820 pixels no matter how I resize the browser window.) I solved it by applying the style guide rule and made it fit to 80 columns, since I was editing the text anyway.
I have tested it [1] and GitHub is able to display about 110-115 characters per line (depending on the browser, in chrome I could see 111 characters, in Firefox 115, but might depend on available fonts, display resolution etc...) So from the GitHub POV the practical limit seems to be 110 characters. [1] https://github.com/lslezak/yast-ntp-client/pull/3/files - -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUfEF4AAoJEHHp6jkF1zbPn9kH/Ar79ASTcYVbKAgJXTxV5rOS GMD16k+mmZQ8WzaodzJoXEcRAUOgr75DAV+h587dUSsMNbwLEUH1wBHIZ3I6L0T4 jeEruHx4dps79PQqJE+TGP9PWobaYibLsZZ2+n0Qv5NPlW5eXlCUsRct3v1HY/kU 3I1UJbOTc5C6PAEskQNjE4CaeMXh/SRPsEo+JWZUQOxm2FUCAkD1axh+aoQQtyDk XIp3tYqdAz6cYsU0+bDLGS2w1ijOMfFeApksNxhjiCtsQupddyqSuqrmnIKXzot1 lzPHskrlqzE3i1+NYx/O3L/vavnIVfJd4DBFz90A5fFjnZ1ehSdyjvNw4O9unpw= =cZUd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 12/01/2014 11:22 AM, Ladislav Slezak wrote:
Dne 1.12.2014 v 10:01 Martin Vidner napsal(a):
- Limit lines to 80 characters. https://github.com/bbatsov/ruby-style-guide#80-character-limits
Unfortunately there is no rationale for it or any details why...
[...]
https://github.com/yast/yast-yast2/commit/b3ff10aebd39aa0a446e6d7004fbe5821e...
As you can see, you cannot see the text because the GitHub formatting cuts it off. (On my 1920 pixel wide display, the diff viewport is 820 pixels no matter how I resize the browser window.) I solved it by applying the style guide rule and made it fit to 80 columns, since I was editing the text anyway.
I have tested it [1] and GitHub is able to display about 110-115 characters per line (depending on the browser, in chrome I could see 111 characters, in Firefox 115, but might depend on available fonts, display resolution etc...)
So from the GitHub POV the practical limit seems to be 110 characters.
Independently from GitHub (just the tool we are using today), 100 sounds like a reasonable hard limit. It's already 25% more than the agreed 80 soft* limit. Cheers. * Soft meaning "no Rubocop fatal error" no "feel free to ignore". -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On Dec 1 11:22 Ladislav Slezak wrote (excerpt):
https://github.com/yast/yast-yast2/commit/b3ff10aebd39aa0a446e6d7004fbe5821e...
On my 1920 pixel wide display, the diff viewport is 820 pixels no matter how I resize the browser window. ... I have tested it [1] and GitHub is able to display about 110-115 characters per line (depending on the browser, in chrome I could see 111 characters, in Firefox 115, but might depend on available fonts, display resolution etc...) So from the GitHub POV the
Dne 1.12.2014 v 10:01 Martin Vidner napsal(a): practical limit seems to be 110 characters. [1] https://github.com/lslezak/yast-ntp-client/pull/3/files
My Firefox shows at https://github.com/lslezak/yast-ntp-client/pull/3/files only -------------------------------------------------------------------- +01234567890123456789012345678901234567890123456789012345678901234 -------------------------------------------------------------------- i.e. only 66 characters. There is no such thing as a "practical value" for stubborn webdesign with a useless fixed main text viewport width specified in pixels. When text width is a fixed pixel value it results that it depends on the particular user's browser font how many characters fit into a fixed pixel value. I wished you could keep the reasonable freedom of the ideas behind https://github.com/SUSE/style-guides/blob/master/Ruby.md instead of following the bad ideas behind a fixed value (web)design. Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Nov 25, 2014 at 01:27:35PM +0100, Josef Reidinger wrote:
On Tue, 25 Nov 2014 13:14:32 +0100 Ladislav Slezak <lslezak@suse.cz> wrote:
Dne 25.11.2014 v 10:51 Josef Reidinger napsal(a):
Is there reason to use new lambda syntax?
Not really, our style guide does not mention this and the upstream style guide (https://github.com/bbatsov/ruby-style-guide#lambda-multi-line) suggests using ->() for single line functions and "lambda" for multi-line.
My approach here is: if it is not in our style guide, lets use the upstream one. And if we don't like the upstream default then adapt our style...
I'm not strict here, if we decide to not use ->() at all I'm fine with that....
It can be intersting how others see it.
I think we should not reinvent the wheel, so we should follow the upstream style guide. Regarding understandability by newbies, I tried - https://duckduckgo.com/?q=-%3E%28%29 No luck, even on Google. See also https://support.google.com/websearch/answer/2466433?hl=en&p=g_punctuation - https://duckduckgo.com/?q=ruby+dash+greater+than Finds the answer, and also points to - http://symbolhound.com/?q=-%3E%28%29 -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
Dne 25.11.2014 v 10:51 Josef Reidinger napsal(a): [...]
when I see this change ( https://github.com/yast/yast-registration/commit/3e89195d3938d04c3de39b2a5a9... ), I am not sure if it helps with readability. I think better change is to change it to
if ret == :skip && confirm_skipping log.info "Skipping registration on user request" @registration_skipped = true break end end
in general I am not sure if it is wrong to use return in loops. What is rationale behind?
It actually complained because of the extra "if" block. It's similar to the usual "if" guard clauses: if something return if !something do_something ---> do_something end The requested change is this: while foo while foo if something next if !something do_something ---> do_something break break end end end It saves one indentation level. -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
I took opurtunity and try rubocop on legacy yast module like bootloader. Result of my attempt is visible at https://github.com/yast/yast-bootloader/pull/202 so now it is possible to compare how configuration file can look for legacy module. Few notes: - some decisions are my personal code style taste. We should unify it. - I intentionally make difference between new code in src/lib and rest. This is really cool that rubocop allows it. E.g. old code longest line is 299 chars, new code have 120 and can be decreased after some cleaning. Same apply for metrics. - auto-correct feature is really cool, but in few cases I found bugs there. - some options are really nice tunable - integration with travis is really cool - it took me two days to fine tune configuration, but I think that when we agreed on style, then only metrics should be tuned to prevent getting module into worser state I welcome any comments, Josef On Mon, 24 Nov 2014 19:56:00 +0100 Ladislav Slezak <lslezak@suse.cz> wrote:
Hi all,
I looked at Rubocop (a Ruby code scanner) [1] and tried to use it in the registration module to see if it could be used in Yast to improve the code quality.
I have summarized my findings in a blog post [2], in short:
- it is highly configurable - it can find also some semantic issues - it suggests how to fix the found issues - it can auto correct many issues (esp. indentation and white space)
You can see the found issues and fixes in this pull request [3]. Many issues were just harmless indentation or white space issues, but some were quite critical like this "private" attribute misuse [4]. Majority of the issues were autocorrected by Rubocop itself, I just reviewed the changes and committed each fix in a separate commit to see what was the problem and how it was fixed.
What do you think about Rubocop and Yast? Would it make sense to use it globally for all modules? What would be the pros and cons for you? Would you like to fix the coding issues in the existing code?
Thanks for your feedback!
[1] https://github.com/bbatsov/rubocop [2] http://lslezak.blogspot.cz/2014/11/using-rubocop.html [3] https://github.com/yast/yast-registration/pull/177 [4] https://github.com/yast/yast-registration/commit/4f4819838723e7ddd7598976db2...
--
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 To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (8)
-
Ancor Gonzalez Sosa
-
Arvin Schnell
-
Jiri Srain
-
Johannes Meixner
-
Josef Reidinger
-
Ladislav Slezak
-
Lukas Ocilka
-
Martin Vidner