Do we need a SCLo specific section on bugs.centos.org- and maybe get Honza setup as primary developer for that ?
regards,
-------- Forwarded Message -------- Subject: Re: [scl.org] bug reporting for slcs ? Date: Thu, 5 Nov 2015 11:38:03 +0100 From: Jarek Polok Jaroslaw.Polok@cern.ch Organisation: CERN To: sclorg@redhat.com
Since the problem is sclo-specific [ upstream package not affected ], submitted bug report here:
https://bugs.centos.org/view.php?id=9705
(as 'Project Buildsys' category 'general')
Cheers
Jarek
On 10/29/2015 04:07 PM, Jarek Polok wrote:
Hi,
Where bugs for SCLo collections are to be reported ?
bugs.centos.org does not seem to have SCLo project defined ?
We have just seen a (minor) bug in rh-ruby22 collection (wrong shebang paths in some tools)
My understanding is that that collection is a rebuilt of upstream RH one: in that case the bug is to be reported to CentOS/SCLo or to RH directly ?
Thanks
Jarek
__
_ Jaroslaw_Polok __________________ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _
SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
Sorry for late response, I don't think we need anything on bugs.centos.org, we already have this space: https://bugzilla.redhat.com/enter_bug.cgi?product=softwarecollections.org
Honza
On 11/05/2015 12:37 PM, Karanbir Singh wrote:
Do we need a SCLo specific section on bugs.centos.org- and maybe get Honza setup as primary developer for that ?
regards,
-------- Forwarded Message -------- Subject: Re: [scl.org] bug reporting for slcs ? Date: Thu, 5 Nov 2015 11:38:03 +0100 From: Jarek Polok Jaroslaw.Polok@cern.ch Organisation: CERN To: sclorg@redhat.com
Since the problem is sclo-specific [ upstream package not affected ], submitted bug report here:
https://bugs.centos.org/view.php?id=9705
(as 'Project Buildsys' category 'general')
Cheers
Jarek
On 10/29/2015 04:07 PM, Jarek Polok wrote:
Hi,
Where bugs for SCLo collections are to be reported ?
bugs.centos.org does not seem to have SCLo project defined ?
We have just seen a (minor) bug in rh-ruby22 collection (wrong shebang paths in some tools)
My understanding is that that collection is a rebuilt of upstream RH one: in that case the bug is to be reported to CentOS/SCLo or to RH directly ?
Thanks
Jarek
__
_ Jaroslaw_Polok __________________ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _
SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
While I'm fine with this, it does create a split between where most CentOS bugs are filed and where the scl-sig ones are filed.
Perhaps an excuse to revisit unifying the bug reporting?
On Friday, November 6, 2015, Honza Horak hhorak@redhat.com wrote:
Sorry for late response, I don't think we need anything on bugs.centos.org, we already have this space: https://bugzilla.redhat.com/enter_bug.cgi?product=softwarecollections.org
Honza
On 11/05/2015 12:37 PM, Karanbir Singh wrote:
Do we need a SCLo specific section on bugs.centos.org- and maybe get Honza setup as primary developer for that ?
regards,
-------- Forwarded Message -------- Subject: Re: [scl.org] bug reporting for slcs ? Date: Thu, 5 Nov 2015 11:38:03 +0100 From: Jarek Polok Jaroslaw.Polok@cern.ch Organisation: CERN To: sclorg@redhat.com
Since the problem is sclo-specific [ upstream package not affected ], submitted bug report here:
https://bugs.centos.org/view.php?id=9705
(as 'Project Buildsys' category 'general')
Cheers
Jarek
On 10/29/2015 04:07 PM, Jarek Polok wrote:
Hi,
Where bugs for SCLo collections are to be reported ?
bugs.centos.org does not seem to have SCLo project defined ?
We have just seen a (minor) bug in rh-ruby22 collection (wrong shebang paths in some tools)
My understanding is that that collection is a rebuilt of upstream RH one: in that case the bug is to be reported to CentOS/SCLo or to RH directly ?
Thanks
Jarek
__
_ Jaroslaw_Polok __________________ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _
SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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?
Honza
On 11/07/2015 01:36 PM, Tom Sorensen wrote:
While I'm fine with this, it does create a split between where most CentOS bugs are filed and where the scl-sig ones are filed.
Perhaps an excuse to revisit unifying the bug reporting?
On Friday, November 6, 2015, Honza Horak <hhorak@redhat.com mailto:hhorak@redhat.com> wrote:
Sorry for late response, I don't think we need anything on bugs.centos.org <http://bugs.centos.org>, we already have this space: https://bugzilla.redhat.com/enter_bug.cgi?product=softwarecollections.org Honza On 11/05/2015 12:37 PM, Karanbir Singh wrote: Do we need a SCLo specific section on bugs.centos.org- and maybe get Honza setup as primary developer for that ? regards, -------- Forwarded Message -------- Subject: Re: [scl.org <http://scl.org>] bug reporting for slcs ? Date: Thu, 5 Nov 2015 11:38:03 +0100 From: Jarek Polok <Jaroslaw.Polok@cern.ch> Organisation: CERN To: sclorg@redhat.com Since the problem is sclo-specific [ upstream package not affected ], submitted bug report here: https://bugs.centos.org/view.php?id=9705 (as 'Project Buildsys' category 'general') Cheers Jarek On 10/29/2015 04:07 PM, Jarek Polok wrote: Hi, Where bugs for SCLo collections are to be reported ? bugs.centos.org <http://bugs.centos.org> does not seem to have SCLo project defined ? We have just seen a (minor) bug in rh-ruby22 collection (wrong shebang paths in some tools) My understanding is that that collection is a rebuilt of upstream RH one: in that case the bug is to be reported to CentOS/SCLo or to RH directly ? Thanks Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok __________________ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ _______________________________________________ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
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.
- KB
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?
Honza
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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-@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 - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----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
On 11/11/15 17:01, 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?
Remember also, in addition to the points made by Karsten, that many CentOS users, use CentOS Linux and the components we ship without any relation to RHEL - they dont interact with or care about the RHEL relationship since none exist ( eg. ARM and i386 as linux components, Virt and the storage sig work as layer components ).
to me, and clearly to atleast some of the users here, it makes sense to have a bugs.centos.org instance for components we ship from here.
-
Fabian Arrotin -
Honza Horak -
Karanbir Singh -
Karanbir Singh -
Karsten Wade -
Tom Sorensen