Bug 478886

Red Hat Bugzilla is now using version 3.4 of the Bugzilla codebase and
therefore this feature will need to be implemented against the new release.
Updating bug version to 3.2.

Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can.

Thanks
Bugzilla Development Team

As part of the recent Bugzilla 2.4 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time.

If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically.

Thanks, the Bugzilla team.

This issue remains viable and unfixed ... a typo in commend 4 perhaps -- 4.2

and needs a re-assign to the 4.2 level as the component

-- Russ herrold

This won't be happening. Core code contains Red Hat business rules, especially Bugzilla/Bug.pm. Red Hat provide upstream's Bugzilla code in our repos.

  -- simon

Another issue that needs to be addressed is the large number of places in the git repo where Red Hat-specific email addresses, groups, and variable names are used.  Some of these are actually obsolete (e.g. the crontab), but those that are still used should probably be config items rather than hard-coded values.

Easy way to vet commit logs:

$ git shortlog -e > git.log

Only 10K lines!

FYI I have worked with sourceware.org to get https://sourceware.org/gerrit/ set-up. It's hosted in our PHX2 DC.

Waiting on the blocking bug to move there.

Any progress on this? It'd be great to have this up on pagure.io or somewhere...

I know the sourceware gerrit was mentioned in comment #20, but that was before pagure.io existed.

(Also wow, this bug is over 10 years old now!)

There is currently no timeline for this happening. I am pursing several things to unblock it.

Hi, there are 3 items on the TODO list:

1: There are a few remaining internal items that need to be moved out of the BZ code base.

2: MPL 2.0 needs to be pasted to a lot of files. Bug 1819967.

3: RH specific README needs to be added.

#1 breaks the current deployment so will require some extra attention to make sure we can deploy hot-fixes if required.

#2 is a lot of changes, but nothing functional.

#3 is basically done.

I intend to merge these in the next release or three; the release that contains these changes will be what I make public.

I'll be dropping RHBZ as a single commit on top of the upstream 5.0 branch. It's not optimal, but as explained in the new README it is necessary given the history contents and the lack of resources available to address that.

I'm tossing up between hosting on pagure and github, leaning towards pagure ATM.

(In reply to Jeff Fearn 🐞 from comment #27)
> Hi, there are 3 items on the TODO list:
> 
> 1: There are a few remaining internal items that need to be moved out of the
> BZ code base.
> 
> 2: MPL 2.0 needs to be pasted to a lot of files. Bug 1819967.
> 
> 3: RH specific README needs to be added.
> 
> #1 breaks the current deployment so will require some extra attention to
> make sure we can deploy hot-fixes if required.
> 
> #2 is a lot of changes, but nothing functional.
> 
> #3 is basically done.
> 
> I intend to merge these in the next release or three; the release that
> contains these changes will be what I make public.
> 
> I'll be dropping RHBZ as a single commit on top of the upstream 5.0 branch.
> It's not optimal, but as explained in the new README it is necessary given
> the history contents and the lack of resources available to address that.
> 
> I'm tossing up between hosting on pagure and github, leaning towards pagure
> ATM.

This sounds great! I would personally prefer to have it hosted on pagure. And Stasiek (who I cc'd to this) would prefer that as well. This would make our lives considerably easier for what we're trying to do in openSUSE.

Created https://pagure.io/group/Red-Hat-Bugzilla where we will be adding our code when it's ready, and perhaps the bz-admin cli tool we use as well.

(In reply to Jeff Fearn 🐞 from comment #29)
> Created https://pagure.io/group/Red-Hat-Bugzilla where we will be adding our
> code when it's ready, and perhaps the bz-admin cli tool we use as well.

Do you have a timeline on when it will be ready? We'd like to start looking at a deployment for SUSE/openSUSE soon to replace our existing Bugzilla software...

(In reply to Neal Gompa from comment #30)
> (In reply to Jeff Fearn 🐞 from comment #29)
> > Created https://pagure.io/group/Red-Hat-Bugzilla where we will be adding our
> > code when it's ready, and perhaps the bz-admin cli tool we use as well.
> 
> Do you have a timeline on when it will be ready? We'd like to start looking
> at a deployment for SUSE/openSUSE soon to replace our existing Bugzilla
> software...

Hi, I don't have a time line. I have been prioritized to do some Ops work so it comes down to how much time I get to spend on the dev side.

This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.

The code is now available at https://pagure.io/Red-Hat-Bugzilla/rh-bugzilla

w00t!