FAQ
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

Search Discussions

  • Yoinier Hernandez Nieves at Nov 26, 2010 at 1:52 pm

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel

    --
    Yoinier Hern?ndez Nieves.
    Administrador de Redes.
    Nodo Provincial Teico Las Tunas.
  • Karanbir Singh at Nov 26, 2010 at 2:17 pm
    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?idF47 to you. Also, if you need
    any sort of resources please shout out.

    - KB
  • Yoinier Hernandez Nieves at Nov 26, 2010 at 2:28 pm

    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?idF47 to you. Also, if you need
    any sort of resources please shout out.

    - KB
    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    My account is Ynieves_NET.

    Thanks.

    --
    Yoinier Hern?ndez Nieves.
    Administrador de Redes.
    Nodo Provincial Teico Las Tunas.
  • Fabian Arrotin at Nov 26, 2010 at 2:07 pm

    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 :-)


    --
    --
    Fabian Arrotin
  • Karanbir Singh at Nov 26, 2010 at 2:14 pm

    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
  • Fabian Arrotin at Nov 26, 2010 at 2:21 pm

    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.


    --
    --
    Fabian Arrotin
  • Karanbir Singh at Nov 26, 2010 at 2:25 pm

    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
  • Matt Rose at Nov 26, 2010 at 2:35 pm

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Ralph Angenendt at Nov 26, 2010 at 3:01 pm

    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
  • Matt Rose at Nov 26, 2010 at 3:49 pm

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Ralph Angenendt at Nov 26, 2010 at 4:01 pm

    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
  • Jeff Johnson at Nov 26, 2010 at 5:52 pm

    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
  • Ralph Angenendt at Nov 29, 2010 at 4:29 pm

    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
  • JohnS at Nov 29, 2010 at 5:43 pm

    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?idF48
    [2] http://wiki.centos.org/QaWiki/6/AuditStatus
  • Ralph Angenendt at Nov 29, 2010 at 7:58 pm

    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
  • JohnS at Nov 29, 2010 at 11:44 pm

    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
  • Karanbir Singh at Dec 1, 2010 at 8:46 pm

    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
  • David Hrbáč at Nov 26, 2010 at 2:19 pm

    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
  • Karanbir Singh at Nov 26, 2010 at 2:21 pm

    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
  • Fabian Arrotin at Nov 26, 2010 at 2:27 pm

    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 :/

    --
    --
    Fabian Arrotin
  • David Hrbáč at Nov 26, 2010 at 2:41 pm

    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
  • David Hrbáč at Nov 26, 2010 at 2:31 pm

    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
  • Stefan Held at Nov 26, 2010 at 2:41 pm

    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.

    --

    Stefan Held VI has only 2 Modes:
    obi unixkiste org The first one is for beeping all the time,
    the second destroys the text.

    ---------------------------------------------------------------------------
    perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
    ---------------------------------------------------------------------------
  • David Hrbáč at Nov 26, 2010 at 2:44 pm

    Dne 26.11.2010 20:41, Stefan Held napsal(a):
    There is another option, switch to bugzilla :)
    Well, what am I talking about all the time?!? :o)
    DH
  • Florian La Roche at Nov 26, 2010 at 3:04 pm

    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
  • Ralph Angenendt at Nov 26, 2010 at 3:29 pm

    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
  • Matt Rose at Nov 26, 2010 at 4:06 pm

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Ralph Angenendt at Nov 26, 2010 at 4:20 pm

    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
  • Matt Rose at Nov 26, 2010 at 4:37 pm

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Florian La Roche at Nov 27, 2010 at 2:53 am
    Okay, that sounds rather sane. Other opinions on that?
    Adding bugzilla would enlarge the centos infrastructure and
    would be a good step.

    regards,

    Florian La Roche
  • Christoph Maser at Nov 29, 2010 at 5:10 am

    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
  • Marcus Moeller at Nov 29, 2010 at 6:39 am
    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.

    --
    Greets
    Marcus
  • Ralph Angenendt at Nov 26, 2010 at 3:04 pm

    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
  • Karanbir Singh at Dec 1, 2010 at 8:56 pm

    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
  • Ralph Angenendt at Nov 26, 2010 at 2:57 pm

    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
  • Felix Schwarz at Nov 26, 2010 at 3:57 pm

    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
  • Karanbir Singh at Dec 1, 2010 at 9:02 pm
    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
  • Ralph Angenendt at Dec 2, 2010 at 4:52 pm

    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

    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
    +1 there.

    Ralph
  • Athmane Madjoudj at Dec 2, 2010 at 8:59 pm

    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

    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
    +1 there.
    Wise decision, +1 .

    best regards.

    --
    Athmane Madjoudj

Related Discussions

People

Translate

site design / logo © 2022 Grokbase