10:42 a.m.
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.
After following this list for a while now, I've learned a bit about the
culture here, so I want to level the playing field a bit (since I'm
already being bold). So here are the rules:
1. Please provide constructive criticism, rather than just saying,
"We tried and it didn't work" or "This is why this will
fail".
Fedora is built on lots of things many others have said would be
impossible or impractical.
2. Please bring up consequences of a community-run issue tracker
compared to Red Hat running it (keeping in mind point #1)
3. Only FOSS solutions should be suggested, if someone is going to do
that (I won't cry if we drop Bugzilla). If anyone mentions JIRA,
I may reach through the screen and strangle you...(I'm looking at
you, Moodle & Zend Framework!)
4. Keep in mind that not everyone has the same level of experience
(This is mostly for my benefit). Share your wisdom, but try not
to be a jerk about it.
5. If you think something is so obviously wrong about the idea, then
view that more as a challenge to overcome than an insurmountable
hurdle. Again, see #1 above.
6. I hold zero power to make this happen directly (except by good-ol'
gumption, I suppose). So, don't think that I'm trying to
single-handedly change things. I'm just proposing the idea.
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!
10:47 a.m.
On Wed, 2009-04-22 at 23:42 +0800, 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.
This discussion is moot unless you can find someone with the manpower,
hardware, bandwidth, and expertise to maintain such a bug tracker -
24/7/365 - for the entire Fedora community.
So far we've identified *one* organization willing to do that - Red
Hat's Bugzilla team.
Unless you've got someone else who can commit to that, there's really
nothing else to discuss.
-w
11:01 a.m.
On 04/22/2009 11:47 PM, Will Woods wrote:
On Wed, 2009-04-22 at 23:42 +0800, 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.
>
This discussion is moot unless you can find someone with the manpower,
hardware, bandwidth, and expertise to maintain such a bug tracker -
24/7/365 - for the entire Fedora community.
So far we've identified *one* organization willing to do that - Red
Hat's Bugzilla team.
Unless you've got someone else who can commit to that, there's really
nothing else to discuss.
-w
Just to stick to the guidelines I made in the original post, could you
please enlighten me as to the extent of work involved in maintaining
Fedora's portion of Bugzilla? For example, how many people, machines,
TBs, & experts *maintain* Fedora's portion of Bugzilla? These are
legitimate questions, especially since you've posted them as a "blocker"
to my proposal.
With that out of the way, I really would like to know how hard it is to
maintain an issue tracker for a FOSS project as large as Fedora. My
initial idea is, "Not really", aside from the scale. If that's far off,
I' really appreciate knowing the daily challenges faced in keeping
Bugzilla up-and-running.
Are you on the Bugzilla team? If not, could you cajole someone from the
team to respond? I'd really appreciate it. Thanks!
10:57 a.m.
Basil Mohamed Gohar <abu_hurayrah(a)hidayahonline.org> writes:
And now, on to the advantages as I see them:
It would be polite of you to at least acknowledge that there might
be DISadvantages.
The main one from my personal perspective is that I don't need an
extra bug tracker in my daily work. Right now, Red Hat's bugzilla
is all that I need to look at to handle both RHEL and Fedora
responsibilities. If there are two trackers involved, one or the
other is going to get looked at less frequently, and given who pays
me I'm afraid Fedora is going to lose out.
Now the above argument means nothing much if you just consider my
personal effort compared to all of Fedora, but when you consider that
it applies to every Red Hat engineer I think it becomes significant.
There are enough Red Hat people involved in Fedora that penalizing
all of us will put a noticeable drag on the project.
regards, tom lane
11:07 a.m.
On 04/22/2009 11:57 PM, Tom Lane wrote:
Basil Mohamed Gohar<abu_hurayrah(a)hidayahonline.org> writes:
> And now, on to the advantages as I see them:
>
It would be polite of you to at least acknowledge that there might
be DISadvantages.
The main one from my personal perspective is that I don't need an
extra bug tracker in my daily work. Right now, Red Hat's bugzilla
is all that I need to look at to handle both RHEL and Fedora
responsibilities. If there are two trackers involved, one or the
other is going to get looked at less frequently, and given who pays
me I'm afraid Fedora is going to lose out.
Now the above argument means nothing much if you just consider my
personal effort compared to all of Fedora, but when you consider that
it applies to every Red Hat engineer I think it becomes significant.
There are enough Red Hat people involved in Fedora that penalizing
all of us will put a noticeable drag on the project.
regards, tom lane
Those are some really good points. In the "FOSS needs a central
bugtracker" thread, there's an idea of issue trackers communicating with
each other. Theoretically, this would alleviate some, if not all, of
the work load of someone having to check two issue trackers, because if
one can be consider upstream to the other, then the data can flow with
the work only needing to be done in one place.
I definitely acknowledge disadvantages, but I am also definitely arguing
this from a community standpoint. Having said that, I did not want to
minimize what Red Hat contributes to Fedora. And having said *that*,
Red Hat will benefit from anything that benefits Fedora. Directly.
I believe a solution exists where Fedora's independence in terms of
issue tracking is not a burden on Red Hat's contributors to it. But I
don't know that I have the experience to say what that solution is just
yet. Hence, this thread for brainstorming. ;)
3:18 a.m.
On 2009-04-22, 16:07 GMT, Basil Mohamed Gohar wrote:
Those are some really good points. In the "FOSS needs
a central bugtracker" thread, there's an idea of issue trackers
communicating with each other. Theoretically, this would
alleviate some, if not all, of the work load of someone having
to check two issue trackers, because if one can be consider
upstream to the other, then the data can flow with the work
only needing to be done in one place.
<rant>
OK, either you are trolling or you are serious and you have some
brainpower to stand behind your words.
If the former, then read
http://slashdot.org/features/98/10/13/1423253.shtml very
carefully and then go and do something useful.
If the latter, then I have a couple of bugs for you to solve:
https://bugzilla.redhat.com/show_bug.cgi?id=452962 -- that should
be easy, just make periodic XML-RPC requests and store it in the
database.
https://bugzilla.redhat.com/show_bug.cgi?id=189813 -- OK, this is
biggie, and you will need to work closely with people around
http://www.bugzilla.org . On the other hand, I heard they work on
this, so any real help you can provide to them would be very
welcome.
And fixing either of these would actually help somebody (me
included; yes, I would love to click on the button "Move
upstream" in RH Bugzilla) to fix bugs better. Your suggestion
(aside from making a lot of work for somebody else, not talking
about huge costs in hardware and bandwidth -- and yes, they are
huge, just believe me) doesn't seem to help to anybody.
</rant>
Matěj
7 a.m.
On 04/23/2009 04:18 PM, Matej Cepl wrote:
On 2009-04-22, 16:07 GMT, Basil Mohamed Gohar wrote:
> Those are some really good points. In the "FOSS needs
> a central bugtracker" thread, there's an idea of issue trackers
> communicating with each other. Theoretically, this would
> alleviate some, if not all, of the work load of someone having
> to check two issue trackers, because if one can be consider
> upstream to the other, then the data can flow with the work
> only needing to be done in one place.
>
<rant>
OK, either you are trolling or you are serious and you have some
brainpower to stand behind your words.
If the former, then read
http://slashdot.org/features/98/10/13/1423253.shtml very
carefully and then go and do something useful.
If the latter, then I have a couple of bugs for you to solve:
https://bugzilla.redhat.com/show_bug.cgi?id=452962 -- that should
be easy, just make periodic XML-RPC requests and store it in the
database.
https://bugzilla.redhat.com/show_bug.cgi?id=189813 -- OK, this is
biggie, and you will need to work closely with people around
http://www.bugzilla.org . On the other hand, I heard they work on
this, so any real help you can provide to them would be very
welcome.
And fixing either of these would actually help somebody (me
included; yes, I would love to click on the button "Move
upstream" in RH Bugzilla) to fix bugs better. Your suggestion
(aside from making a lot of work for somebody else, not talking
about huge costs in hardware and bandwidth -- and yes, they are
huge, just believe me) doesn't seem to help to anybody.
</rant>
Matěj
While I don't agree with your dichotomy, I have to be honest and say
that, at the moment, I am no way ready to undertake a task like this
myself right now.
Having said that, the fact that I am not able to do this myself does not
automatically exclude me from making the suggestion and participating in
the brainstorming that follows. I definitely *use* Fedora/Red Hat's
Bugzilla, so I am speaking from my own experiences with it, and my
suggestion is to improve that experience. I realize Fedora comes with
no official support, so I hope no one thinks I'm expecting any, either. ;)
11:06 a.m.
On 2009-04-23, 12:00 GMT, Basil Mohamed Gohar wrote:
Having said that, the fact that I am not able to do this myself
does not automatically exclude me from making the suggestion
and participating in the brainstorming that follows.
I definitely *use* Fedora/Red Hat's Bugzilla, so I am speaking
from my own experiences with it, and my suggestion is to
improve that experience. I realize Fedora comes with no
official support, so I hope no one thinks I'm expecting any,
either. ;)
Thanks for taking my rant well, but trust me ... I went through
more bugzilla bug reports than most of the people here (I am
employed as bug triager at Red Hat). On the top of not that fast
bugzilla I use a lot of Greasemonkey scripts so my pages are
a little bit slower.
But still there are ways how to make it working (and I do every
workday) ... for example you can Ctrl-<click> couple of tabs from
your query and let them download on the background while you work
on the first one.
If the speed of bugzilla was the biggest problem we have, we
would be most lucky people in the world.
And do please read that Alan Cox's article ... it is one of the
finest pieces of writing on open source development I have ever
seen (and as a former lawyer I read a lot).
Best,
Matej
11:29 a.m.
On Wed, 22 Apr 2009, Tom Lane wrote:
Basil Mohamed Gohar <abu_hurayrah(a)hidayahonline.org> writes:
> And now, on to the advantages as I see them:
It would be polite of you to at least acknowledge that there might
be DISadvantages.
The main one from my personal perspective is that I don't need an
extra bug tracker in my daily work. Right now, Red Hat's bugzilla
is all that I need to look at to handle both RHEL and Fedora
responsibilities. If there are two trackers involved, one or the
other is going to get looked at less frequently, and given who pays
me I'm afraid Fedora is going to lose out.
As a RHEL, CentOS, and Fedora user it is also nice to have only one place
to go to file my bugs, see which ones are still open, etc.
-Mike
3:23 a.m.
On 2009-04-22, 15:57 GMT, Tom Lane wrote:
If there are two trackers involved, one or the
other is going to get looked at less frequently, and given who pays
me I'm afraid Fedora is going to lose out.
I would add that there are components, which I am going through
just because it is more convenient to do so, but in case I would
have to set up new queries just to satisfy somebody's need for
change, I would just skip them ... seamonkey, epiphany, galeon,
that's about you, I am talking!
Matej
11 a.m.
Honestly, I disagree.
RedHat as a company provides a lot to the community. Think of e.g. Dan
Williams work on NM, that is used by all (including competeting) distros
end most users.
I, personally, think of using fedora as "beta testing" red hat in a way
that means: If I report a bug, eventually Red Hat can improve its
product.
The conclusion: As long as there are no real regressions in community
bugfixing, I think all those bug reports are a little price compared to
what "we" consume.
regards
christoph
ps: the slowness ... yes, I know. Somebody should really fix this...
11:14 a.m.
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.
Dennis
11:23 a.m.
On 04/23/2009 12:14 AM, Dennis Gilmore wrote:
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.
Dennis
Actually, I think the Fedora Infrastructure team, from what I've
witnessed, is more the capable of doing this. Unless I'm totally
clueless (which I may be), if Fedora Infrastructure undertook running an
issue tracking system themselves, I do not think it would be the most
complex system in the whole project. I think they handle far more
challenging tasks on a day-to-day basis.
I think the misfiling of bugs would be far *less* if we had separate
issue trackers. What are the odds a Fedora user is going to file
something on Red Hat's Bugzilla, if they've never heard of it before (I
can understand, during the transition, a lot of this happening).
Likewise, who would file a bug for RHEL in Fedora's issue tracker, if
they're completely separate websites? Maybe I just didn't understand
what you meant here.
I definitely didn't think it was simple. Rather, I feel it is important
and we should make a goal to achieve.
And everyone keeps talking about bandwidth for Bugzilla. Am I missing
something? Are there huge binary files being transferred that I'm
missing? How many GB/day are we talking?
I believe allowing Fedora Infrastructure to run their own issue tracker
will result in a leaner & meaning instance that will likely run better
than Red Hat's, if only because it'll be fresher, but also because
they'll have greater control to suit the community's needs.
11:26 a.m.
On Thu, 23 Apr 2009, Basil Mohamed Gohar wrote:
On 04/23/2009 12:14 AM, Dennis Gilmore wrote:
> 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.
>
> Dennis
Actually, I think the Fedora Infrastructure team, from what I've witnessed, is
more the capable of doing this. Unless I'm totally clueless (which I may be),
if Fedora Infrastructure undertook running an issue tracking system
themselves, I do not think it would be the most complex system in the whole
project. I think they handle far more challenging tasks on a day-to-day
basis.
Nothing personal but you're not in a position to make this judgement.
We've not even setup a test version populated with data about the size
that would be required for Fedora so no analysis of what we could or could
not do has been done.
-Mike
I think the misfiling of bugs would be far *less* if we had separate
issue
trackers. What are the odds a Fedora user is going to file something on Red
Hat's Bugzilla, if they've never heard of it before (I can understand, during
the transition, a lot of this happening). Likewise, who would file a bug for
RHEL in Fedora's issue tracker, if they're completely separate websites?
Maybe I just didn't understand what you meant here.
I definitely didn't think it was simple. Rather, I feel it is important and
we should make a goal to achieve.
And everyone keeps talking about bandwidth for Bugzilla. Am I missing
something? Are there huge binary files being transferred that I'm missing?
How many GB/day are we talking?
I believe allowing Fedora Infrastructure to run their own issue tracker will
result in a leaner & meaning instance that will likely run better than Red
Hat's, if only because it'll be fresher, but also because they'll have
greater
control to suit the community's needs.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11:36 a.m.
On 04/23/2009 12:26 AM, Mike McGrath wrote:
On Thu, 23 Apr 2009, Basil Mohamed Gohar wrote:
> Actually, I think the Fedora Infrastructure team, from what I've witnessed, is
> more the capable of doing this. Unless I'm totally clueless (which I may be),
> if Fedora Infrastructure undertook running an issue tracking system
> themselves, I do not think it would be the most complex system in the whole
> project. I think they handle far more challenging tasks on a day-to-day
> basis.
>
>
Nothing personal but you're not in a position to make this judgement.
We've not even setup a test version populated with data about the size
that would be required for Fedora so no analysis of what we could or could
not do has been done.
-Mike
I know that. I'm just a Fedora user. This thread is exploratory, and
I'm trying to get this kind of information out there. I didn't mean to
speak for the team at all, I just wanted to say I think greater problems
have been tackled.
Is Bugzilla so hard to manage, though? Is the data really that enormous?
Another example that comes to mind, though definitely not
apples-to-apples, was the migration from MoinMoin to MediaWiki. Yes, I
realize Bugzilla does much more than a wiki does, but I witnessed a lot
of the process of that migration, and yes, it's still ongoing, and there
was stumbling along the way. But the community really came together on
that and helped-out. I also realize that currently, Bugzilla is much
more of a core app to both Fedora & Red Hat than the Wiki is or likely
ever will be. But the concept of migrating a system is not new to
Fedora. The key is how can we leverage the community to help with it.
11:51 a.m.
On Thu, 23 Apr 2009, Basil Mohamed Gohar wrote:
On 04/23/2009 12:26 AM, Mike McGrath wrote:
> On Thu, 23 Apr 2009, Basil Mohamed Gohar wrote:
>
> > Actually, I think the Fedora Infrastructure team, from what I've
> > witnessed, is
> > more the capable of doing this. Unless I'm totally clueless (which I may
> > be),
> > if Fedora Infrastructure undertook running an issue tracking system
> > themselves, I do not think it would be the most complex system in the
> > whole
> > project. I think they handle far more challenging tasks on a day-to-day
> > basis.
> >
> >
>
> Nothing personal but you're not in a position to make this judgement.
> We've not even setup a test version populated with data about the size
> that would be required for Fedora so no analysis of what we could or could
> not do has been done.
>
> -Mike
I know that. I'm just a Fedora user. This thread is exploratory, and I'm
trying to get this kind of information out there. I didn't mean to speak for
the team at all, I just wanted to say I think greater problems have been
tackled.
Is Bugzilla so hard to manage, though? Is the data really that enormous?
"I don't know" and "I don't know" which is why I can't
say "yes we can do
that" or "no we can't do that"
Another example that comes to mind, though definitely not
apples-to-apples,
was the migration from MoinMoin to MediaWiki. Yes, I realize Bugzilla does
much more than a wiki does, but I witnessed a lot of the process of that
migration, and yes, it's still ongoing, and there was stumbling along the way.
But the community really came together on that and helped-out. I also realize
that currently, Bugzilla is much more of a core app to both Fedora & Red Hat
than the Wiki is or likely ever will be. But the concept of migrating a
system is not new to Fedora. The key is how can we leverage the community to
help with it.
Lots of pre-work went into that to determine its feasibility. With
bugzilla we're not even at the "could we" stage, we're still at the
"should we try" stage of which I only play a small part of.
-Mike
11:57 a.m.
On 04/23/2009 12:51 AM, Mike McGrath wrote:
On Thu, 23 Apr 2009, Basil Mohamed Gohar wrote:
> Is Bugzilla so hard to manage, though? Is the data really that enormous?
>
>
"I don't know" and "I don't know" which is why I can't
say "yes we can do
that" or "no we can't do that"
I didn't really mean those questions for you, but rather, they're
somewhat rhetorical. The impression I'm getting is that Bugzilla is
some kind of mammoth app that requires a huge investment of resources to
run & maintain. I thought it was just an enterprise-level bug tracker.
It's deployed quite widely.
> Another example that comes to mind, though definitely not
apples-to-apples,
> was the migration from MoinMoin to MediaWiki. Yes, I realize Bugzilla does
> much more than a wiki does, but I witnessed a lot of the process of that
> migration, and yes, it's still ongoing, and there was stumbling along the way.
> But the community really came together on that and helped-out. I also realize
> that currently, Bugzilla is much more of a core app to both Fedora& Red Hat
> than the Wiki is or likely ever will be. But the concept of migrating a
> system is not new to Fedora. The key is how can we leverage the community to
> help with it
Lots of pre-work went into that to determine its feasibility. With
bugzilla we're not even at the "could we" stage, we're still at the
"should we try" stage of which I only play a small part of.
-Mike
It is my sincere hope that this thread will bring the "could we"
stage
just a little bit closer by getting more eyes on it and more minds
engaged in it.
2:02 a.m.
On 04/22/2009 10:27 PM, Basil Mohamed Gohar wrote:
>
I didn't really mean those questions for you, but rather, they're
somewhat rhetorical. The impression I'm getting is that Bugzilla is
some kind of mammoth app that requires a huge investment of resources to
run & maintain. I thought it was just an enterprise-level bug tracker.
It's deployed quite widely.
Enterprise level and mammoths go hand in hand.
Rahul
11:33 a.m.
On Wednesday 22 April 2009 11:23:31 am Basil Mohamed Gohar wrote:
On 04/23/2009 12:14 AM, Dennis Gilmore wrote:
> 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.
>
> Dennis
Actually, I think the Fedora Infrastructure team, from what I've
witnessed, is more the capable of doing this. Unless I'm totally
clueless (which I may be), if Fedora Infrastructure undertook running an
issue tracking system themselves, I do not think it would be the most
complex system in the whole project. I think they handle far more
challenging tasks on a day-to-day basis.
As one of the people on the infrasructure
team i'm telling you we do not have
the resources or knowledge for this.
It has taken us a long time to think about migrating mailing lists. Which we
are slowly doing.
I think the misfiling of bugs would be far *less* if we had separate
issue trackers. What are the odds a Fedora user is going to file
something on Red Hat's Bugzilla, if they've never heard of it before (I
can understand, during the transition, a lot of this happening).
Likewise, who would file a bug for RHEL in Fedora's issue tracker, if
they're completely separate websites? Maybe I just didn't understand
what you meant here.
I definitely didn't think it was simple. Rather, I feel it is important
and we should make a goal to achieve.
And everyone keeps talking about bandwidth for Bugzilla. Am I missing
something? Are there huge binary files being transferred that I'm
missing? How many GB/day are we talking?
Bandwidth doesnt just come out of the air. all of fedoras bandwidth is
donated by someone. as is alot of the hardware that we have.
I believe allowing Fedora Infrastructure to run their own issue
tracker
will result in a leaner & meaning instance that will likely run better
than Red Hat's, if only because it'll be fresher, but also because
they'll have greater control to suit the community's needs.
We would need to import every fedora bug from Red Hats bugzilla. it would be
smaller but not that much smaller. If we dont do this we would create alot fo
confusion.
I suggest that you take this to the infrastructure list. fedora-devel is
really the wrong place for this discussion.
Dennis
11:49 a.m.
Dennis Gilmore <dennis(a)ausil.us> writes:
On Wednesday 22 April 2009 11:23:31 am Basil Mohamed Gohar wrote:
> I believe allowing Fedora Infrastructure to run their own issue tracker
> will result in a leaner & meaning instance that will likely run better
> than Red Hat's, if only because it'll be fresher, but also because
> they'll have greater control to suit the community's needs.
We would need to import every fedora bug from Red Hats bugzilla. it
would be smaller but not that much smaller. If we dont do this we
would create alot fo confusion.
Bear in mind that database performance tends to scale about as log(N),
assuming that the DB is properly set up and maintained. Even if a
Fedora-only DB instance were a factor of 10 smaller than the current
RHEL+Fedora instance (which I suspect is an optimistic estimate), there
would not be that much change in perceived response times.
Red Hat's bugzilla does seem to be tremendously slow at times. As best
I've been able to tell, though, most of the slowness that I see comes
from network delays and not the database proper. Redesigning the HTML
it puts out (to not require so many network round-trips to display a
page) might do far more for us than any amount of database fiddling.
regards, tom lane
11:54 a.m.
-------- Original Message --------
Subject: Re: Independent Fedora bug tracker
From: Tom Lane <tgl(a)redhat.com>
To: Development discussions related to Fedora <fedora-devel-list(a)redhat.com>
Date: 04/22/2009 11:49 AM
Red Hat's bugzilla does seem to be tremendously slow at times. As best
I've been able to tell, though, most of the slowness that I see comes
from network delays and not the database proper. Redesigning the HTML
it puts out (to not require so many network round-trips to display a
page) might do far more for us than any amount of database fiddling.
regards, tom lane
May I suggest that any javascript be moved to separate files and tables
(yes I see them) use <div>s? Just on the front page I see bare
Javascript that could be separated for a minor boost (web crawlers wont
download separate files).
3:04 p.m.
Basil Mohamed Gohar wrote:
3. Only FOSS solutions should be suggested, if someone is going to
do
that (I won't cry if we drop Bugzilla). If anyone mentions JIRA,
I may reach through the screen and strangle you...(I'm looking at
you, Moodle & Zend Framework!)
Somewhat related: have RH's customizations to Bugzilla ever been released?
If not, can they be? If not, wouldn't that alone be a reason to have a
separate instance for Fedora? We're proudly stating that our infrastructure
is running entirely on Free Software, but that only goes so far if the
software we're using has unpublished local patches.
Kevin Kofler
2:58 a.m.
On 2009-04-22, 20:04 GMT, Kevin Kofler wrote:
Somewhat related: have RH's customizations to Bugzilla ever
been released?
I believe that everything what's reasonable (e.g., not some
RHEL-management stuff) was sent upstream. I know for sure that
Dave Lawrence (the main bugzilla magician in Red Hat) works
really hard on keeping the RH-customization as small as possible
-- after being burnt severely with previous instance of bugzilla
(where upgrade to BZ 3.0 took over a year) they are trying to
keep the customizations lean. And if you noticed, we had couple
of upgrades of bugzilla to the latest version. I didn't, unless
somebody reminded me.
Matej
2:11 a.m.
On Wed, Apr 22, 2009 at 10:42 AM, Basil Mohamed Gohar
<abu_hurayrah(a)hidayahonline.org> wrote:
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".
How slow is it? And how is moving to a new buzilla going to help with
that? I use it regularly enough, I haven't noticed anything special
about it of late.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
3:29 a.m.
On Thu, Apr 23, 2009 at 2:11 AM, Arthur Pemberton <pemboa(a)gmail.com> wrote:
On Wed, Apr 22, 2009 at 10:42 AM, Basil Mohamed Gohar
<abu_hurayrah(a)hidayahonline.org> wrote:
> 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".
How slow is it? And how is moving to a new buzilla going to help with
that? I use it regularly enough, I haven't noticed anything special
about it of late.
How had you not noticed how slow it is? For me, on average it takes
approximately 2.5sec to load a page. Red Hat Bugzilla takes approximately
15-20sec to load a page. This gets really bad when you consider the number
of pages you go through to get stuff done in the bugzilla. However, I
severely doubt Red Hat or the Fedora Project will allow the separation of
bug trackers at this time for the simple reason that Fedora bugs are often
tied to Red Hat bugs. All Red Hat people would have to do is tag a bug for
RHEL in addition to Fedora. This kind of bug tracking simplicity is
something I doubt they would be willing to give up.
In any case, it might be a better idea to move off of Bugzilla and to
something else. I would like to suggest Mantis Bug Tracker (
http://mantisbt.org). It is quite nice in my experience and it even has
scripts available to migrate from Bugzilla to MantisBT. In my experience, it
is closer to the average page load that I usually get than Bugzilla, taking
at most 5sec to load a page with it being less than 3sec most of the time.
12:43 p.m.
On Thu, 2009-04-23 at 03:29 -0500, King InuYasha wrote:
However, I severely doubt Red Hat or the Fedora Project will allow
the
separation of bug trackers at this time for the simple reason that
Fedora bugs are often tied to Red Hat bugs. All Red Hat people would
have to do is tag a bug for RHEL in addition to Fedora. This kind of
bug tracking simplicity is something I doubt they would be willing to
give up.
Well, er, not really. Ironically, not being able to do that is one of
the biggest limitations of Bugzilla. You can't tag a bug on b.r.c as
being in both Fedora and RHEL. The Product field can only be set to
Fedora *or* RHEL, not both. If you really need to track an issue that
affects both, you need two reports.
(Since the Bugzilla flow for RHEL is rather different from and more
rigorous than the one for Fedora, this is likely to be needed in any
case).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:58 p.m.
On Thu, Apr 23, 2009 at 3:29 AM, King InuYasha <ngompa13(a)gmail.com> wrote:
On Thu, Apr 23, 2009 at 2:11 AM, Arthur Pemberton
<pemboa(a)gmail.com> wrote:
>
> On Wed, Apr 22, 2009 at 10:42 AM, Basil Mohamed Gohar
> <abu_hurayrah(a)hidayahonline.org> wrote:
>
> > 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".
>
>
> How slow is it? And how is moving to a new buzilla going to help with
> that? I use it regularly enough, I haven't noticed anything special
> about it of late.
>
How had you not noticed how slow it is? For me, on average it takes
approximately 2.5sec to load a page. Red Hat Bugzilla takes approximately
15-20sec to load a page.
I cannot replicate this on one machine so far, I'll be trying another.
Are there any pages that are specifically bad? And wouldn't a thick
client which uses the XML-RPC interface to connect to multiple IMSs be
more useful that just playing catch with what ever IMS you prefer at
the time?
The rest of your post is irrelevant to my question.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
2:22 p.m.
Arthur Pemberton <pemboa(a)gmail.com> writes:
On Thu, Apr 23, 2009 at 3:29 AM, King InuYasha
<ngompa13(a)gmail.com> wrote:
> How had you not noticed how slow it is? For me, on average it takes
> approximately 2.5sec to load a page. Red Hat Bugzilla takes approximately
> 15-20sec to load a page.
I cannot replicate this on one machine so far, I'll be trying
another.
I think this squares with my theory up-thread that it's mostly a network
issue and not the database per se. It would be interesting to compare
the ping times the two of you see to bugzilla.redhat.com. For me the
ping time is around 120 msec and loading a single simple bug entry
takes about 3 seconds (on a good day, anyway ... it used to be a lot
worse ...)
From here in Pittsburgh I can ping sites in San Jose in 70-some msec,
so there is certainly plenty of room for improvement in
bugzilla.redhat.com's connectivity. It shouldn't take 120 to get
to Phoenix.
regards, tom lane
3:48 p.m.
On Thu, Apr 23, 2009 at 2:22 PM, Tom Lane <tgl(a)redhat.com> wrote:
Arthur Pemberton <pemboa(a)gmail.com> writes:
> On Thu, Apr 23, 2009 at 3:29 AM, King InuYasha <ngompa13(a)gmail.com> wrote:
>> How had you not noticed how slow it is? For me, on average it takes
>> approximately 2.5sec to load a page. Red Hat Bugzilla takes approximately
>> 15-20sec to load a page.
> I cannot replicate this on one machine so far, I'll be trying another.
I think this squares with my theory up-thread that it's mostly a network
issue and not the database per se. It would be interesting to compare
the ping times the two of you see to bugzilla.redhat.com. For me the
ping time is around 120 msec and loading a single simple bug entry
takes about 3 seconds (on a good day, anyway ... it used to be a lot
worse ...)
It could also just be a rendering speed of the browser. Really. As I
said, a good thick client would solve most of the problems indicated
in this thread.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
3:54 p.m.
On Thu, Apr 23, 2009 at 3:48 PM, Arthur Pemberton <pemboa(a)gmail.com> wrote:
On Thu, Apr 23, 2009 at 2:22 PM, Tom Lane <tgl(a)redhat.com>
wrote:
> Arthur Pemberton <pemboa(a)gmail.com> writes:
>> On Thu, Apr 23, 2009 at 3:29 AM, King InuYasha <ngompa13(a)gmail.com>
wrote:
>>> How had you not noticed how slow it is? For me, on average it takes
>>> approximately 2.5sec to load a page. Red Hat Bugzilla takes
approximately
>>> 15-20sec to load a page.
>
>> I cannot replicate this on one machine so far, I'll be trying another.
>
> I think this squares with my theory up-thread that it's mostly a network
> issue and not the database per se. It would be interesting to compare
> the ping times the two of you see to bugzilla.redhat.com. For me the
> ping time is around 120 msec and loading a single simple bug entry
> takes about 3 seconds (on a good day, anyway ... it used to be a lot
> worse ...)
It could also just be a rendering speed of the browser. Really. As I
said, a good thick client would solve most of the problems indicated
in this thread.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rendering speed of the browser? As if. I look at Bugzilla regularly in
various projects: Mozilla, ReactOS, Fedora, etc. and the Bugzilla is always
a bit slower than the rest of the site, true, but it is a lot more
pronounced on Red Hat's Bugzilla.
4:10 p.m.
King InuYasha <ngompa13(a)gmail.com> writes:
On Thu, Apr 23, 2009 at 3:48 PM, Arthur Pemberton
<pemboa(a)gmail.com> wrote:
> On Thu, Apr 23, 2009 at 2:22 PM, Tom Lane <tgl(a)redhat.com> wrote:
>> I think this squares with my theory up-thread that it's mostly a network
>> issue and not the database per se. It would be interesting to compare
>> the ping times the two of you see to bugzilla.redhat.com.
[ two responses, no data ]
I take it nobody wants to sully their complaining with actual facts
that might help narrow down the problem.
regards, tom lane
4:29 p.m.
On Thu, Apr 23, 2009 at 4:10 PM, Tom Lane <tgl(a)redhat.com> wrote:
King InuYasha <ngompa13(a)gmail.com> writes:
> On Thu, Apr 23, 2009 at 3:48 PM, Arthur Pemberton <pemboa(a)gmail.com> wrote:
>> On Thu, Apr 23, 2009 at 2:22 PM, Tom Lane <tgl(a)redhat.com> wrote:
>>> I think this squares with my theory up-thread that it's mostly a network
>>> issue and not the database per se. It would be interesting to compare
>>> the ping times the two of you see to bugzilla.redhat.com.
> [ two responses, no data ]
I take it nobody wants to sully their complaining with actual facts
that might help narrow down the problem.
regards, tom lane
From my desktop:
$ ping -c 50 -i 5 -q -s 512 bugzilla.redhat.com
PING bugzilla.redhat.com (209.132.176.231) 512(540) bytes of data.
--- bugzilla.redhat.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 245167ms
rtt min/avg/max/mdev = 114.606/118.980/135.277/3.966 ms
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
6:12 p.m.
On Thu, Apr 23, 2009 at 04:29:05PM -0500, Arthur Pemberton wrote:
On Thu, Apr 23, 2009 at 4:10 PM, Tom Lane <tgl(a)redhat.com>
wrote:
> King InuYasha <ngompa13(a)gmail.com> writes:
>> On Thu, Apr 23, 2009 at 3:48 PM, Arthur Pemberton <pemboa(a)gmail.com>
wrote:
>>> On Thu, Apr 23, 2009 at 2:22 PM, Tom Lane <tgl(a)redhat.com> wrote:
>>>> I think this squares with my theory up-thread that it's mostly a
network
>>>> issue and not the database per se. It would be interesting to compare
>>>> the ping times the two of you see to bugzilla.redhat.com.
>
>> [ two responses, no data ]
>
> I take it nobody wants to sully their complaining with actual facts
> that might help narrow down the problem.
>
> regards, tom lane
>From my desktop:
$ ping -c 50 -i 5 -q -s 512 bugzilla.redhat.com
PING bugzilla.redhat.com (209.132.176.231) 512(540) bytes of data.
--- bugzilla.redhat.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 245167ms
rtt min/avg/max/mdev = 114.606/118.980/135.277/3.966 ms
You could probably compare how fast the pages render via elinks vs
Firefox.
Don't know how much of the time is spent doing JavaScript or generating
the huge list of components...
I bet there's some sort of website profiling plugin for Firefox out
there that would help......
Ray
7:05 a.m.
On Friday 24 April 2009 00:12:41 Ray Van Dolson wrote:
Don't know how much of the time is spent doing JavaScript or
generating
the huge list of components...
From previous discussions, it seems the main issue has been the
JavaScript for
population the list of components. It's much slower in
"older" browsers than
the latest releases as well.
2:49 a.m.
On 2009-04-24, 12:05 GMT, Bill Crawford wrote:
On Friday 24 April 2009 00:12:41 Ray Van Dolson wrote:
> Don't know how much of the time is spent doing JavaScript or generating
> the huge list of components...
Huge list of components has not been generated
per default for
couple of months already.
Matej
9:44 a.m.
On Saturday 25 April 2009 08:49:19 Matej Cepl wrote:
On 2009-04-24, 12:05 GMT, Bill Crawford wrote:
> On Friday 24 April 2009 00:12:41 Ray Van Dolson wrote:
>> Don't know how much of the time is spent doing JavaScript or generating
>> the huge list of components...
Huge list of components has not been generated per default for
couple of months already.
Erm ... where's this big list selector "Component" coming from, then?
Matej
1:39 a.m.
* Arthur Pemberton [24/04/2009 00:59] :
$ ping -c 50 -i 5 -q -s 512 bugzilla.redhat.com
Please use Firefox's Yslow extension if you want to give us
meaningful data.
Emmanuel
4:28 a.m.
On 04/24/2009 09:39 AM, Emmanuel Seyman wrote:
* Arthur Pemberton [24/04/2009 00:59] :
> $ ping -c 50 -i 5 -q -s 512 bugzilla.redhat.com
>
Please use Firefox's Yslow extension if you want to give us
meaningful data.
from my home connection Yslow says 7-15 secs. For instance in the case of
https://bugzilla.redhat.com/show_bug.cgi?id=189949 , yslow prints C
274.3K 11.881s
https://bugzilla.redhat.com/show_bug.cgi?id=489135 , yslow prints 7.138 s
https://bugzilla.redhat.com/request.cgi?requester=wolfy%40nobugconsulting...
I get B 242.8K 6.56s
http://tinyurl.com/dl8mmt 6.688 s
http://fedoraproject.org/wiki/ 4.503s
http://fedoraproject.org/wiki/PackageMaintainers 4.111s
http://fedoraproject.org/wiki/BugZappers 2.08s
http://fedoraproject.org/wiki/Extras/PackageStatus 8.733 s
11:11 a.m.
On Fri, Apr 24, 2009 at 4:28 AM, Manuel Wolfshant
<wolfy(a)nobugconsulting.ro> wrote:
On 04/24/2009 09:39 AM, Emmanuel Seyman wrote:
>
> * Arthur Pemberton [24/04/2009 00:59] :
>
>>
>> $ ping -c 50 -i 5 -q -s 512 bugzilla.redhat.com
>>
>
> Please use Firefox's Yslow extension if you want to give us
> meaningful data.
>
from my home connection Yslow says 7-15 secs. For instance in the case of
https://bugzilla.redhat.com/show_bug.cgi?id=189949 , yslow prints C 274.3K
11.881s
https://bugzilla.redhat.com/show_bug.cgi?id=489135 , yslow prints 7.138 s
https://bugzilla.redhat.com/request.cgi?requester=wolfy%40nobugconsulting...
I get B 242.8K 6.56s
http://tinyurl.com/dl8mmt 6.688 s
http://fedoraproject.org/wiki/ 4.503s
http://fedoraproject.org/wiki/PackageMaintainers 4.111s
http://fedoraproject.org/wiki/BugZappers 2.08s
http://fedoraproject.org/wiki/Extras/PackageStatus 8.733 s
https://bugzilla.redhat.com/show_bug.cgi?id=189949 , yslow prints 3.535
https://bugzilla.redhat.com/show_bug.cgi?id=489135 , yslow prints 3.552
https://bugzilla.redhat.com/request.cgi?requester=wolfy%40nobugconsulting...
I get 4.311
http://tinyurl.com/dl8mmt 6.688 s
http://fedoraproject.org/wiki/ 1.729
http://fedoraproject.org/wiki/PackageMaintainers 5.337
http://fedoraproject.org/wiki/BugZappers 0.896
http://fedoraproject.org/wiki/Extras/PackageStatus 2.858
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
12:45 a.m.
On Do April 23 2009, Tom Lane wrote:
King InuYasha <ngompa13(a)gmail.com> writes:
> On Thu, Apr 23, 2009 at 3:48 PM, Arthur Pemberton <pemboa(a)gmail.com>
wrote:
>> On Thu, Apr 23, 2009 at 2:22 PM, Tom Lane
<tgl(a)redhat.com> wrote:
>>> I think this squares with my theory up-thread that it's mostly a
>>> network issue and not the database per se. It would be interesting to
>>> compare the ping times the two of you see to bugzilla.redhat.com.
>
> [ two responses, no data ]
I take it nobody wants to sully their complaining with actual facts
that might help narrow down the problem.
Here it takes around 13-15 seconds to load a Red Hat bugzilla but report.
Ping is 230 ms and for one bug report, Firefox creates 20 requests which all
have to do a seperate SSL handshake, because the server does not support to
keep connections open or HTTP Pipelining afaict. One SSL handshake seems to
take around 700 ms currently, because there are two requests that create a 404
and take that long. I did the measuring using the tamper data plugin btw.
Regards
Till
3:57 p.m.
On Thu, 2009-04-23 at 15:48 -0500, Arthur Pemberton wrote:
It could also just be a rendering speed of the browser. Really. As I
said, a good thick client would solve most of the problems indicated
in this thread.
Well, b.r.c isn't particularly fast to respond even when you're
accessing it with python-bugzilla. Though I haven't compared it with
another bugzilla directly, yet.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:15 a.m.
On 2009-04-23, 20:48 GMT, Arthur Pemberton wrote:
It could also just be a rendering speed of the browser. Really.
As I said, a good thick client would solve most of the problems
indicated in this thread.
eclipse-mylyn in Rawhide seems to be almost useful ... except
I have created so many greasemonkey scripts to make my firefox
experience better, that eclipse now feels kind of bare.
Matej
5477
days inactive
5480
days old
44 comments
18 participants
participants (18)
-
Adam Williamson -
Arthur Pemberton -
Basil Mohamed Gohar -
Bill Crawford -
Christoph Höger -
Dennis Gilmore -
Emmanuel Seyman -
Kevin Kofler -
Manuel Wolfshant -
Matej Cepl -
Michael Cronenworth -
Mike McGrath -
Neal Gompa -
Rahul Sundaram -
Ray Van Dolson -
Till Maas -
Tom Lane -
Will Woods