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)
Created attachment 307383 [details] patch to specfile, following approach (a): add testopia as a new subpackage
Created attachment 307384 [details] patch to specfile following approach (b): simply add testopia to main bugzilla package
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.
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?
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.
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
Works for me.
Bug 450013 filed: "Review Request: testopia - bugzilla extended to add test case management"; have CCed John Berninger.
Closing, see: https://bugzilla.redhat.com/show_bug.cgi?id=450013#c29