I want to fix yast2-slide-show for SLE11 SP3. Which git commands do I
have to use, please?
Thus far, I have checked out trunk only.
--
Karl Eichwalder SUSE LINUX Products GmbH
R&D / Documentation Maxfeldstraße 5
90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
in this blog post
http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3 is
summary of changes in new rspec 3.0. I do not think that we will use it
for SLE-12 tests, but maybe it will be used for 13.2. In general I
think we should not use new syntax now, but what we can do is to not
use deprecated syntax as there is already alternatives to prevent
future problems.
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
while reassigning yast-maintainers bugs I noticed that once again
the maintainer/bugowner information is inconsistent: The content
of the MAINTAINER file in git differs from the output of 'osc
maintainer' or 'osc bugowner'. This leads to confusion.
We had this problem before and apparently fail to solve the
inconsistency long term. So I propose to drop the MAINTAINER file
in git and rely on osc.
Instead we can have a AUTHORS files so that people not knowing
about osc can still reach the authors.
Regards,
Arvin
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
We have been discussing the current usability problems in all modules
that manages servers taking this dns-server screenshot as starting
point. http://paste.opensuse.org/51547407
We mainly have two problems:
- Users expect different effects on running/stopped
after changing enabled/disabled (and vice versa).
- Sometimes is not so clear when settings should be written to
configuration files and when that configuration should be applied to
a running server (service reload).
I'll try to summarize a possible solution after listening to QA team and
SUSE's UX team. For details check [1]
1) Change the UI for enabling/disabling. We don't need a box with radio
buttons. It would it better to have a single checkbox.
[X] Start DNS server when booting
2) Remove the "reload" button in its current form
3) Add a button [Apply current settings] which works exactly like "ok"
but without quitting. Initially disabled. Enabled once the user has
changed something.
4) Use pop-ups to ask the user about their intentions when saving
changes or running the server. A subtle but important detail - the goal
of the pop-ups is exposing functionality and offering options, not
warning about something that some users can perceive as problems (and
others don't).
4.a) User changed any configuration and clicked on "Start Server Now".
Show dialog with "changes are pending" message and two options:
"Cancel" and "Save Settings and Start Server Now".
4.b) User changed any configuration and clicked "ok" or "apply":
First of all, save settings to configuration files.
Next step depends on current situation:
a) Server is not running
Ask the user if they would like to start the server now
b) Server is running and “start when booting” is marked
Reload the server
c) Server is running and “start when booting” is not marked
Ask the user if they would like to stop the server now.
If they decide to keep it running, reload the server.
What do you think? I'd say it makes a lot of sense. But I'm not sure how
the reloading of setting is currently managed in most cases and if
somebody could complain about the settings being "immediately" effective
on already running services.
Cheers.
[1]
https://trello.com/c/Xu7BKag3/181-use-case-for-service-start-stop-enable-di…
--
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
A first prototype of the systemd journal reading module is available at:
https://github.com/ancorgs/yast-journal
It still does not include a Rakefile, so you'll have to do something
like this to play with it.
Y2DIR=src/ /usr/sbin/yast2 journal
It took me a little bit longer than expected because:
- I have been going back and forward with the UI design/implementation.
- I tried to mimic ActiveRecord as much as possible when querying the
journal. Turns out it was not a brilliant decision (as stated in
the comments of the SystemdJournal::Query class).
I'm sure the code contains a lot of newbie mistakes (specially in the UI
part) so let's find them all before we start writing a tutorial with
that code as a base :-)
I implemented the classes for retrieving and processing the journal
entries as pure ruby classes living in /lib. But I'm not sure if it's a
good decision. Wouldn't it be better to implement them as a module so it
can be accessed from other programming languages?
There are still a lot of usability problems and I still need a way to
make all this information visible [1], but it's just the first
prototype. I'm more worried right now about the architecture (lib vs
module) and the libyui usage mistakes/patterns.
[1]
https://github.com/ancorgs/yast-journal/blob/master/src/lib/systemd_journal…
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
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/4f4819838723e7ddd7598976db…
--
Best Regards
Ladislav Slezák
Yast Developer
------------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: lslezak(a)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(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet.
Pending requests in repository yast-kdump:
- get rid of autotools (22 days)
https://github.com/yast/yast-kdump/pull/23
Pending requests in repository yast-network:
- AY: added IPv6 option (bnc#633310) (8 days)
https://github.com/yast/yast-network/pull/270
Pending requests in repository yast-theme:
- Install scalable icons & fix name of yast-yast-language.* to yast-language.* (91 days)
https://github.com/yast/yast-theme/pull/45
Pending requests in repository yast-yast2:
- Use native Ruby implementations in Yast::URL and Yast::IP (9 days)
https://github.com/yast/yast-yast2/pull/305
Pending requests in repository yast-docker:
- fixed string substitution (15 days)
https://github.com/yast/yast-docker/pull/3
- Start making this a gem (52 days)
https://github.com/yast/yast-docker/pull/2
Pending requests in repository yast.github.io:
- Suggested Text Changes (13 days)
https://github.com/yast/yast.github.io/pull/30
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
As I said in the team call, I want to avoid uncertainty and
inconsistencies, so please let's come to an agreement about Git
branches for openSUSE 13.2.
Branch Name
-----------
openSUSE-13_2
This is the only clear thing :)
Global or Individual
--------------------
Do we want to make the branches globally in all repos at once, or
leave it to the individual maintainers?
I think that depends on how we want Jenkins and Travis to work,
which I don't know, see below.
Jenkins
-------
Recall that for SLE 12 in IBS we have
- Devel:YaST:Head
- Devel:YaST:SLE-12
But in OBS we have always had just YaST:Head, with no dedicated
maintenance project.
OTOH the Jenkins jobs for Devel:YaST:SLE-12 are failing anyway (all
of them except 2) so how is this supposed to work??
Travis
------
With the current setup,
Travis will build PRs to the openSUSE-13_2 branch with dependencies
from master which is wrong, giving false positives and false
negatives.
--
Martin Vidner, Cloud & Systems Management Team
http://en.opensuse.org/User:Mvidner
Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
