Bug 228504 - There is only 'Individual Port(s)' in 'Component' field of 'Ports & Packages' bug submitting form.
Summary: There is only 'Individual Port(s)' in 'Component' field of 'Ports & Packages'...
Status: Closed Works As Intended
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: Bugmeister
URL:
Keywords:
: 235597 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-05-26 14:55 UTC by Yasuhiro Kimura
Modified: 2024-02-05 01:53 UTC (History)
3 users (show)

See Also:


Attachments
Screen shot of bug submitting form. (89.74 KB, image/png)
2018-05-26 14:55 UTC, Yasuhiro Kimura
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro Kimura freebsd_committer freebsd_triage 2018-05-26 14:55:44 UTC
Created attachment 193713 [details]
Screen shot of bug submitting form.

Steps:

1. Access FreeBSD Bugzilla (https://bugs.freebsd.org/bugzilla/).
2. Login with registered account.
3. Select 'New'.
4. Select 'Ports & Packages'.

Then there is only 'Individual Port(s)' in 'Component' field.

Attached file is screen shot of bug submitting form.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2018-05-28 11:05:01 UTC
Access to view other components was restricted as a solution in bug 198411, so this issue is technically 'works as intended'. However ...

I happen to not agree with that particular solution, and would have preferred considering, or at least thinking about the real underlying cause(s), and alternate methods to reduce/eliminate false positives, rather than a blanket restriction.

Further, since the change, we have the exact same issue but in the opposite direction: 'ports framework' bug reports/patches, incorrectly being put into 'individual ports' and having to be reassigned. This time however, the missclassification is forced by the lack of alternative (visible) components, rather than imprescise/overlapping/unclear component names

I believe the underlying root cause is the ambiguity of the term 'ports framework', since to the uninitiated (read: non committers), all ports / any ports, and issues for them, can appear to come under that banner.

Accordingly it would great to put some actual effort into thinking about and understanding the actual information//taxonomical problem, and solving the underlying ambiguities in whatever way to help users make more informed and more accurate 'category' choices.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2020-07-24 23:39:40 UTC
*** Bug 235597 has been marked as a duplicate of this bug. ***
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2024-01-26 01:54:03 UTC
I agree with the request to have something other than "Individual Ports".

For now I have re-enabled "Ports Framework" in the dropdown.

If this turns out to be controversial, perhaps we could try "Multiple Ports".

I also think that the "Package Building Framework" ought to be restricted to developers only.
These are, and only are, of interest to people wrangling the package building machines themselves.
Regular users should not have this shown to them.
Comment 4 Mathieu Arnold freebsd_committer freebsd_triage 2024-02-03 08:18:18 UTC
Please put it back as it was.
Non committers don't understand the difference and choose at random, we used to have patch for ports that would sit for months or years untouched and unseen as being wrongly assigned to portmgr.
This added a lot of triage for portmgr, time we already are short of.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2024-02-05 01:53:43 UTC
Previous change reverted per portmgr.