Bug 449401
Summary: | RFE: add Testopia extension to Fedora bugzilla packages | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dave Malcolm <dmalcolm> | ||||||
Component: | bugzilla | Assignee: | John Berninger <john> | ||||||
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | rawhide | CC: | 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
Dave Malcolm
2008-06-02 16:14:10 UTC
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 |