Open Bug 61992 Opened 24 years ago Updated 10 years ago

Reducing duplicate typing in versions

Categories

(Bugzilla :: Administration, task, P3)

Tracking

()

People

(Reporter: hansoneric, Unassigned)

References

Details

Each product has a version, at my company some products use the same versions as other products, when this happens, alot of typing goes on. I was wondering if it would be possible to have an option on the "Edit Version" screen to have a pull down box with the words next to it "Use versions from: --- ", normally the pull down box would be blank or null, but it would contain a list of other products. Then when you hit the button next to it, you would get a seperate table with the heading "Versions from Applications" (for example if you were using applications version numbers also). Then at the bottom of the table would be a button that would let you stop using applications versions. The pull down list would be always present so you could include versions from multiple components. I figured this would just be stored in a list somewhere and Bugzilla would pull the "versions" field from any components stored in the list. An array with a default value of null or something.
*** This bug has been marked as a duplicate of 69262 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reopening bug since this seems to be fundamentally different problem, or at least approach to the problem. I think all products should have thier own set of milestones/versions. However, it would be nice to be able to "include" or "link" other product's m/v into another. For example I have a product "Can Opener". In bugzilla there are two products "Can Opener Hardware" and "Can Opener Software". The will share major target milestons (1.0, 2.0, 3.0, etc). However Software may have individual sub milestones (.9, 1.3, etc) but still wants the Hardware milestones. So I imagine in Software's list of m/v, there would be a "link" entry telling bugzilla to include the versions from the Product "Can Opener Hardware". I began implementing this but slowed down when all I could think of was a special string that would show Bugzilla that it wasn't a real version, but a link version (e.g. "::link::Can Opener Hardware::" in the version field of Can Opener Software.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
That's exactly what bug 69262 is about. Don't forget that in Bugzilla 3's design, there are no special fields -- 'version', 'milestone' and 'product' are merely user-defined fields that happen to have those names.
I was hoping this would be implemented (or bug 69262) before 2004 (estimated time for bugzilla 3 by a posting to the bugzilla newgroup). I have been posting to bug 69262 and it sounds different. I think my idea is easier to implement, while bug 69262 would probably be best left as a design idea for B3.
Please elaborate in your own words what the difference between these two bugs is ... I don't see any. We're targetting simultaneously released products for 3.X because that's where it seemed it will most likely be fixed. Judging by the way development has progressed since then we're not afraid of continuing schema changes on the 2.X line, so maybe it will get done. It would certainly be nice but I'm trying to balance it with lots of other things that would also be nice before then. Generally enhancement request targetting is only my personal opinion on the state of things, as most enhancements aren't "required". And if they aren't I don't have too much influence in making people do stuff by a specific time, and in the majority of cases I wouldn't want to try and make them not to do it before then. Maybe this will get done by then ... the team changes their mind about things as members change their mind or more people get involved. And anyone can contribute the code to do this.
Target Milestone: --- → Future
Mathew, please take a closer look. I believe there are good explanations on both bugs. Here is a summary though: I believe bug 69262 is a structural way in which we treat how fields (version or milestones) relate to each. The bug seems to be about the structure of bugzilla. My bug is a superficial working fix. I want to be able to include Milestones or Versions across Products, but also have each Product have its own "private" set. Therefore you could have a master set of Milestones that are shared by all Products (I.e. Product A shares Product B's Milestones, and only Product B needs to be updated). But Products would each have thier own Milestones, maybe minimilestones, I don't know. The point being I think I, or someone else, could implement this functionality before bugzilla 3. Bug 69262 seems specifically targeted toward Bugzilla 3.
-> Bugzilla product
Assignee: tara → justdave
Status: REOPENED → NEW
Component: Bugzilla → Administration
OS: Linux → All
Product: Webtools → Bugzilla
Hardware: PC → All
Version: other → unspecified
Reassigning all of my "future" targetted bugs to indicate that I'm not presently working on them, and someone else could feel free to work on them. (sorry for the spam if you got this twice, it didn't take right the first time)
Assignee: justdave → nobody
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---
Assignee: nobody → administration
See Also: → 69262
I think this bug is unlikely to be implemented, because bug 69262, which allows Products to share Version or Milestone sets, will provide the right function for most users. Allowing them also to have their own private additional options would complicate things quite a bit, I'd imagine. (What happens if the shared set acquires a milestone which is already in one of the independent sets?) Gerv
You need to log in before you can comment on or make changes to this bug.