[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Independent Fedora bug tracker

On Wednesday 22 April 2009 10:42:02 am Basil Mohamed Gohar wrote:
> Forgive me for being so bold, but it's an issue I've felt strongly about
> for quite some time now - namely, that I believe the Fedora Project
> community should be hosting our own bug/issue tracker.  From what I've
> read & heard, this issue has come up before and the decision was to stay
> with the RH Bugzilla.  This doesn't discourage me in the least, though,
> and I think that's never a reason not to try again.

> And now, on to the advantages as I see them:
>    1. Fedora SHOULD have it's own issue tracking system, just like
>       Fedora SHOULD be a community project.  I mean, Fedora is either
>       driven by the community or not.  I do not think this is
>       detrimental to Red Hat at all, because Red Hat benefits directly
>       from the success of Fedora.
>    2. We would be able to tie FAS & the issue tracker together without
>       too many legal problems, hopefully.
>    3. Red Hat Bugzilla is SLOW.  I'm serious.  It's that big of an issue
>       for me.  I hope having our own would make it "go faster".
> Honestly, I feel reason #1 is sufficient, but I thought I may as well
> add a few technical points to get the ball rolling.  So, here's hoping
> this doesn't turn into a flame fest!

Biggest Con is that infrastructure which already has limited resources would 
need to run it. AFAIK  we have no one with experience that could setup and run 
a bugzilla/ other bug tracking system.  this is largely the reason why we have 
not done it.   

The other reason its not been done is that we need a way to move bugs to Red 
Hat's bugzilla and move from Red Hat's bugzilla to whatever we run.  people 
misfile bugs.  they effect fedora and rhel and need cloning.  there is alot of 
extra bits needed that you seem to not have considered.  

Step 1 find people to do the work,
Step 2 do an analysis of the needed workflows.
Step 3 find hardware, bandwidth and all needed resources
Step 4 setup system, and migration plans

Just trying to point out its not as simple as you seem to think.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]