|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST Partitioner and partition active (boot) flag status | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Forgotten User Xh41Ao4q6j <forgotten_Xh41Ao4q6j> |
| Component: | YaST2 | Assignee: | Duncan Mac-Vicar <dmacvicar> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | aj, dmacvicar, locilka, mrmazda |
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | 64bit | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Forgotten User Xh41Ao4q6j
2007-08-12 07:25:48 UTC
This should already be done, in cases where we can guarantee that the system is bootable, eg /boot on a primary partition. But, I'm not really sure, want the bug here is. I changed severity to enhancement. That is what I missed first time. In question is missing ability to set/change/view active (boot) flag on partition using YaST partitioner. There are other programs (fdisk, cfdisk) that can be used for that task, but I guess that YaST and it's modules should be central point of system administration. For a long time this feature was irrelevant as GRUB specific code was installed in MBR and it was not important what partition was active. With generic MBR that looks for a bootable partition this is important feature for YaST partitioner. I stumbled over this looking how to explain what to do in case that boot screen installed with 10.3 Beta version is not what user wants, and he wants to have back previous installed with 10.2. I got to resort to explanation using cfdisk as you can't use YaST Partitioner. New features need to go through FATE, not bugzilla. How to access FATE? To my knowledge, it is not publicly accessible. That seems to be kind of catch 22. New features need to go through FATE. FATE is not publicly accessible. I guess that the only way would be to have faith that you are going to put it in a FATE ;-) Thomas, sorry for being so picky, but is RESOLVED/INVALID really the correct way to close an enhancement that 'should be filed into FATE' :)? If there is a FATE request filed (based on this enhancement), we often close the bug as LATER. Rajko hasn't any access to FATE so he can't file a FATE request ;) So a better RESOLUTION would be probably LATER or WONTFIX. If an feature request comes in via bugzilla I consider INVALID the correct resolution. But if you prefer WONTFIX, finw with me. You guys are missing the point. How are OpenSUSE alpha/beta testers and users supposed to request new features except via Bugzilla when FATE is not accesible to them? Why does Bugzilla have an ENHANCEMENT status if not for new/enhanced features requests? Thanks Felix. This is getting silly. There is many calls on mailing lists to file enhancement request. The severity ENHANCEMENT was introduced to allow people that have no FATE access to file feature requests. It was, and it is still used by everyone: https://bugzilla.novell.com/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=Enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=openSUSE&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_severity&field-1-1-0=bug_status&field-1-2-0=classification&field0-0-0=noop&keywords=&keywords_type=anywords&long_desc=&long_desc_type=fulltext&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type0-0-0=noop&value-1-0-0=Enhancement&value-1-1-0=NEW%2CASSIGNED%2CNEEDINFO%2CREOPENED%2CRESOLVED%2CVERIFIED%2CCLOSED&value-1-2-0=openSUSE&value0-0-0=&votes=&order=bugs.bug_id%20desc&query_based_on= There is 2726 enhancement filed since 2003-09-18. So it is not new feature. There is 313 enhancements filed after this one. So it is still heavily used. We're going to open FATE so that openSUSE users can contribute to it as well. We will continue to handle enhancements requests here - and make the process clear and visible to everyone. I'm sorry for this confusion here. Thomas, could you add this *yourself* as feature to FATE, please? Once you've done that, feel free to resolve the bug. No, since I do not consider this a enhancement that is worth the effort needed to handle this correctly. Rajko, this enhancement will be closed as the implementation effort seems to be high for the benefit it gives according to the developers. If you have better usecases, feel free to post them here, but please don't reopen it unless there is a good reason. About the FATE/bugzilla issue, nevermind. Use bugzilla enhancements with a good use case to file enhancement proposals, unless you are in contact with some developer. Duncan, AJ reopened, not Rajko, so I would think there must be some justification internal to Novell to keep it open and valid as an enhancement. Felix, this is fine now for me. I reopened and asked for a proper evaluation and an answer to both comment #9 and #13 - and that's what Duncan did. Thanks! As is typical of bugs resolved as a result of Novell internal discussion, it wasn't explicitly noted as such. The lack of that small bit of information makes it look like resolution was a unilateral act of the assignee, unless it came from a Novell non-assignee. |