[CentOS-devel] [scl.org] Fwd: Re: bug reporting for slcs ?

Fabian Arrotin

arrfab at centos.org
Thu Nov 12 06:29:47 UTC 2015


-----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.
> 
> 1. 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.
> 
> 2. 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.
> 
> 3. All open -- bugs at bugzilla.redhat.com have the annoying habit 
> of being hidden for non- at 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.
> 
> 4. 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.
> 
> 5. 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlZEMdsACgkQnVkHo1a+xU6nkgCfSj8AyJVzHi0BMSfY/f6Ol/aD
sf0AnRCkg4S7rKL6CbEXIm31QfXRmYtG
=oIyY
-----END PGP SIGNATURE-----



More information about the CentOS-devel mailing list