March 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305673] openFATE - link account names to users.o.o
by fate_noreply＠suse.de 30 Mar '09

30 Mar '09

Feature changed by: Juergen Weigert (jnweiger) Feature #305673, revision 7 Title: openFATE - link account names to users.o.o openFATE: Evaluation Priority Requester: Mandatory Requested by: Klaas Freitag (kfreitag) Partner organization: openSUSE.org Description: User account names in openFATE should be a link to the according user.o. o page. Business case (Partner benefit): openSUSE.org: Better integration of the openSUSE tools + Discussion: + #3: Juergen Weigert (jnweiger) (2009-03-30 15:18:19) + I'll check. -- openSUSE Feature: https://features.opensuse.org/305673

1 0

[openFATE 305841] Be able to add proxy setting, choose network card and set wifi setting via Fx.
by fate_noreply＠suse.de 30 Mar '09

30 Mar '09

Feature added by: Joop Boonen (worldcitizen) Feature #305841, revision 1, last change by Title: Be able to add proxy setting, choose network card and set wifi setting via Fx. openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: Be able to add proxy setting, choose network card and set wifi setting via one of the F(1..12) keys in the install screen. I think it'll be easier for less experienced users to install openSuSE via ftp/http when they are behind a proxy and firewall, want to user a certain network card and/or want to install via wifi. -- openSUSE Feature: https://features.opensuse.org/305841

1 2

[openFATE 302628] Access to encrypted devices/partitons by dongle
by fate_noreply＠suse.de 30 Mar '09

30 Mar '09

Feature changed by: Ludwig Nussel (lnussel) Feature #302628, revision 30 Title: Access to encrypted devices/partitons by dongle openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-31 10:53:14 reject reason: too late - and still lacking a real concept behind the full story. Priority Requester: Desirable openSUSE-11.1: Rejected by Stephan Kulow (coolo) reject date: 2008-08-07 16:27:08 reject reason: out of resources. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Stefan Fent (sfent) Description: Think of the following scenario: You store your files on an encrypted partition and if you want to access them you just insert your USB stick, flash card or whatever and gain access to your files. Another thought would be to encrypt the whole system and the only possibilty to access it is via dongle. Relations: - FATE#301352: Filesystem encryption using Smartcard certificate (feature/id: 301352) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2007-10-05 23:04:19) Michele (desktop) / Matthias (storage) what do you think about this? #2: Michael Löffler (michl19) (2008-01-02 18:27:26) Nice to have but I miss a business case. #3: Stephan Kulow (coolo) (2008-01-07 14:42:28) (reply to #2) the business case of such a feature only works if you have a company to sell those dongle sticks I'd say. And those dongle vendors prefer custom boot loaders from those I know. So I don't think a solution with a stick that can be easily copied by dd is preferrable and I would rather reject this. #4: Guy Lunardi (glunardi) (2008-01-18 19:46:42) It's my understanding that Chris' work would allow for this to happen. This would be very neat indeed, we have discussed this with several customers who expressed interest. Using a simple USB key would be one inexpensive way to make this work. One alternative that a customer asked was to have the ability to unlock the data using certificates strored within a smart card. #7: Stephan Kulow (coolo) (2008-06-27 11:23:16) (reply to #4) Chris work? I fail to see the context. #9: Guy Lunardi (glunardi) (2008-07-02 15:27:37) (reply to #7) I do believe that Chris' work would be good for us to leverage however I do not know the details and could be wrong since it has been a few months now since we last talked about this. Chris, would you be able to assist me with provide insights on ways we could address this? #11: Chris Rivera (chrismrivera) (2008-07-06 23:52:49) (reply to #9) If you setup an encrypted home directory with cryptconfig it defaults to creating an encrypted container and a key file. The key file can reside anywhere, including removable media. If you use removable media you need to setup an fstab entry using the device label or device UUID to ensure that the dongle gets mounted automatically and the key file is in the right location. #12: Stephan Kulow (coolo) (2008-08-07 16:26:44) (reply to #11) ok, just talked about with Chris about this feature. We have no resources for yast work any more and the work required seem to be this: "so it would just mean moving the .key file to the media, changing the . key file location in pam_mount.conf, and adding an fstab entry" (quoting Chris). So this would be either put in a README or we wait for SPx. #13: Stephan Kulow (coolo) (2009-03-04 11:39:07) (reply to #12) any objection against opening this to openSUSE.org? #14: Marcus Meissner (msmeissn) (2009-03-04 11:40:59) (reply to #13) no, done #5: Stephan Kulow (coolo) (2008-03-31 10:52:41) I still have no clear picture of what cryptfs setups we're going to support - there are various fate entries about it: e,g, 302981 and 301352. So I would like PM to sort this out - and I personally think it's too late for 11.0. #6: Matthias Eckermann (mge1512) (2008-04-01 01:35:14) In an ideal world we would support: * TPM (incl. fingerprint readers etc.) * Smart Cards * simple devices with key on (USB sticks, memory cards) * passphrase (as today) * (optional) integration with a directory (LDAP, eDirectory, ...) #15: Mario Goppold (mgoppold) (2009-03-29 22:26:03) Hi, because I just need to unlook my root partition via USB stick I have build an rpm for it: http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_… _SVNr46_luks_key-64.1.x86_64.rpm The main changes are in /lib/mkinitrd/scripts/{setup,boot}-luks.sh and the new /etc/sysconfig/initrd.luks_key. The LUKS-Keyfile should on an Labled or UUIDed USB-Stick. You can unlook all partitions with a master key or define a separate for every luks_device. The approach is certainly not the best but there is no keyscript in /etc/crypttab jet (why not?). + #16: Ludwig Nussel (lnussel) (2009-03-30 09:13:46) (reply to #15) + mind creating a patch against + http://git.opensuse.org/?p=projects/boot.crypto.git;a=summary so I can + have a look? I'm not really fond of supporting the keyscript option but + since debian now uses that askpass program that I like to integrate + we'd basically get keyscript support for free at least wrt boot.crypto. + For YaST it would be between hard and impossible to support as one can + never know what the keyscript does. -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 302628] Access to encrypted devices/partitons by dongle
by fate_noreply＠suse.de 29 Mar '09

29 Mar '09

Feature changed by: Mario Goppold (mgoppold) Feature #302628, revision 29 Title: Access to encrypted devices/partitons by dongle openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-31 10:53:14 reject reason: too late - and still lacking a real concept behind the full story. Priority Requester: Desirable openSUSE-11.1: Rejected by Stephan Kulow (coolo) reject date: 2008-08-07 16:27:08 reject reason: out of resources. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Stefan Fent (sfent) Description: Think of the following scenario: You store your files on an encrypted partition and if you want to access them you just insert your USB stick, flash card or whatever and gain access to your files. Another thought would be to encrypt the whole system and the only possibilty to access it is via dongle. Relations: - FATE#301352: Filesystem encryption using Smartcard certificate (feature/id: 301352) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2007-10-05 23:04:19) Michele (desktop) / Matthias (storage) what do you think about this? #2: Michael Löffler (michl19) (2008-01-02 18:27:26) Nice to have but I miss a business case. #3: Stephan Kulow (coolo) (2008-01-07 14:42:28) (reply to #2) the business case of such a feature only works if you have a company to sell those dongle sticks I'd say. And those dongle vendors prefer custom boot loaders from those I know. So I don't think a solution with a stick that can be easily copied by dd is preferrable and I would rather reject this. #4: Guy Lunardi (glunardi) (2008-01-18 19:46:42) It's my understanding that Chris' work would allow for this to happen. This would be very neat indeed, we have discussed this with several customers who expressed interest. Using a simple USB key would be one inexpensive way to make this work. One alternative that a customer asked was to have the ability to unlock the data using certificates strored within a smart card. #7: Stephan Kulow (coolo) (2008-06-27 11:23:16) (reply to #4) Chris work? I fail to see the context. #9: Guy Lunardi (glunardi) (2008-07-02 15:27:37) (reply to #7) I do believe that Chris' work would be good for us to leverage however I do not know the details and could be wrong since it has been a few months now since we last talked about this. Chris, would you be able to assist me with provide insights on ways we could address this? #11: Chris Rivera (chrismrivera) (2008-07-06 23:52:49) (reply to #9) If you setup an encrypted home directory with cryptconfig it defaults to creating an encrypted container and a key file. The key file can reside anywhere, including removable media. If you use removable media you need to setup an fstab entry using the device label or device UUID to ensure that the dongle gets mounted automatically and the key file is in the right location. #12: Stephan Kulow (coolo) (2008-08-07 16:26:44) (reply to #11) ok, just talked about with Chris about this feature. We have no resources for yast work any more and the work required seem to be this: "so it would just mean moving the .key file to the media, changing the . key file location in pam_mount.conf, and adding an fstab entry" (quoting Chris). So this would be either put in a README or we wait for SPx. #13: Stephan Kulow (coolo) (2009-03-04 11:39:07) (reply to #12) any objection against opening this to openSUSE.org? #14: Marcus Meissner (msmeissn) (2009-03-04 11:40:59) (reply to #13) no, done #5: Stephan Kulow (coolo) (2008-03-31 10:52:41) I still have no clear picture of what cryptfs setups we're going to support - there are various fate entries about it: e,g, 302981 and 301352. So I would like PM to sort this out - and I personally think it's too late for 11.0. #6: Matthias Eckermann (mge1512) (2008-04-01 01:35:14) In an ideal world we would support: * TPM (incl. fingerprint readers etc.) * Smart Cards * simple devices with key on (USB sticks, memory cards) * passphrase (as today) * (optional) integration with a directory (LDAP, eDirectory, ...) + #15: Mario Goppold (mgoppold) (2009-03-29 22:26:03) + Hi, because I just need to unlook my root partition via USB stick I + have build an rpm for it: http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_… + _SVNr46_luks_key-64.1.x86_64.rpm The main changes are in + /lib/mkinitrd/scripts/{setup,boot}-luks.sh and the new + /etc/sysconfig/initrd.luks_key. The LUKS-Keyfile should on an Labled or + UUIDed USB-Stick. You can unlook all partitions with a master key or + define a separate for every luks_device. The approach is certainly not + the best but there is no keyscript in /etc/crypttab jet (why not?). -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 303400] Allow to enable the backend error handler (beh) from the YaST printer module
by fate_noreply＠suse.de 27 Mar '09

27 Mar '09

Feature changed by: Johannes Meixner (jsmeix) Feature #303400, revision 12 Title: Allow to enable the backend error handler (beh) from the YaST printer module openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 09:39:42 reject reason: Postponing. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Lars Müller (lmuelle) Description: It should be possible to enable the backend error handler (beh) from the YaST printer module. This is usefull if a network printer isn't always reachable. Think of a printer switched on later than the startup of cups happens. + Discussion: + #1: Johannes Meixner (jsmeix) (2009-03-27 09:46:06) + I wonder why I am not included in such requests? + It is already implemented in the new yast printer module for openSUSE + 11.1 and accordingly also for SLE11 via the "Connection Wizard". + How to use it: + 0. Usually one would first set up the queue as usual (i.e. without + beh). + 1. In case of backend errors and when additionally the default error + handling is not what is wanted, one would first try if another CUPS + error policy helps. One can change the CUPS error policy in YaST via + "Policies". + 2. If even another CUPS error policy does not do what is wanted, one + could daisy-chain beh: Select the queue and "Edit" it. In the "Modify" + dialog select "Connection Wizard" and therein "Daisy-Chain Backend + Error Handler (beh)" usually leave the defaults for beh (or adapt them, + read the help text in YaST), klick "OK" to go back to the "Modify" + dialog. Now there is a new connection using "beh" available. Select + this new connection in the "Modify" dialog and klick "OK" to apply the + change to the queue. -- openSUSE Feature: https://features.opensuse.org/303400

1 0

[openFATE 302476] KDE notification for apparmor rejects
by fate_noreply＠suse.de 26 Mar '09

26 Mar '09

Feature changed by: Sascha Manns (saigkill) Feature #302476, revision 23 Title: KDE notification for apparmor rejects openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-26 17:30:24 Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:38:24 reject reason: Rejected due to lack of time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.2: Unconfirmed Priority - Requester: Desirable + Requester: Important Projectmanager: Desirable Requested by: Stephan Kulow (coolo) Description: fate #300563 added dbus event advertising. We'd need a KDE frontend for these dbus events that shows a notification of these events. Documentation Impact: Needs to be documented Discussion: #1: Stephan Binner (beineri) (2008-03-18 10:45:07) Just had a chat with Ludwig and Marcus about this topic (if it would be a nice SoC project) and they don't see much use in having such an applet on the desktop. #2: Marcus Meissner (msmeissn) (2008-03-20 14:52:14) (reply to #1) (background reasoning is: it would spend almost all of the time: doing nothing.) #4: Stephan Kulow (coolo) (2008-03-26 17:30:09) (reply to #2) such dbus callbacks are perfect kded modules - they would register a callback and be dead code after that and create a notification on callback. And it's half a day effort, not really SoC material. #3: Jared Allen (jpallen) (2008-03-20 13:56:50) I like the idea of using this as a SoC project. Let's consider this for openSUSE 11.1 #6: Stephan Binner (beineri) (2009-01-17 16:16:46) (reply to #3) Any objection to make this fate public for openSUSE.org partner and try to advertize it there? -- openSUSE Feature: https://features.opensuse.org/302476

1 0

[openFATE 305869] improve partioning UI during installation
by fate_noreply＠suse.de 26 Mar '09

26 Mar '09

Feature changed by: Martin Schmidkunz (mschmidkunz) Feature #305869, revision 8 Title: improve partioning UI during installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: The partitioning dialog during installation is perceived as confusing (see Bug #461819) . The reasons for confusion are * button labeling * workflow A redesign could provide some improvement. A first idea could be: http://en.opensuse.org/Image:Partitioner_proposal_installation.png References: https://bugzilla.novell.com/show_bug.cgi?id=461819 http://en.opensuse.org/Image:Partitioner_proposal_installation.png Discussion: #1: Kevin Dupuy (kdupuy9) (2009-03-26 00:06:41) I like the proposal so far. Perhaps there could also be some improvements wrt the actual partitioning interface, similar to GParted or the Ubuntu partitioner. This way it's easier for people that need to make a small change to YaST's proposal can do it easily. GParted: http://kajar.files.wordpress.com/2009/02/gparted-gui.jpg Ubuntu: http://1.bp.blogspot.com/_MfwRx_4ERx8/Sa6_M2URLeI/AAAAAAAAAxA/rEcbk5uSrhA/s… + #2: Martin Schmidkunz (mschmidkunz) (2009-03-26 16:35:44) (reply to #1) + By talking about the "actual partitioning interface" do you refer to + the (expert) partitioner module in YaST? (the one with the storage tree + on the left pane :-)) There are some improvements planed for this + interface. One of them refers to the use of the bar graph. In order to + use some of the design ideas proposed by gparted we would need to + extend bar graph widget at first (see FATE #303534: Extend BarGraph + Widget). -- openSUSE Feature: https://features.opensuse.org/305869

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 26 Mar '09

26 Mar '09

Feature changed by: Elmar Stellnberger ATK (estellnb) Feature #302159, revision 33 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. + #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) + One advantage will be that packages can be inspected by a prog. such as + mc in advance to installation or to manually take them apart by + rpm2cpio. Sometimes it is necessary to add special rpm-installation + options as --excludepath or --excludedocs to install several versions + of a single package for downward compatibility. Furthermore in + combination with an upcoming --arch switch it may enable to download + packages on a server to be installed on another system/machine. f.i. + the ati repo can not be browsed via http so that it is necessary to + download packages from it via zypper rather than a web browser. -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 26 Mar '09

26 Mar '09

Feature changed by: Ján Kupec (jkupec) Feature #302159, revision 32 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 - See also feature #300747 + See also feature #300747 and #305624 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 305489] default email in email applications
by fate_noreply＠suse.de 26 Mar '09

26 Mar '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305489, revision 14 Title: default email in email applications openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Martin Lasarsch (mlasars) Description: To get more subscriptions to the mailinglists it would be nice to have a "default mail" in the mail clients (evolution, kmail) which points the user to the mailinglists. Every openSUSE user should be subscribed to opensuse-announce at least. A simple reply to this "default mail" should subscribe to the list (so it's opt-in, no one should be forced). Of course there could be more information in it, like other important lists, pointing to the main list page. evolution have already a "default mail", with general information about evolution, kmail afaik not. - This might be also usefull for OEM customers to have a welcome mail for + This might be also useful for OEM customers to have a welcome mail for the customers, pointing to the support pages etc.. So general email "branding" packages which makes it possible to have such special "default mails" for the email clients would be usefull. Discussion: #1: Carlos Lange (cflange) (2009-01-17 19:59:30) There are several parts to this suggestion. 1) "default mail": If you mean "Default" in the sense that when I start a new message the To: field is filled out by default with the mailing- list address, I disagree with your comment. The user should set that and an inexperienced user should find herself/himself subscribing to a mailing-list by mistake, just because they forgot to reset the To: field. Such a user would be rightly upset and feel like they were trapped into doing it. 2) If you mean, however, that the address book in Evolution and Kmail should be pre-populated with relevant addresses, such as the mailing- list and others, in the same way the Firefox bookmarks toolbar comes pre-populated with the SUSE folder, then I would agree that this is a useful suggestion, because the user can freely choose to use those addresses or not. 3) I strongly disagree that every openSUSE user should be subscribed to the opensuse-announce mailing-list. I deal with many different types of users. Only a minority of them would be interested in receiving announcements and they actively subscribe to the mailing-list. The vast majority of them likes the Linux-way of being non-intrusive, without the nags and unsolicited messages from the proprietary world, that tend to be associated with annoying marketing strategies. Please, don't advocate that for openSUSE. The SUSE information box shown at the first login is as much in-your- face direct marketing as one should need to take when using openSUSE. And being beautiful and carefully designed as it is, it contains all information a new user needs to decide how much involved with the operating system they want to be. #2: Joe Brockmeier (jbrockmeier) (2009-01-20 02:05:37) (reply to #1) Perhaps "every" is a bit much, but I feel a lot more people should be subscribed than are currently. I find it's not uncommon to talk to people and see that they're unaware of something happening in the community that has been announced on the mailing list. The percentage of people subscribed to -announce is much less than 1% of openSUSE users, and I feel we could be reaching a lot more people. It's not an "annoying marketing strategy," it's an attempt to keep our community informed. Most of the messages that go to announce are not "marketing" in nature, they're informative. #3: Kevin Dupuy (kdupuy9) (2009-01-20 02:49:32) (reply to #2) I also like the idea of having more users subscribed to the -announce list. Every time there is scheduled downtime, even though it is announced on -announce and openSUSE News, some people come on the opensuse(a)o.o mailinglist "eh, what happened? the servers are down, suse is unreliable!",. so those type of mails I'd like for more users to get. Then again perhaps not every user wants to know when the next project meeting is, so that's a strike against the idea as well. I do think, as with Carlos, that the address book in Kontact and Evolution should have some important email address in there (opensuse(a)o.o, anything else?) #4: Martin Lasarsch (mlasars) (2009-01-20 17:12:09) (reply to #1) 1. no 2. maybe, why not 3. should means as an opt-in ... not forcing With default i meant to have a simple email in the inbox to make it easier to subscribe to the announce list. + #5: Stefan Behlert (sbehlert) (2009-03-26 10:58:17) + I think the idea of having some addresses in the addressbook is good. + I'm not sure which one's are the ideal ones for that, though. Let'S + start with a few and add what is found missing later. -- openSUSE Feature: https://features.opensuse.org/305489

1 0