87411 - (bz-globals) move global Bugzilla subroutines into modules (remove CGI.pl and globals.pl)

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P2)

Description

[Andreas Franke (gone)]

Richard Walters wrote 
(in news://news.mozilla.org:119/uhexcrkll.fsf%40qualcomm.com ):

For one thing, I put all the scripts into a "Bugzilla namespace", by doing a
"package Bugzilla".  I stripped out all the subroutines from "CGI.pl" and
"globals.pl", putting them into a new file called "Bugzilla.pm" which I put in
/etc/httpd/lib/perl/Bugzilla.pm, and load when the web server starts, by
having "PerlRequire Bugzilla.pm" in my /etc/httpd/conf/httpd.conf file.  That
way they need only be compiled once when the server first starts.

The good news of putting Bugzilla into its own namespace:  It does not pollute
the global namespace.  The bad news:  I had to do global search-replaces for
all instances of "$::", replacing with "$Bugzilla::".  Same with arrays and
hashes.

Comment 1

[Matthew Tuck [:CodeMachine]]

Can we get a patch for this?

Comment 2

[Richard Walters]

Have you seen the patch I made available through the URL in bug 87406?  It is
slightly old and has a lot of other stuff in it, but it might be useful to you.

I was still planning to help out and do what Andreas mentioned in bug 87406,
which is to introduce a series of patches, the first being the introduction of
the namespace.  I don't have a lot of free time to work on it though, so I'm
sorry if it takes a while.  If you need a patch by a certain date, let me know,
and I'll try to get it done by then as best I can.

Comment 3

[Richard Walters]

Hmm.. the target milestone for this bug is Bugzilla 2.18, but the target
milestone for bug 87406, which this blocks, is Bugzilla 2.16.  That seems
backwards to me - shouldn't this one get done sooner (it is actually a smaller
amount of work, a subset of bug 87406 anyway)?

Comment 4

[Andreas Franke (gone)]

-> Bugzilla product, General component, reassigning.

Comment 5

[Florian Kolbe]

Again, this bug is targeted towards 2.18, but blocks #87406, which is
targeted 2.16.
Can we target this bug for 2.16 please? What can I do to help?

Does voting for this bug help to adjust the 'priority'? Is the 'bug ranking'
by votes used at all? If yes, please vote for this bug (and/or tell me how I
can help fix it).

Thanks

Comment 6

[Andreas Franke (gone)]

It's not so much voting that helps, it's submitting patches that determines the
target milestone. In this case, bitrot may be the biggest problem.

I think, you can do the following things to help:
1. Get the bugzilla maintainers (see http://www.mozilla.org/projects/bugzilla )
   to confirm that 
   a) this is a good thing to do AND
   b) that this should be done asap
2. Propose a namespace (I think "Bugzilla::" has already been proposed ), and 	
   get consensus on it (or one of the alternatives).
3. Attach a patch. The simplest way to create such a patch is to check out a 
   fresh, clean CVS tree, and perform a couple of global substitutions in all
   perl files:
	$:: --> $Prefix::
	@:: --> @Prefix::
	%:: --> %Prefix::
  Then make sure everything still works; in case it doesn't some of these
  substitutions may need to be undone or otherwise specialcased manually.

Once the patch is there, make as much noise as you can, mail all maintainers at
least once a day until someone checks it in. :-)

The critical thing with this that it will bitrot very quickly, or if it's
checked in now it will bitrot a lot of existing patches. (And in any case it
will break some patched existing installations! But they should be easy to
detect and to fix.) Nevertheless I think this should to be done soon, and it
should be possible to add some automated tests to prevent future checkins with
variables in the global namespace.

I guess however that the biggest problem will be step 1.

Comment 7

[Dave Miller [:justdave]]

milestone is out of sequence with dependencies...  fixing

Comment 8

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 9

[Bradley Baetz (:bbaetz)]

I'm going to morph this slightly. As you've noticed, just moving the stuff by
itsself doesn't actually work, mainly because we need to have the code running
in every request.

The fix here is to eventually remove CGI.pl and globals.pl, but at the minimum
we have to:

- move all the 'real' code out
- not use (or reset) all the global variables we have

For mod_perl, I think we can get away with:

- CGI.pm stuff - avoids global code/vars/etc, and also ensapsulates the mod_perl
stuff for us
- template cleanup - global $vars sucks, because we'd have to reset it on every
go arround
- DBI cleanup - We need to be able to reuse global connection objects, and the
current ownership module sucks

The DBI stuff may not be neceesary, but since the code is basically written
already, its probably a lot easier to use it than work arround this.

Comment 10

[Dave Miller [:justdave]]

Reassigning to the person that's actually been working on this.

Brad: what's the status on this?  All of the dependencies have been resolved. 
Is there any more to be done here or can we go ahead and resolve this as well?

I notice prior comments suggest eliminating CGI.pl and globals.pl, but we still
have both....

Comment 11

[Bradley Baetz (:bbaetz)]

Thats because not all of the bugs have been filed, and not all the ones which 
have been got listed as dependancies.

This bug can be closed when globals.pl and CGI.pl go away. Some mod_perl can 
happen before that, though. I think that the current list of dependancies are 
all which need to move for show_bug to work under mp, but there may be others 
which come up.

Comment 12

[Dave Miller [:justdave]]

*** Bug 98451 has been marked as a duplicate of this bug. ***

Comment 13

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 14

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 15

[Dave Miller [:justdave]]

*** Bug 276033 has been marked as a duplicate of this bug. ***

Comment 16

[Max Kanat-Alexander]

The target milestone on this is actual. By Bugzilla 2.22, I want globals.pl to
be gone entirely.

Comment 17

[Frédéric Buclin]

Updating the summary to catch this bug in queries including globals.pl and CGI.pl.

Comment 18

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 19

[Frédéric Buclin]

globals.pl is dead! :)

Comment 20

[Max Kanat-Alexander]

Added to the release notes as part of bug 349423.