- openSUSE Features

[openFate 305168] default to relatime
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Sven Burmeister (rabauke) Feature #305168, revision 10 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. + #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) + 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu + suffering from using relatime by default? If not, it seems likely that + there are little to none issues. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305168

1 0

[openFate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: Todd R (TheBlackCat) Feature #302923, revision 19 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral openSUSE-11.1: Rejected by Matthias Eckermann <mge(a)novell.com> reject date: 2008-07-22 23:04:50 reject reason: Postponing, will not be ready. Priority Requester: Neutral openSUSE-11.2: Evaluation Priority Requester: Neutral Requested by: Ján Kupec (jkupec) Partner organization: openSUSE.org Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: Stephan Kulow (coolo) (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow (coolo) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) I would like to see robust redirection, if possible. The details about a list, probably should not be in the feature description. + #7: Todd R (theblackcat) (2009-01-22 22:20:45) + Would this also be able to handle changes in the Buildservice, like + renaming or moving of a certain Buildservice repository? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0

[openFate 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: evamaria fuchs (nefuchs) Feature #302306, revision 41 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi <flucifredi(a)novell.com> reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Martin Schmidkunz (mschmidkunz) Partner organization: openSUSE.org Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432) maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. + #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) + Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302306

1 0

[openFate 120326] Resume download
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #120326, revision 43 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Partner organization: openSUSE.org Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. #13: Dmitri Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) I'd vote at least for a way to change the timeout settings for YaST or it doesn't solve the problem? #15: Alam Aby Bashit (init7) (2009-01-22 09:35:17) I'd like to vote this feature implemented in 11.2. You surely want to have resume capability if you have unreliable yet slow internet connection for say, updating KDE 4.2 :) + #16: Duncan Mac-Vicar (dmacvicar) (2009-01-22 15:14:44) (reply to #15) + Please stop this "I vote for this" or "+1" or "mee too" comments. There + is no voting system in FATE yet, but following a discussion about "I + want this too" makes hard to evaluate features. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120326

1 0

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #304879, revision 28 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.2: Evaluation + Priority + Requester: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0

[openFate 302963] Rating support for FATE
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #302963, revision 9 Title: Rating support for FATE + openFATE: Evaluation + Priority + Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) + Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): - Threshold for feature processing should save thousands of dollars in - wasted time doing ping pong, needinfos for features with incomplete - information. Even engineering could be optimized when features with no - real business case dissapear by social tagging. + openSUSE.org: Threshold for feature processing should save thousands of + dollars in wasted time doing ping pong, needinfos for features with + incomplete information. Even engineering could be optimized when + features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302963

1 0

[openFate 305673] openFATE - link account names to users.o.o
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305673, revision 4 Title: openFATE - link account names to users.o.o - openFATE: New + 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 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305673

1 0

[openFate 120326] Resume download
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: Alam Aby Bashit (init7) Feature #120326, revision 42 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Partner organization: openSUSE.org Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. #13: Dmitri Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) I'd vote at least for a way to change the timeout settings for YaST or it doesn't solve the problem? + #15: Alam Aby Bashit (init7) (2009-01-22 09:35:17) + I'd like to vote this feature implemented in 11.2. You surely want to + have resume capability if you have unreliable yet slow internet + connection for say, updating KDE 4.2 :) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120326

1 0

[openFate 120326] Resume download
by fate_noreply＠suse.de 21 Jan '09

21 Jan '09

Feature changed by: Piotrek Juzwiak (BenderBendingRodriguez) Feature #120326, revision 41 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Partner organization: openSUSE.org Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. #13: Dmitri Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. + #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) + I'd vote at least for a way to change the timeout settings for YaST or + it doesn't solve the problem? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120326

1 0

[openFate 303809] Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1
by fate_noreply＠suse.de 21 Jan '09

21 Jan '09

Feature changed by: Matthias Eckermann (mge1512) Feature #303809, revision 17 Title: Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 openSUSE-11.1: Rejected by Matthias Eckermann <mge(a)novell.com> reject date: 2008-07-30 16:50:50 reject reason: Moving to SLE 11 SP 1 / openSUSE 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Matthias Eckermann (mge1512) + Partner organization: openSUSE.org Description: Proposal is to offer an option in YaST to clone a disk layout for RAID use and probably jump into the RAID-creation-mode directly Below the original request from C. Boltz / openSUSE community: ----------------------------------------------------------------------------------------------------- It would be good to have an easier way to setup a raid 1 (mirroring). Currently you have to: * create partitions on first disk * create partitions on the second disk (usually using the same layout). * put the corresponding partitions (sda1+sdb1, sda2+sdb2, ...) into a raid array. The easier way would be * [x] I want to create a raid 1 * define the partitioning once for both disks YaST should then partition both disks as requested and create the raid volumes This would save the user/admin some time. However, the traditional method should still be available in case someone wants to have a different layout for some partitions for whatever reason. Relations: - Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 (novell/bugzilla/id: 387373) https://bugzilla.novell.com/show_bug.cgi?id=387373 Discussion: #2: Matthias Eckermann (mge1512) (2008-05-06 20:10:22) Thanks for the proposal. I am happy that there are more people out there sharing my problems:-) Yet, looking at the current "model" we have in mind for partitioner enhancements, I wonder, if we could probably make that more "generic" by adding something like a "clone disk partitioning scheme" button: You would partition hd0 first and then say: please clone this to hd1, hd2, ... and be able to adjust settings on hd1, ... later. Would that fit? so long - MgE #3: Christian Boltz (cboltz) (2008-05-08 05:07:14) Cloning the disk layout sounds like a good idea and would help. To make it more useful for RAID creation, add "clone to md*", maybe combined with a selection dialog to choose the disks to use. #4: Matthias Eckermann (mge1512) (2008-05-08 05:26:16) Well, you know, we indeed are planning to have such a dialog for creation of raids in the future, ...:-) I changed the "title" according to our discussion, and will 1transfer the request into our internal Feature tracking system soon. Thanks! so long - MgE #6: Martin Schmidkunz (mschmidkunz) (2008-05-15 11:37:58) AFAIK it is currently possible to create one partition after the other. So it does not make sense for me to have a "Clone this partition for future use" at the end. Instead I thought of: http://en.opensuse.org/Image:Idea_303809_1.png When the user presses "Add" in the "partitioning" tab he can choose whether to create one new partition or to use the whole partition scheme from another physical harddisk. Does that make sense? #7: Matthias Eckermann (mge1512) (2008-05-15 12:05:53) (reply to #6) Well, no:-( We are not asking for _partition_ cloning, but _disk_ cloning, i.e. if you have several harddisks, and you want to copy the partitioning from sda to sdb or the like. #8: Martin Schmidkunz (mschmidkunz) (2008-05-16 10:01:41) As discussed live with mge we agree on my proposal. #9: Arvin Schnell (aschnell) (2008-05-16 10:33:01) (reply to #8) That approach has some problems: 1) Hiding "Cloning" behind "Add Partition" is incomprehensible. Cloning affect the whole disk, adding a partition not really. 2) The step to select the partition type is omitted if only one type of partition can be selected. 3) The complete workflow of adding a partition is omitted when no partitions can be created. We (mge, mschmidkunz and aschnell) now agreed upon adding an entry to the "expert" menubutton in the partition overview. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303809

1 0