Bug 449401 - RFE: add Testopia extension to Fedora bugzilla packages
RFE: add Testopia extension to Fedora bugzilla packages
Product: Fedora
Classification: Fedora
Component: bugzilla (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: John Berninger
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-06-02 12:14 EDT by Dave Malcolm
Modified: 2008-08-21 09:57 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-21 09:57:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to specfile, following approach (a): add testopia as a new subpackage (4.26 KB, patch)
2008-06-02 12:15 EDT, Dave Malcolm
no flags Details | Diff
patch to specfile following approach (b): simply add testopia to main bugzilla package (2.61 KB, patch)
2008-06-02 12:16 EDT, Dave Malcolm
no flags Details | Diff

  None (edit)
Description Dave Malcolm 2008-06-02 12:14:10 EDT
Testopia (http://www.mozilla.org/projects/testopia/) is an extension of Bugzilla
that adds test-case management, allowing test plans and result reporting to be
integrated into the Bugzilla web UI.

It patches the core of Bugzilla, and hence has to be built as part of the core
package, rather than a separate srpm.

I'm about to attach two different patches to the Fedora bugzilla.spec file, for
two approaches I've tried to adding this.

Both patches add a %{with_testopia} boolean to the specfile.

The first approach I tried: 
(a) add-testopia-as-subpackage.patch is an attempt to isolate the code in an
optional subpackage.  This doesn't actually work, but I'm attaching it for
reference.  The problems with this approach are
  (i) that I want the testopia subpackage to own a few isolated extension files
in the payload, but the main bugzilla subpackage ends up owning them as well,
and to fix this would be a much more invasive patch to the %files section of the
specfile (is there an specfile syntax I've missed here?)
  (ii) I suspect that the resulting bugzilla package wouldn't work properly
without having the bugzilla-testopia package also installed, but have been
unable to test due to (i)

The second approach I tried is:
(b) add-testopia-as-buildtime-option.patch
This merely adds testopia to the build, merging it into the main bugzilla
package.  In the patch I've enabled it by default.

A third approach might be (c): as (b), but disabling it by default.  This would
keep the package unchanged for current users, but enable people to obtain
testopia features with a one-line change to the specfile and a rebuild.

How do these sound?

(Background: some people (CCed) have expressed an interest in deploying an
instance of testopia for helping with Fedora installation testing, storing stuff
in a db, rather than in wiki pages; hence we'd want some easy way of managing
the deployment via RPM)
Comment 1 Dave Malcolm 2008-06-02 12:15:44 EDT
Created attachment 307383 [details]
patch to specfile, following approach (a): add testopia as a new subpackage
Comment 2 Dave Malcolm 2008-06-02 12:16:26 EDT
Created attachment 307384 [details]
patch to specfile following approach (b): simply add testopia to main bugzilla package
Comment 3 John Berninger 2008-06-02 14:39:16 EDT
I'm not too sure I'm comfortable with this - if it could be added as a
completely independent subpackage I wouldn't have an issue, but the way it
patches the core disturbs me.  I don't want to ever get to a situation where a
bugzilla user is forced to have testopia but doesn't want it, which it sounds
like would be the case here.  I'll look at the patches and see if I can come up
with something I'm comfortable with - will let you know.

Comment 4 Dave Malcolm 2008-06-03 14:55:58 EDT
Another approach could be to treat testopia as an entirely separate package,
albeit with a very similar specfile.

Would it be OK to use the bugzilla.spec (and patches) as a base, and create a
new testopia fedora package, with a testopia.spec that's essentially identical
to your bugzilla.spec? (and the patches etc).

I think there are two ways to go about this: to attempt for parallel-installable
packages, using different paths, or the simpler approach of simply having
testopia use the same paths and have a Conflicts with bugzilla, so that the
specfiles can stay as close as possible.  This latter approach is more appealing
to me if I'm going to own this package, ideally I can just piggyback off of the
work you've already done to package bz; I'd need to watch your package CVS
somehow to keep things in sync (which could get ugly in itself).

Do either of these approaches sound more appealing?  If so I can take a testopia
spec/srpm through the package review system.

Comment 5 John Berninger 2008-06-03 15:03:31 EDT
I was considering something similar - from F10 onwards, move bugzilla to a
different directory and use the alternatives system to switch between generic
bugzilla and testopia-enabled bugzilla.  If you'd like to generate a review
request and add me as a CC: then make that depend on a new bug to move
/usr/share/bugzilla to (e.g.) /usr/share/bugzilla-generic and integrate with
alternatives, that would make my life a bit easier.  If the simple conflicts
would be easier, I'm good with that, too - feel free to grab the existing
specfile and tweak it to your heart's content.
Comment 6 Dave Malcolm 2008-06-03 15:41:54 EDT

I don't think using "alternatives" buys us anything; even if we went down the
parallel-installable route, then you'd use https://localhost/bugzilla for one
and https://localhost/testopia for the other; /usr/share/bugzilla vs
/usr/share/testopia etc, and alternatives wouldn't be needed.  But any approach
like this adds complexity.  (or have I missed something?)

So I think separate, conflicting bugzilla vs testopia packages that own the same
paths in the filesystem is the best approach:
- simplicity, sysadmin chooses "regular bugzilla" or "bugzilla+testopia" by
picking one of the two
- avoids having to touch your packages and thus introducing any risks to your users
- keep the testopia.spec file as close as possible to the bugzilla.spec file

(Hopefully the size of the testopia patch against core bugzilla will eventually
shrink down to zero over time and we'll be able to reassess this)

So I'll work on a package review request for testopia, based on the bugzilla
specfile; will CC you and link to it in a comment in this bug
Comment 7 John Berninger 2008-06-03 15:47:32 EDT
Works for me.
Comment 8 Dave Malcolm 2008-06-04 15:11:47 EDT
Bug 450013 filed: "Review Request: testopia - bugzilla extended to add test case
management"; have CCed John Berninger.
Comment 9 Dave Malcolm 2008-08-21 09:57:22 EDT
Closing, see: https://bugzilla.redhat.com/show_bug.cgi?id=450013#c29

Note You need to log in before you can comment on or make changes to this bug.