-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/11/15 22:16, Karsten Wade wrote:
On 11/11/2015 09:01 AM, Honza Horak wrote:
On 11/11/2015 11:00 AM, Karanbir Singh wrote:
On 11/11/15 08:55, Honza Horak wrote:
I see, but on the other hand it gives us ability to clone bugs to RHSCL product since many issues in centos collections will be reproducible in RHSCL packages as well.
With other packages that are rebuilt in centos (non-SCL), people report issues into bugzilla.redhat.com as well, don't they?
no, built in centos -> bugs.centos.org; SIG content or otherwise.
why is this better than pointing people to https://bugzilla.redhat.com/enter_bug.cgi?product=softwarecollections.
org?
As
this has come up a few times, we might want to add it to the project FAQ? This is the list of reasons I've gathered in the last year on why the CentOS Project needs its own bug reporting tool.
- Consistency -- you always know where to file bugs around
/anything/ related to the CentOS Project, rather than having to go find out which parts use a different bug tracker.
- Visibility -- CentOS Project contributors are not all Fedora or
Red Hat bug users, nor should they have to be to participate in the project. Using N bug reporting tools rather than one location means some parts of the project are dark to participants.
- All open -- bugs at bugzilla.redhat.com have the annoying habit
of being hidden for non-@redhat.com accounts, whether the entire bug or a comment. Even if there is a rule to never-make-private, it's hard to enforce -- you don't know to request that a bug or comment made be open as per the rule if you don't know it exists because it's private and hidden.
- Process -- CentOS is not RHEL (for example), bugs don't belong
in the upstream bugzilla.redhat.com until they are verified as reproducible in that environment. A bug filed against an SCL running on CentOS cannot be filed properly in bugzilla.r.c since the rest of the stack it rides on (CentOS Linux + potentially other SIG content) is not in bugzilla.r.c nor in Red Hat's purview to fix.
- Optics -- CentOS bugs are not Red Hat bugs, it's confusing to
people if some bug reports are filed in Bugzilla, some in Mantis, etc.
Your point that centralized management makes life easier for package maintainers and bug product owners is important, but has generally been rejected because it puts the burden on the bug reporter to know when and where to file which type of bug. That is a higher barrier to bug reporting, lowering reporting rates, and increasing dis-engagement with the project.
Regarding the discussion of merging bug reporting, etc., a few points come to mind.
- Massive undertaking with small perceptual value. * Large number
of resources needed to merge. * Current project contributors are focused on areas they care more about and/or perceive as more important/higher value. * Therefore, any merge effort is going to need a technical leader who cares and can commit time, and can pull in the other contributors to make it happen. This is in addition to reaching a consensus with the community.
Regards, - Karsten
With all this in mind, there is still maybe that "simple" thing that can be done (even if it adds "work" for the reporter, or the assignee if he'll do it) : what he asked people to do (if it was verified that the error could be reproduced on RHEL, or if that's really obvious, like an error in the .spec file affecting all builds, whatever the distro) : - - file a bug report on bugs.centos.org - - file a bug on bugzilla linking to the original bug report
Step 2 adds more work though, so wondering if $assignee (having already access to bugzilla with his account, something that probably $report doesn't) can just do that (so either just the link, or a copy/paste of bug report so that it can be cloned "internally" at the bugzilla level (don't know the internal mechanics used there)
Don't know if that makes sense or not
- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab