hi,
EL6 now includes abrt ( https://fedorahosted.org/abrt/ ), which is setup to talk with bugzilla.r.c and comes with a plugin that allows details passed to rhsupport. We dont really want either of those two things to happen. So we can either :
- Remove abrt completely ( might not be the best overall solution, but it would surely be the fastest short term target )
- Leave abrt in the distro, but disable chatter abilities with anything *.r.c; and *.fedoraproject.org ( that leaves functionality partially intact, but local implementations would need to adopt and go with whatever they want / need; this solution might not be as nice as the last option)
- Last option: get a plugin together that can do what's needed to file at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! )
Who wants to take on the task of handling abrt, getting the work done and driving this issue into CentOS-6 ? Being able to code in python might not be optional..
- KB
El 26/11/10 13:44, Karanbir Singh escribió:
hi,
EL6 now includes abrt ( https://fedorahosted.org/abrt/ ), which is setup to talk with bugzilla.r.c and comes with a plugin that allows details passed to rhsupport. We dont really want either of those two things to happen. So we can either :
- Remove abrt completely ( might not be the best overall solution, but
it would surely be the fastest short term target )
- Leave abrt in the distro, but disable chatter abilities with anything
*.r.c; and *.fedoraproject.org ( that leaves functionality partially intact, but local implementations would need to adopt and go with whatever they want / need; this solution might not be as nice as the last option)
- Last option: get a plugin together that can do what's needed to file
at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! )
+1, nice option. I like help. That is a way for manage bugs of the CentOS.
Who wants to take on the task of handling abrt, getting the work done and driving this issue into CentOS-6 ? Being able to code in python might not be optional..
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hi Yoinier,
On 11/26/2010 06:52 PM, Yoinier Hernandez Nieves wrote:
- Last option: get a plugin together that can do what's needed to file
at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! )
+1, nice option. I like help. That is a way for manage bugs of the CentOS.
Thanks for offering to help - Going by your response I am going to assume you are offering to help/write the plugin to have ABRT work with mantis.
Please make sure you have an account on bugs.c.o and let me know, I'll assign http://bugs.centos.org/view.php?id=4647 to you. Also, if you need any sort of resources please shout out.
- KB
El 26/11/10 14:17, Karanbir Singh escribió:
Hi Yoinier,
On 11/26/2010 06:52 PM, Yoinier Hernandez Nieves wrote:
- Last option: get a plugin together that can do what's needed to file
at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! )
+1, nice option. I like help. That is a way for manage bugs of the CentOS.
Thanks for offering to help - Going by your response I am going to assume you are offering to help/write the plugin to have ABRT work with mantis.
Please make sure you have an account on bugs.c.o and let me know, I'll assign http://bugs.centos.org/view.php?id=4647 to you. Also, if you need any sort of resources please shout out.
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
My account is Ynieves_NET.
Thanks.
Karanbir Singh wrote:
hi,
<snip>
Who wants to take on the task of handling abrt, getting the work done and driving this issue into CentOS-6 ? Being able to code in python might not be optional..
Due to the fact that there are still lots of thing to do for a CentOS 6.0 release, i don't think that putting extra work (by providing a specific centos plugin package for abrt that will delay/postpone the release) at this time is the best idea. I do like the idea of having abrt working for next release, aka 6.1 though. Now that the problem/issue was identified and that a correct fix implies development (not a single patch), i'd rather see it postponed than the whole distro. My personal thought though :-)
On 11/26/2010 07:07 PM, Fabian Arrotin wrote:
I do like the idea of having abrt working for next release, aka 6.1 though. Now that the problem/issue was identified and that a correct fix implies development (not a single patch), i'd rather see it postponed than the whole distro.
I would be happy with that personally. But I *would* like to take steps to make sure that CentOS installs dont hit resources not hosted at *.centos.org
- KB
Karanbir Singh wrote:
On 11/26/2010 07:07 PM, Fabian Arrotin wrote:
I do like the idea of having abrt working for next release, aka 6.1 though. Now that the problem/issue was identified and that a correct fix implies development (not a single patch), i'd rather see it postponed than the whole distro.
I would be happy with that personally. But I *would* like to take steps to make sure that CentOS installs dont hit resources not hosted at *.centos.org
Is abrt running during anaconda install process ? i know that it's the case in beta2refresh but don't know if it is in 6.0 GA. That would indeed mean that abrt should still be built and provided with centos 6.0 and so maybe just disabling/identifying what needs to be done just to be sure that it doesn't hit @redhat.com machines. But i'm still thinking that the specific abrt plugin to report bugs in the centos mantis bug report system should be postponed, except if a python guru can write it in 2 minutes and that it can be tested directly in the QA process.
On 11/26/2010 07:21 PM, Fabian Arrotin wrote:
I would be happy with that personally. But I *would* like to take steps to make sure that CentOS installs dont hit resources not hosted at *.centos.org
But i'm still thinking that the specific abrt plugin to report bugs in the centos mantis bug report system should be postponed, except if a python guru can write it in 2 minutes and that it can be tested directly in the QA process.
Aologies for not being clear on this - but that's mostly what I meant; we can retain abrt but disable it from hitting non .centos.org places; in the mean time do the work for making abrt work against bugs.c.o and ship that once its ready.
Lets see what Yoinier comes back with. He will almost certainly need to look at both the bits of code and then do an estimate on how much work is needed and how long its likely to take. We would / could then decide on the 6.0/6.1 timeline.
- KB
On 11/26/2010 07:21 PM, Fabian Arrotin wrote:
I would be happy with that personally. But I *would* like to take steps to make sure that CentOS installs dont hit resources not hosted at *.centos.org
But i'm still thinking that the specific abrt plugin to report bugs in the centos mantis bug report system should be postponed, except if a python guru can write it in 2 minutes and that it can be tested directly in the QA process.
Aologies for not being clear on this - but that's mostly what I meant; we can retain abrt but disable it from hitting non .centos.org places; in the mean time do the work for making abrt work against bugs.c.o and ship that once its ready.
Lets see what Yoinier comes back with. He will almost certainly need to look at both the bits of code and then do an estimate on how much work is needed and how long its likely to take. We would / could then decide on the 6.0/6.1 timeline.
from a quick once-over of the code, resubmitting to a bugzilla instance hosted at centos only requires a change to a config file. I'm gonna try building it and see if there's anything more regarding plugins that we can disable at runtime, but this looks quite easy *if* we have a bugzilla.c.o.
I'm monitoring the bug. I'll put anything that I find in there.
Matt
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Am 26.11.10 20:35, schrieb Matt Rose:
from a quick once-over of the code, resubmitting to a bugzilla instance hosted at centos only requires a change to a config file. I'm gonna try building it and see if there's anything more regarding plugins that we can disable at runtime, but this looks quite easy *if* we have a bugzilla.c.o.
The problem is that we don't have a bugzilla.c.o, but a mantis.c.o. Although there seems to be some xmlrpc plugin for mantis (which I haven't checked out), probably noone has tested that yet.
The other solution would be to run a b.c.o, but that takes work to setup, more work to get the accounts over and even more work to reimport the bugs, afaics.
If you know about a working solution on how to do that, I'd be curious.
Ralph
Am 26.11.10 20:35, schrieb Matt Rose:
from a quick once-over of the code, resubmitting to a bugzilla instance hosted at centos only requires a change to a config file. I'm gonna try building it and see if there's anything more regarding plugins that we can disable at runtime, but this looks quite easy *if* we have a bugzilla.c.o.
The problem is that we don't have a bugzilla.c.o, but a mantis.c.o. Although there seems to be some xmlrpc plugin for mantis (which I haven't checked out), probably noone has tested that yet.
The other solution would be to run a b.c.o, but that takes work to setup, more work to get the accounts over and even more work to reimport the bugs, afaics.
If you know about a working solution on how to do that, I'd be curious.
The solution proposed by Fabian was to have a separate bugzilla.c.o, that would take bugs from abrt, and then a manual process to move them either to bugzilla.redhat.com, or bugs.centos.org, or, more likely, just ignore them, but, most importantly, not have them go outside of centos.org which is Karanbir's main concern right now.
Matt
Ralph _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Am 26.11.10 21:49, schrieb Matt Rose:
The other solution would be to run a b.c.o, but that takes work to setup, more work to get the accounts over and even more work to reimport the bugs, afaics.
If you know about a working solution on how to do that, I'd be curious.
The solution proposed by Fabian was to have a separate bugzilla.c.o, that would take bugs from abrt, and then a manual process to move them either to bugzilla.redhat.com, or bugs.centos.org, or, more likely, just ignore them, but, most importantly, not have them go outside of centos.org which is Karanbir's main concern right now.
I am not going to run two different bug reporting instances. Others in c.org probably won't want to do that either :)
So it is either abrt without reporting, no abrt, or b.c.o running on a bugzilla instance, afaics.
And I have no problem changing b.c.o from mantis to bugzilla, *if* people not only want to, but do help. But remember: Old bugs have to get either resolved or moved over.
Ralph
On Nov 26, 2010, at 4:01 PM, Ralph Angenendt wrote:
So it is either abrt without reporting, no abrt, or b.c.o running on a bugzilla instance, afaics.
There are fallacies in reaching the conclusion that those are the only possible outcomes.
The argument chain that leads to those alternative resolutions goes something like this:
Q: Are segfault's (tracked by ABRT) bugs? A: Almost certainly.
Q: And where do bug reports get filed go ... ? A: In a bugzilla! duh!
which leads to a certain narrow perspective and Q.E.D conclusion: 1) rip ABRT out of CentOS 2) cripple ABRT or gimp it up with "no reporting" 3) set up a b.c.o instance
Bugzilla is almost certainly a reasonable end-point for ABRT if you have gazillions of paid employees who are paid (as part of a "service" model) to track store-bought product defects and paying customer complaints.
But is that the right model for CentOS? Hardly imho ...
The better model is what is being done with kernel.org bugs (which I claim was studied when ABRT was written. I'm sure there were other implementations at M$ and with Apple radar blips too).
With kernel.org, bugs are tracked as a software devel process metric, not as a paid wage slave performance indicator.
SO I suggest that you should look at other alternative end-points for ABRT automated segfault/bug end-points, and view as a objective distro "process" metric to prioritize scarce resources, not track, bug reports. No user id's needed is just one of many benefits.
Unless you really like sipping from a bugzilla fire hose, with everyone 2nd and 3rd guessing whatever solution you attempted to solve a reported problem. There are hair shorts and strait jackets for those who really MUSTHAVE their nagware to Get Things Done!
JMHO, YMMV, everyone's does, yadda, yadda.
hth
73 de Jeff
Am 26.11.10 23:52, schrieb Jeff Johnson:
On Nov 26, 2010, at 4:01 PM, Ralph Angenendt wrote:
So it is either abrt without reporting, no abrt, or b.c.o running on a bugzilla instance, afaics.
There are fallacies in reaching the conclusion that those are the only possible outcomes.
Hence "afaics" :)
Bugzilla is almost certainly a reasonable end-point for ABRT if you have gazillions of paid employees who are paid (as part of a "service" model) to track store-bought product defects and paying customer complaints.
That is what I am not sure about and especially where my hesitations come from (seeing how many people help tracking bugs on bugs.centos.org).
But is that the right model for CentOS? Hardly imho ...
As said, I'm neither bought nor sold, but I do see the problem with the amount of people.
With kernel.org, bugs are tracked as a software devel process metric, not as a paid wage slave performance indicator.
Harsh words :) But yeah, most abrt reports probably would have to be reported upstream, sooner or later.
SO I suggest that you should look at other alternative end-points for ABRT automated segfault/bug end-points, and view as a objective distro "process" metric to prioritize scarce resources, not track, bug reports. No user id's needed is just one of many benefits.
What I do not want to miss (well, for me too) is the automation of information collection within abrt for those people who really want to file a bug - because it can lead to better bug reports.
What we cannot do is piping those reports into bz.redhat.com :)
Im rather agnostic into which bug reporting tool people do throw their reports into, but I don't want to run two of those.
Thanks for your insight,
Ralph
On Mon, 2010-11-29 at 22:29 +0100, Ralph Angenendt wrote:
That is what I am not sure about and especially where my hesitations come from (seeing how many people help tracking bugs on bugs.centos.org).
Ok this is not about "abrt" but is about bug reports.tracking.etc... I'm just bringing it up again and it is no way to mean anything to you. (Ralph)...
I don't think it is really clear enough if people are wanted to submit patches to the bz for things like [1]. Or for that matter for those of who can fix things and provide el6 workable sources. IE, the ones of us that have EL5 hosts that support building for EL6. It seems to me it was just a errrrr ok if you can but we don't really want that? I think we all need an enlightenment on this.
I have a Spread Sheet dump of bz.co.c and 90% are Block Status? I also see [2] which has not changed in 3 days {Sat 27 Nov 2010 05:50:45 PM EST}. Check the server logs and you will see :-) {Mon Nov 29 17:42:30 EST 2010}
1. Is it getting blocked from being in the distro? 2. It is clearly patch hell for a beginner. 3. It would be a great patch project. 4. Like a Jigsaw Puzzle non the less it can be patched to workability. 5. Clearly it has more ".com" references than the law allows. 6. Maybe this should go in the reality thread? 7. Define the patchable ones and maybe we can split them up between the ones that do know how to do so.
John
[1] http://bugs.centos.org/view.php?id=4648 [2] http://wiki.centos.org/QaWiki/6/AuditStatus
Am 29.11.10 23:43, schrieb JohnS:
Ok this is not about "abrt" but is about bug reports.tracking.etc... I'm just bringing it up again and it is no way to mean anything to you. (Ralph)...
Good, because I really have no idea what you were trying to say in your mail.
Ralph
On Tue, 2010-11-30 at 01:58 +0100, Ralph Angenendt wrote:
Am 29.11.10 23:43, schrieb JohnS:
Ok this is not about "abrt" but is about bug reports.tracking.etc... I'm just bringing it up again and it is no way to mean anything to you. (Ralph)...
Good, because I really have no idea what you were trying to say in your mail.
You should read it again..
John
On 11/29/2010 10:43 PM, JohnS wrote:
I don't think it is really clear enough if people are wanted to submit patches to the bz for things like [1].
absolutely do so. If there is anything in the distro that hits properties outside .centos.org - then you should at-least file it in, patch would be great as well; but do not hold the report back if you don't have a patch.
Or for that matter for those of who can fix things and provide el6 workable sources. IE, the ones of us that have EL5 hosts that support building for EL6. It seems to me it was just a errrrr ok if you can but we don't really want that? I think we all need an enlightenment on this.
Not sure what you mean by that, did you find sources that did'nt work in EL6 ? That is the sort of thing which would need to ideally make its way into bugzilla.r.c
I have a Spread Sheet dump of bz.co.c and 90% are Block Status? I also see [2] which has not changed in 3 days {Sat 27 Nov 2010 05:50:45 PM EST}. Check the server logs and you will see :-) {Mon Nov 29 17:42:30 EST 2010}
That timestamp is never going to change, its coming from moin's internal version check; whereas the page changes content. I'll plumb in a 'generated at: ' timestamp as well. I'll also add in a list of pkgs not considered as yet, and the whitelists already in place.
The actual report status should be clear enough as to what the status of the corresponding package is.
- KB
Dne 26.11.2010 20:07, Fabian Arrotin napsal(a):
Karanbir Singh wrote: Due to the fact that there are still lots of thing to do for a CentOS 6.0 release, i don't think that putting extra work (by providing a specific centos plugin package for abrt that will delay/postpone the release) at this time is the best idea.
I'd stick with bugzilla instance. - upstream provides updates for abrt<->bz integration - it's working now, we need only bz instance - no need for someone to track upstream and implement changes downstream DH
On 11/26/2010 07:19 PM, David Hrbáč wrote:
I'd stick with bugzilla instance.
- upstream provides updates for abrt<->bz integration
- it's working now, we need only bz instance
- no need for someone to track upstream and implement changes downstream
Not entire sure if upstream would be happy to have that in, and once we release something - its quite hard to completely remove it from the wild.
I guess its a question we can ask
- KB
Karanbir Singh wrote:
On 11/26/2010 07:19 PM, David Hrbá?? wrote:
I'd stick with bugzilla instance.
- upstream provides updates for abrt<->bz integration
- it's working now, we need only bz instance
Well, a second reading on David's post leads me to the conclusion that he wanted to report to bugzilla, but not upstream :-)
- no need for someone to track upstream and implement changes downstream
Not entire sure if upstream would be happy to have that in, and once we release something - its quite hard to completely remove it from the wild.
I guess its a question we can ask
If we could only redirect to something like bugzilla.centos.org (for the abrt stuff) instead of upstream's bugzilla, that would be fine. There would still be a process of sorting real bugs from that bz instance and report them in mantis and/or upstream too :/
Dne 26.11.2010 20:27, Fabian Arrotin napsal(a):
Karanbir Singh wrote:
On 11/26/2010 07:19 PM, David Hrbá?? wrote:
I'd stick with bugzilla instance.
- upstream provides updates for abrt<->bz integration
- it's working now, we need only bz instance
Right.
Well, a second reading on David's post leads me to the conclusion that he wanted to report to bugzilla, but not upstream :-)
- no need for someone to track upstream and implement changes downstream
I mean, once we are going to pluging/rewrite, we need someone to track abrt upstream and propagate them into downstream/centos plugin. Also there will be work with mantis upstream down to...
If we could only redirect to something like bugzilla.centos.org (for the abrt stuff) instead of upstream's bugzilla, that would be fine. There would still be a process of sorting real bugs from that bz instance and report them in mantis and/or upstream too :/
Right. DH
Dne 26.11.2010 20:21, Karanbir Singh napsal(a):
On 11/26/2010 07:19 PM, David Hrbáč wrote: Not entire sure if upstream would be happy to have that in, and once we release something - its quite hard to completely remove it from the wild.
I guess its a question we can ask
- KB
I know, it's just a question of price. - BZ includes xml-rpc interface, mantis does not. - you'd need mantisconnect, it's soap interface to mantis, it means abrt rewrite - or we need own xml-rpc server, better with the same function set as BZ as not to rewrite abrt DH
Am Freitag, den 26.11.2010, 20:31 +0100 schrieb David Hrbáč:
- BZ includes xml-rpc interface, mantis does not.
- you'd need mantisconnect, it's soap interface to mantis, it means abrt
rewrite
This would mean heavy development on two sides (mantis + abrt) and would be a showstoper for Centos 6. If we go down this road it would be the best to leave abrt out now, or patch it to simply make a file with the Data.
- or we need own xml-rpc server, better with the same function set as BZ
as not to rewrite abrt DH
There is another option, switch to bugzilla :)
I have no clue why Mantis is preferred by the team, maybe someone could share the light.
On Fri, Nov 26, 2010 at 08:44:41PM +0100, David Hrbáč wrote:
Dne 26.11.2010 20:41, Stefan Held napsal(a):
There is another option, switch to bugzilla :)
AFAIK one of the reasons for mantis was also not to duplicate the reports within bugzilla.redhat.com and make sure all reports that also match for the Red Hat Enterprise Release get tracked "upstream".
regards,
Florian La Roche
Am 26.11.10 21:04, schrieb Florian La Roche:
AFAIK one of the reasons for mantis was also not to duplicate the reports within bugzilla.redhat.com and make sure all reports that also match for the Red Hat Enterprise Release get tracked "upstream".
Well, that is the reason to have our own bug tracker, but that is not the reason to have two different technical platforms for that.
As said: Mantis is a much more harmless beast to handle, at least at the time I last looked at bugzilla (somewhere in the middle of the bugzilla 2 cycle).
If that has changed and if the opinion of most people here is that it would be better to switch to bugzilla: Sure, if somebody (or more than one person) wants to help with it.
We could phase out mantis, but beware: We don't just need a place to file CentOS 6 bugs against, we'd also need to track CentOS 4 and 5 bugs in there. And we'd need a few people to look at all still open bugs in b.c.o and decide if those should be taken over to a new bug reporting facility or not.
And I am not sure if we - at the moment - have the time to do that before 6 comes out.
Helpful hands are always welcome.
Ralph
Am 26.11.10 21:04, schrieb Florian La Roche:
AFAIK one of the reasons for mantis was also not to duplicate the reports within bugzilla.redhat.com and make sure all reports that also match for the Red Hat Enterprise Release get tracked "upstream".
Well, that is the reason to have our own bug tracker, but that is not the reason to have two different technical platforms for that.
As said: Mantis is a much more harmless beast to handle, at least at the time I last looked at bugzilla (somewhere in the middle of the bugzilla 2 cycle).
If that has changed and if the opinion of most people here is that it would be better to switch to bugzilla: Sure, if somebody (or more than one person) wants to help with it.
Speaking as the only System Engineer/Build Engineer/SCM maintainer/Bugzilla maintainer at my work, I can say that bugzilla is definitely not a full-time job. If you give me access to a c.o machine I could probably set one up in an afternoon.
We could phase out mantis, but beware: We don't just need a place to file CentOS 6 bugs against, we'd also need to track CentOS 4 and 5 bugs in there. And we'd need a few people to look at all still open bugs in b.c.o and decide if those should be taken over to a new bug reporting facility or not.
And I am not sure if we - at the moment - have the time to do that before 6 comes out.
It's not a good idea, period. This is something that centos should do according to our own schedule. Setting up a separate bugzilla instance just to receive abrt submissions is a way of taking back control over the timing of this important decision.
Helpful hands are always welcome.
Ralph _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Am 26.11.10 22:06, schrieb Matt Rose:
Speaking as the only System Engineer/Build Engineer/SCM maintainer/Bugzilla maintainer at my work, I can say that bugzilla is definitely not a full-time job. If you give me access to a c.o machine I could probably set one up in an afternoon.
Hmmm. Need to think about that. Can you write up what would be needed to do that? Database? I'm afraid that that will be another sink for user accounts, and we already have quite a few of those. Do you think there would be any chance to reuse the b.c.o accounts from mantis?
I could tell you how those look in the database.
And I am not sure if we - at the moment - have the time to do that before 6 comes out.
It's not a good idea, period. This is something that centos should do according to our own schedule. Setting up a separate bugzilla instance just to receive abrt submissions is a way of taking back control over the timing of this important decision.
Okay, that sounds rather sane. Other opinions on that?
Ralph
Am 26.11.10 22:06, schrieb Matt Rose:
Speaking as the only System Engineer/Build Engineer/SCM maintainer/Bugzilla maintainer at my work, I can say that bugzilla is definitely not a full-time job. If you give me access to a c.o machine I could probably set one up in an afternoon.
Hmmm. Need to think about that. Can you write up what would be needed to do that? Database?
The main things are MySQL, Perl, an MTA, and Apache2. There's a whackload of perl modules that are needed as well that I don't remember off the top of my head. There's a checksetup perl script that will install them if you don't mind polluting your system with CPAN modules. If not, I think Dag has all of the perl modules as rpms.
Requirements are listed here. http://www.bugzilla.org/docs/3.0/html/installation.html
I'm afraid that that will be another sink for user
accounts, and we already have quite a few of those. Do you think there would be any chance to reuse the b.c.o accounts from mantis?
With my use case, bugzilla.c.o would only need a couple of users to triage and treat appropriately.
Honestly, I think this may not be a bad way to do things permanently, based on Felix's experiences from using abrt in Fedora, as it would let developers concentrate on reproducible bugs.
Matt
Ralph _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Am Freitag, den 26.11.2010, 22:20 +0100 schrieb Ralph Angenendt:
Am 26.11.10 22:06, schrieb Matt Rose:
Speaking as the only System Engineer/Build Engineer/SCM maintainer/Bugzilla maintainer at my work, I can say that bugzilla is definitely not a full-time job. If you give me access to a c.o machine I could probably set one up in an afternoon.
Hmmm. Need to think about that. Can you write up what would be needed to do that? Database? I'm afraid that that will be another sink for user accounts, and we already have quite a few of those. Do you think there would be any chance to reuse the b.c.o accounts from mantis?
I could tell you how those look in the database.
Wasn't there some efforts for LDAP user accounts for website version 2 and a new forum? Bugzilla integrates very well and flexible with LDAP.
Chris
Hi Christoph,
Am Freitag, den 26.11.2010, 22:20 +0100 schrieb Ralph Angenendt:
Am 26.11.10 22:06, schrieb Matt Rose:
Speaking as the only System Engineer/Build Engineer/SCM maintainer/Bugzilla maintainer at my work, I can say that bugzilla is definitely not a full-time job. If you give me access to a c.o machine I could probably set one up in an afternoon.
Hmmm. Need to think about that. Can you write up what would be needed to do that? Database? I'm afraid that that will be another sink for user accounts, and we already have quite a few of those. Do you think there would be any chance to reuse the b.c.o accounts from mantis?
I could tell you how those look in the database.
Wasn't there some efforts for LDAP user accounts for website version 2 and a new forum? Bugzilla integrates very well and flexible with LDAP.
Yes, but we are still in need of an account creation frontend.
Am 26.11.10 20:41, schrieb Stefan Held:
There is another option, switch to bugzilla :)
I have no clue why Mantis is preferred by the team, maybe someone could share the light.
Because it is not a beast requiring one person to take care about it. No idea if bugzilla has gotten better, but that also was the reason to run mantis at work (you can do that besides your job) in favour of having someone who understands bugzilla.
If that was an offer to help to run a bugzilla instance @centos.org, please say so - I'd like to help out with that. Even better if we could import mantis bugs into that.
Regards,
Ralph
On 11/26/2010 07:41 PM, Stefan Held wrote:
I have no clue why Mantis is preferred by the team, maybe someone could share the light.
As Ralph already pointed out - the reasons boiled down to limited resources, and what we really wanted out of the issue tracker. Bz at the time seemed very complex, neither Johnny nor I were very keen on spending lots of time with perl + we wanted an easy way to interface the issue tracker stuff with the website. Many years down the road, the integration has not happened! But the much simpler schema and mysql requirements behind mantis have come in handy when building reports and integrating other tools.
Also worth noting is that we actually migrated FROM bugzilla to mantis, the first instance that we setup on the split from caoslinux was bugzilla.
- KB
Am 26.11.10 19:44, schrieb Karanbir Singh:
- Remove abrt completely ( might not be the best overall solution, but
it would surely be the fastest short term target )
I am against it, as abrt is one of the few packages which really enables people to do serious bug reporting (especially as it downloads the corresponding debug packages which are needed to make sense out of a crash - and does that automagically).
- Leave abrt in the distro, but disable chatter abilities with anything
*.r.c; and *.fedoraproject.org ( that leaves functionality partially intact, but local implementations would need to adopt and go with whatever they want / need; this solution might not be as nice as the last option)
That would be my favourite solution: operate out the part where it reports to somewhere.
- Last option: get a plugin together that can do what's needed to file
at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! )
I don't see how to do that against mantis. And I am (except if someone wants to run it) against switching to bugzilla, if possible.
Ralph
Am 26.11.2010 19:44, schrieb Karanbir Singh:
- Last option: get a plugin together that can do what's needed to file
at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! )
Personally I don't really like abrt. In Fedora I feel that abrt reports go mostly unnoticed and just flood the maintainers. IMHO abrt functionality would be useful for something like kerneloops but not more.
As developer usually you only care about reproducible crashes however (for me personally) that's only a small subset of crashes detected by abrt. So I'd recommend against sending abrt reports to bugs.c.o.
Just my 2¢ from personal Fedora experience.
fs
Just a quick summary of where we are with abrt :
- Split the effort into 2 tasks
1) disable abrt's access to non .centos.org web properties. Target: 6.0 Release
2) Evaluate options for a longer term solution, one of which might be to migrate from mantis to bugzilla and have abrt feed that. Target: 6.1
Felix's comment is interesting. And I think it will boil down to the level of and the kind of a triage team that can come together to handle those issues.
And, evaluating the bugzilla move might be worth doing for reasons even beyond abrt. Maybe as step-1 for the single-auth-mechanism, not sure how much of work will be needed to get proper single-sign-on going though.
- KB
Am 02.12.10 03:02, schrieb Karanbir Singh:
Just a quick summary of where we are with abrt :
- Split the effort into 2 tasks
- disable abrt's access to non .centos.org web properties. Target: 6.0
Release
- Evaluate options for a longer term solution, one of which might be to
migrate from mantis to bugzilla and have abrt feed that. Target: 6.1
+1 there.
Ralph
On 12/02/2010 10:52 PM, Ralph Angenendt wrote:
Am 02.12.10 03:02, schrieb Karanbir Singh:
Just a quick summary of where we are with abrt :
- Split the effort into 2 tasks
- disable abrt's access to non .centos.org web properties. Target: 6.0
Release
- Evaluate options for a longer term solution, one of which might be to
migrate from mantis to bugzilla and have abrt feed that. Target: 6.1
+1 there.
Wise decision, +1 .
best regards.
-
Athmane Madjoudj -
Christoph Maser -
David Hrbáč -
Fabian Arrotin -
Felix Schwarz -
Florian La Roche -
Jeff Johnson -
JohnS -
Karanbir Singh -
Marcus Moeller -
Matt Rose -
Ralph Angenendt -
Stefan Held -
Yoinier Hernandez Nieves