Migrating to our own bugzilla instance.

"Jóhann B. Guðmundsson" johannbg at gmail.com
Wed Sep 18 20:27:16 UTC 2013


On 09/18/2013 06:16 PM, Stephen John Smoogen wrote:

> Wat? They are in their own branches. Now if you are saying that 
> maintainers should not have %{epel} in a fedora spec file.. well that 
> is between you and FESCO or you and the maintainer.
>

The %{epel} along with RHEL and related If's in a Fedora spec file.

I'm not sure if you are aware of it but as soon as we start cleaning up 
core/baseOS as well as anything that comes on top of that be it products 
or something else we need to clean and macronize as much in the process 
to make ourselves more flexible to adapting to changes in the IT 
environment ( as well as being able to integrate features at faster pace ).

> 1) Any bugzilla would require a lot of hardware/software. The current 
> bugzilla runs with multiple front ends (2-4) and multiple back end 
> database servers (somewhere between 7 and 10). We are one of the 
> largest users of the Red Hat bugzilla so we would not be needing 
> anything less because they aren't there for storage as much as 
> scalability so that is a starting project price of $70->$120k not 
> including power, cooling, storage, bandwidth and maintenance. (fast 
> storage may make it much more). From talks with other large sites 
> using Jira, Mantis, etc this will not change on which bug system we 
> use because it is the nature of the number of bugs, lookups, updates, 
> etc. If Fedora QA is interested in it, we can look at requesting from 
> Red Hat that in the next fiscal year.

Encase you have not noticed our QA has shrunken quite a bit at least 
from the point I started working on the systemd integration ( with 
bugzappers and proven packager dying off in that time ) and essentially 
with me being the only one and the Red Hat's QA team on blocker bug 
meetings and go/no-go.

  Now Red Hat's take on that is invent more QA community manager 
position pick them off the street and dump them into the community or 
the other magic solution "let's automate everything! While the fact is 
we ( as in QA ) quite frankly desperately need to find a way to mobilize 
people from my point of view since in the end of the day we will always 
need human beings testing to certain extent. ( or as some people want 
have everything users do report to bugzilla which quickly just becomes 
noise in maintainers ears, which means more bugs being ignored )

One such way is for us to take advantage of "badges" which will allows 
to atleast have a carrot out there until the individual realize he can 
never be on the top, and to do so we need hacking access to bugzilla 
which we are not allowed since it's shared with RHEL and there is always 
that risk that something slips out from there that should be slip.

>
> 2) The large bug bases require at least 2 full time people dealing 
> with them. Most volunteers are part-time people who tend to start them 
> up, burn out, get replaced with new volunteers who reimplement, etc. 
> Volunteers are useful if a full time people are around.

Perhaps infrastructure wize to certain extent but otherwise I disagree 
with you. I've gone through couple of RH employees that have burned out 
or simply changes jobs or focus within RH, so employees are affected by 
this as well and arguably in a shorter time then the volunteer.

>
> 3) We would need a complete bug day for any bug system we would use 
> because existing bugs rely on lots of internal sql code which would be 
> stuff Johann wants to remove for either slowness or not Fedora 
> specific calls. Removing them might lower the number of scaling 
> systems but most of the bug people have said you just replace them 
> quickly with new items which remove any savings.
>
>
> Final point,  EPEL is not just for RHEL. EPEL is what brings a lot of 
> people into Fedora because they see a need for a package they want in 
> RHEL and find out that they need to help it in Fedora before they can 
> get it in EPEL. Also the number of systems using EPEL is 10x the 
> number of Fedora users. So trying to get rid of EPEL is cutting off 
> ones nose to spite ones face.  If you do not like Red Hat is the 
> primary sponsor for Fedora, then I am sorry, but there isn't anything 
> that I or anyone else here on this list can do.

Well we can always try to find other ways to finance ourselves but I 
dont mind RH being our primary sponsor ( I would like to see more 
companies in the role of primary ) but I really much dislike certain 
disrespect RH shows the community by tearing us a new one like they did 
recently in QA community or for example with the WG nomination where RH 
employees had already signed without the community even knowing if it's 
existence or that Gnome tunnel vision and the discrimination it brings 
against other contributors and their work .

JBG


More information about the infrastructure mailing list