Bug 449401

Summary: RFE: add Testopia extension to Fedora bugzilla packages
Product: [Fedora] Fedora Reporter: Dave Malcolm <dmalcolm>
Component: bugzillaAssignee: John Berninger <john>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: bpeck, jlaska, jonstanley, poelstra
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-21 13:57:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to specfile, following approach (a): add testopia as a new subpackage
none
patch to specfile following approach (b): simply add testopia to main bugzilla package none

Description Dave Malcolm 2008-06-02 16:14:10 UTC
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 16:15:44 UTC
Created attachment 307383 [details]
patch to specfile, following approach (a): add testopia as a new subpackage

Comment 2 Dave Malcolm 2008-06-02 16:16:26 UTC
Created attachment 307384 [details]
patch to specfile following approach (b): simply add testopia to main bugzilla package

Comment 3 John Berninger 2008-06-02 18:39:16 UTC
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 18:55:58 UTC
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.

Thoughts?


Comment 5 John Berninger 2008-06-03 19:03:31 UTC
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 19:41:54 UTC
Thanks.  

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 19:47:32 UTC
Works for me.

Comment 8 Dave Malcolm 2008-06-04 19:11:47 UTC
Bug 450013 filed: "Review Request: testopia - bugzilla extended to add test case
management"; have CCed John Berninger.

Comment 9 Dave Malcolm 2008-08-21 13:57:22 UTC
Closing, see: https://bugzilla.redhat.com/show_bug.cgi?id=450013#c29