Feature added by: Hendrik Vogelsang (hennevogel)
Feature #306624, revision 1
Title: voting mechanism for membership approval on users.o.o
Hackweek IV: Unconfirmed
Requested by: Hendrik Vogelsang (hennevogel)
To be better able to vote on membership approvals the openSUSE board is looking for some ruby hacker willing to implement a voting mechanism in users.opensuse.org. users.o.o is a ruby on rails application.
Pepple that want to become openSUSE members fill out an application form in users.o.o. This is then evaluated by the openSUSE board. Each application is voted upon. What is missing in users.o.o is the possiblity to vote on those applications. This would need a couple of things:
Each application needs a state attribute with the following content: * New * To be Accepted * Accepted * To be Rejected * Rejected
Also the respective listings in the interface are needed.
And for each board member an voting field. (+1,0,-1) coupled with a free text field.
Feature added by: Alin M Elena (ealin)
Feature #307436, revision 1
Title: Backup utility
Requested by: Alin M Elena (ealin)
Would be nice if we can have an user backup application by default in kde4.
I propose back-in-time
it has both kde4 and gnome interfaces and is relatively simple to use.
Feature changed by: Claudio Freire (klaussfreire)
Feature #304951, revision 6
Title: Automated tests for .deb packages
Requested by: Marko Jung (markojung)
Partner organization: openSUSE.org
As we already have rpmlint integrated into the build service, we also
should integrate the corresponding debian checks to the build system.
Debian offers three tools for automated checks:
* lintian (http://lintian.debian.org/)
* linda (http://people.debian.org/~stevenk/linda/)
* debdiff (from devscripts)
Further information on automated package tests can be found in Section A.2 of
the Debian Developer's Referemce (http://www.debian.org/doc/developers-reference/ap-tools.en.html#s-tools-lint)
Business case (Partner benefit):
openSUSE.org: For the (trust) metrics project we need as many
statistical information we can get. Therefore we should add as many
automated tests as possible to our system.
+ #1: Claudio Freire (klaussfreire) (2012-05-07 08:26:00)
+ Shouldn't this be doable in prjconf at the project level? Any
+ documentation about this so I could try? (I'd be interested in trying)
Feature added by: The Liberator (L1B3RAT0R)
Feature #309311, revision 1
Title: GUI for PAM
Package Wishlist: Unconfirmed
Requested by: The Liberator (l1b3rat0r)
I would like to see some kind of YAST-like tool for implementing PAM features for all types of logins.
As it is now you can attempt unlimited logins via the terminal or a locked KDE screen.
If there was a GUI for PAM that allowed the user to set maximum password tries, time-frames that login is allowed, and how long a session can last, then our computers would be much more secure.
I have an encrypted hard drive, but once the computer is booted up and the hard drive is decrypted, I have no way of stopping a brute force attack.
For the average user, PAM is too complicated to use all its features without reading for hours.
This seems like the perfect feature to add to YAST.