removed self from cclist. Not sure why I was there...

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Can you give more details ?

where are the frontpage.cgi file ?

The cgi script of the Bugzilla we are using uses it.

https://bugzilla.redhat.com/frontpage.cgi

I think it used to be distributed as part of the Bugzilla package. It is obviously available to the Redhat Bugzilla site.

The Red Hat Bugzilla needs to commit this to the upstream bugzilla people.
Assigning to them.

This is a cgi that is only in use by Red Hat's Bugzilla at this time and is not part of the upstream bugzilla code base.

Sad. Very useful.

I would think that since the community is contributing to Fedora and RedHat that RedHat might consider contributing this to the community.

(In reply to comment #7)
> Sad. Very useful.
> 

Thanks

> I would think that since the community is contributing to Fedora and RedHat
> that RedHat might consider contributing this to the community.  

As for replacing the Fedora maintained Bugzilla package with the same rpms that Red Hat creates for it's production Bugzilla servers that is unlikely to happen. This is because there is quite a bit of changes needed specifically for our own
business practices. Also I do not have resources for maintaining the bugzilla package in Fedora and we push new versions of our code weekly. 

As for the front page view, I am more than happy to create a patch to submit upstream that adds that functionality specifically. It is of course up to the upstream whether they want to include it in an official release which will eventually make it into a Fedora maintained Bugzilla package.

Otherwise one of the things I have had on my todo list for a while is to at least put out srpms of our Bugzilla on a public download site so that at least others 
can pull out pieces that they want. I first need to sanitize it enough to release.

Dave

(In reply to comment #8)
>
> As for replacing the Fedora maintained Bugzilla package with the same rpms that
> Red Hat creates for it's production Bugzilla servers that is unlikely to
> happen. This is because there is quite a bit of changes needed specifically for
> our own
> business practices. Also I do not have resources for maintaining the bugzilla
> package in Fedora and we push new versions of our code weekly.

I really don't think this is an option.
I'm convinced the vast majority of the people who install Fedora's bugzilla package expect bugzilla as shipped by the bugzilla devs, not the code that is hosted on bugzilla.redhat.com .

> Otherwise one of the things I have had on my todo list for a while is to at
> least put out srpms of our Bugzilla on a public download site so that at least
> others 
> can pull out pieces that they want. I first need to sanitize it enough to
> release.

Would the contents be the upstream tarball + patches? That would really be useful.

(In reply to comment #9)
> I really don't think this is an option.
> I'm convinced the vast majority of the people who install Fedora's bugzilla
> package expect bugzilla as shipped by the bugzilla devs, not the code that is
> hosted on bugzilla.redhat.com .

Yeah I was unclear. I didn't really mean shipping Red hat's Bugzilla code as is in Fedora but I meant taking some of our specific feature patches and adding them to the upstream code and then making the Fedora package. We would still need to maintain our patches with every upstream release.

> > Otherwise one of the things I have had on my todo list for a while is to at
> > least put out srpms of our Bugzilla on a public download site so that at least
> > others 
> > can pull out pieces that they want. I first need to sanitize it enough to
> > release.
> 
> Would the contents be the upstream tarball + patches? That would really be
> useful.  

Same as above. It would that way if we decided to take on maintenance of the Fedora Bugzilla package. But I would much prefer for our patches to be submitted upstream, accepted, and then committed to the upstream code base. Then we are no longer obligated to maintain the customized Bugzilla package for Fedora. The Fedora person can just pull down the upstream code whenever a new release comes out.

Dave

Back when this bug was first submitted, frontpage.cgi gave you a list of bugs and 
I couldn't see any real advantage of this page vs a list of saved searchs.

I came back to that page recently and noticed that the lists had been replaced by a series of YUI datatables, making the page much easier to read and thus to use.
Congratulations to whomever did the change.

(In reply to comment #11)
> Back when this bug was first submitted, frontpage.cgi gave you a list of bugs
> and 
> I couldn't see any real advantage of this page vs a list of saved searchs.
> 
> I came back to that page recently and noticed that the lists had been replaced
> by a series of YUI datatables, making the page much easier to read and thus to
> use.
> Congratulations to whomever did the change.  

Thank you for the kind comments as I was the one who did that. 

Upstream Bugzilla (and RH Bugzilla team as well) have standardized on the YUI toolkit and DataTable seemed like a good fit. I am working on using it as well for the standard buglist.cgi bug list screen as well. Also using DataTable for buglist.cgi will automatically give us configurable pagination as well without reloading the page for each subset of results.

Do you feel having pagination would be useful for the frontpage.cgi as well? This would make the page shorter for one since the each table could be shortened to 25 rows or so. Or would it make the page more confusing?

Dave

(In reply to comment #12)
>
> Do you feel having pagination would be useful for the frontpage.cgi as well?

I'm the wrong person to ask that question. As of now, my front page contains
3 non-empty datatables :

* Open Issues: Assigned to You (1 bug)
* Open Issues: New Reported by You (1 bug)
* Open Issues: You Are CC'd On (3 bugs)

Needless to say, I don't really need pagination.