#145 Add more explanation to reporting issues doucment
Closed: Fixed 4 years ago by asamalik. Opened 4 years ago by jaruga.

Is it possible to update the section https://docs.fedoraproject.org/en-US/modularity/reporting-issues/ considering https://pagure.io/fm-orchestrator/issue/1342#comment-582780 adding more explanation of conditions to open the ticket?

People in MBS like the issues that need to discuss a specification are managed by General Modularity Issue Tracker.

MBS (Module Build Service) issue tracker - Issues regarding MBS specifically. But do not open the ticket to decide the specification and etc. In the case, open the ticket on General Modularity Issue Tracker.

I also like to add below content to the section.

Specific components
* DNF issue tracker - Issues regarding dnf module. Link: https://src.fedoraproject.org/rpms/dnf Issues

The ticket can be like below ticket about "dnf module".
https://bugzilla.redhat.com/show_bug.cgi?id=1706131

Thank you.


Thanks @jaruga.

I'm thinking about some wording which would say that problems with MBS infrastructure (like MBS down, module build stuck, module build failed for strange reason) should be reported to https://pagure.io/fedora-infrastructure/. Those also do not belong to upstream MBS tracker.

MBS issue tracker should be used for clear bugs in MBS with clear "right behavior". Maybe the rule of thump is that:

If your issue or RFE changes the syntax or semantics of MBS input or the MBS output (RPMs built in a module or resulting modular metadata), it does belong to General Modularity Issue Tracker. If your issue is related to particular module build in Fedora infrastructure, it belongs to fedora-infrastructure issue tracker. Any other MBS issue can be filed in the MBS issue tracker.

I think we can close this ticket.

Metadata Update from @asamalik:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata