Dne 25.11.2014 v 09:12 Jiri Srain napsal(a):
> 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?
This Rubocop check does not support autocorrection, it only reports an error, it's up
to the developer to fix it properly. So *we* have to check before renaming...
--
Ladislav Slezák
Appliance department / YaST Developer
Lihovarská 1060/12
190 00 Prague 9 / Czech Republic
tel: +420 284 028 960
lslezak(a)suse.com
SUSE
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
my hackweek project was to evaluate using the boost graph library
(BGL) in libstorage. For me the project was interesting and
successful. I have documented it at
https://github.com/aschnell/libstorage-bgl-eval/wiki. The code is
also available there.
So now I would like to redesign the storage part of YaST. Here
are the main steps required:
- Extend libstorage-bgl-eval to fully support disks, partitions
and simply filesystems (probing, committing, testmodes,
testsuite).
- Try to make a compatibility layer.
- Make the new API robust against API and ABI changes.
- Export new API to Ruby (help would be good) for use by all YaST
modules.
- Get a simply installation working (two partitions, ext4 and
swap).
- Extend libstorage-bgl-eval to current libstorage
functionality. Maybe drop a few features, e.g. loop-back
devices (once used for encryption).
- Make the new API suit the needs of all YaST modules (input from
other developers required). If required add utility functions.
- Make all code in YaST use new API (task for several
developers).
- Make expert partitioner use new features, e.g. use disks
without partition table for filesystems.
- Rewrite storage proposal (specification required!).
- Finally drop target-map (as decided during workshop).
- Drop compatibility layer.
In the end yast2-storage would ideally only contain dialogs and
no logic for other YaST modules (since all of that moved to
libstorage). But if some utility functions are easier to
implement in Ruby they can stay there.
I assume that altogether the redesigning will take more than half
a year. Anyway I think it is required to keep the code
maintainable and be prepared for new feature requests. Some
existing features request might already be implemented along the
way (e.g. https://fate.suse.com/316251).
ciao
Arvin
--
Arvin Schnell, <aschnell(a)suse.de>
Senior Software Engineer, Research & Development
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(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
The view_anymsg client is not that useful anymore now that systemd has
replaced the good old plain text logs with journalctl. An easy fix to
avoid the view_anymsg failure would be to make sure that view_anymsg
ensures the installation of any package providing syslog. But that's
just a workaround. I miss a journalctl module for YaST (and I would use
it, journalctl usage is a pain in the **s).
So my plan is to write a new module for journalctl from scratch
documenting the process (looks easy but complete enough to be a
tutorial). Anybody against it? Any advise?
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Moin,
I've promised you to find out how to properly fix a bug that could need
a different text in UI. There are actually two cases:
1.) "Cosmetic fix" - if just changing the text a bit helps to resolve
the issue, translators can create different translations for en_US
and en_GB "translation". It doesn't break other translations
instantly and they could be adapted one by one.
2.) If a bigger change is needed - change in logic, new text, etc.,
then translators will have to get that new text and translate it
for as many languages as possible.
In both cases, open NEW bug by cloning the current one (if it exists)
and assign it to component "Translations" with the default assignee. If
the text is not that visible, the translation itself might wait for SLE
12 SP1, resp. SLE 11 SP4.
Thanks
Lukas
--
Lukas Ocilka, Systems Management (Yast) Team Leader
Cloud & Systems Management Department, SUSE Linux
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hey guys,
Would you consider adding YaST to https://build.opensuse.org and if it
is already there, can you add RedHat, Fedora, CentOS and even Devian
based Linux to the targets?
Thanks.
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
