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
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
Hi,
As Gabi has pointed-out today, we have a growing list of bugs reported
for Yast, assigned to the default assignee: yast-maintainers. Some of
the bugs cannot be fixed easily now as we do not have a single person
who would take care about "that particular module", "usability" or "design".
For me, this is a perfect way for fixing bugs in an agile way:
- Project manager decides what needs to be fixed and when
- We will find out who can fix or which expertise we need
- And we'll either assign these bugs to respective people in time or try
to find help outside
But we need to find a way how not to get lost in bugs assigned to
yast-maintainers. And there are several possibilities:
1. NEW bug needs to be checked and either reassigned or at least marked
as reviewed/confirmed
2. CONFIRMED bug should have a [yast2-*] in Summary, so we know it has
been reviewed already / or we could add new keyword e.g. "reviewed". The
current "Yast Maintainer" must make sure that summary describes the
issue well
3. IN_PROGRESS should have a real assignee, this would need cooperation
with PjM/PM, so they set real priority
4. We will definitely not be able to fix all bugs, so there needs to be
a way to drop as CANTFIX/WONTFIX according to given criteria
5. Features should be closed as FEATURE and the reported advised to use
FATE.
6. Yast maintainer should take care only about bugs that haven't been
reviewed, for that a simple search should be possible (e.g.: doesn't
contain `reviewed` flag)
Please review, and/or come with better ideas. I know this is yet another
rule-set, maybe you'll have a better idea.
Bye
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
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-dns-server:
- New version for maintenance update (22 days)
https://github.com/yast/yast-dns-server/pull/33
Pending requests in repository yast-kdump:
- get rid of autotools (24 days)
https://github.com/yast/yast-kdump/pull/23
Pending requests in repository yast-network:
- [Review] Request from 'schubi2' @ 'yast/yast-network/review_141001_autoyast_do_not_overwrite_firewall_settings' (23 days)
https://github.com/yast/yast-network/pull/260
Pending requests in repository yast-openvas-security-scanner:
- Travis support (6 days)
https://github.com/yast/yast-openvas-security-scanner/pull/2
Pending requests in repository yast-theme:
- Install scalable icons & fix name of yast-yast-language.* to yast-language.* (63 days)
https://github.com/yast/yast-theme/pull/45
Pending requests in repository yast-services-manager:
- Change the target proposal warning level to none | bnc#875652 (66 days)
https://github.com/yast/yast-services-manager/pull/85
Pending requests in repository yast-docker:
- Start making this a gem (24 days)
https://github.com/yast/yast-docker/pull/2
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Greetings,
My name is Daniel and would like to have the privilege of helping you generate additional revenue by offering our cutting-edge web, seo and software services to you.
Would you be interested in a possible redesign of your site or additional features that might benefit the overall usability and user experience which usually leads to increased leads and sales?
You will be able to get emails such as info(a)yourcompany.com, sales(a)yourcompany.com, or
yourname(a)yourcompany.com and much more
Custom Dynamic Web Design starting from Ksh.s 10,000 - Mobile enabled
We also have
CRM - Customer Relationship management system
AMS - Asset Management System
DMS - Document Management System
HRM - Human Resource Planning
PMS - Project Management System
ERP - Enterprise Resource Planning management System
View some of the latest web design projects: http://www.goldenjuices.comhttp://www.eclipsevaluers.comhttp://www.interlab.co.ke
Contact Details: +254(0)703 745 484 | +254(0)724 566 088 | +254 (0) 722 533771 Location: 4th Floor, Dev Towers, Biashara Street, Nairobi Kenya.
Note: - Though this is not an automated email, we keep on sending out these emails to all those people whom we find eligible of using our services.
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I'm checking the current implementation of Travis support in Yast, which
is a great idea indeed.
One little issue I have is what the before_install: contains:
- curl
http://download.opensuse.org/repositories/YaST:/Head:/Travis/xUbuntu_12.04/…
| sudo apt-key add -
- echo "deb
http://download.opensuse.org/repositories/YaST:/Head:/Travis/xUbuntu_12.04/
./" | sudo tee -a /etc/apt/sources.list
From my POV, the "xUbuntu_12.04" is a constant used for ALL Yast module
and maybe even the whole before_install: section. So, I was thinking
about this: what will happen when we start using newer version of
Ubuntu? Will we need to change all .travis.yml files at once? Why this
is not solved by a simple script, e.g. [#1]:
- prepare_travis yast2-devtools yast2-testsuite \
yast2-perl-bindings yast2 yast2-pam
Then we would just need to update one place (the script itself) that
would start downloading Release.key from somewhere else.
Automation is a great thing, but additional work in the future should be
IMO limited.
So, what do you think of the proposal?
Thanks
Lukas
#1 https://github.com/yast/yast-samba-client/pull/34/files
--
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