On Thu, Mar 5, 2009 at 1:36 AM, Danek Duvall <danek.duv...@sun.com> wrote: >> Nice to have > > - A scalability issue -- we have a version for each build. For now, > that's fine, but if this continues for one release after another, the > scroll box is going to get unwieldy. In bugster, we've got essentially > two levels -- release and build.
Edit milestone... Sortkey Active Searchable Action mozilla1.8final 1270 0 1 Delete Milestones and Versions are different, so for Gecko we have many more TMs than versions. w/ TMs, as you can see above Bugzilla won't show "mozilla1.8final" in the target milestone drop down list for bugs in Core (unless of course the bug currently has that as its tm....) For Gecko, I've basically turned off everything older than 1.9. OTOH, we have <10 versions for Core. My employer's Bugzilla is an example of what not to do (they don't ask me for suggestions), and so we have ~1500 versions, we're growing at least 2 versions a week (per product, and versions in some cases don't seem to be compatible across products, even though bugs often need to be redirected to a related product). We used to grow more, so I think they've learned that having too many versions hurts usability (there are probably 10 builds a week, at most one is official, and at one point they basically made each build available as a version, now I suspect they're merely distinguishing between the official release and 'everything else'). However, the perf of even these 1500 versions isn't so bad on the search page (thankfully the active products seem to have <100 versions). -- If you truly want to hurt performance you would turn on the showmenuforusers feature (please don't. please please please please please don't), which my employer's Bugzilla does (this means each bug has three listboxes each of which have >1000 items [email address+email address+realname = very expensive markup]). One note about scrollboxes. Eventually browsers will improve, the s60 browser has few good features, the only one that comes to mind is the ability to filter a listbox. I'm working on trying to implement that for Gecko, and I expect other vendors will add this eventually. Being able to turn off versions as you can milestones would probably make sense for your Bugzilla and for my employer's, however the current UI for turning off anything is tedious (as you have to edit each item individually), so if you or someone else want to contribute the ability to turn off versions as you can milestones, please work on a way to do it from the list instead of the single editor. http://defect.opensolaris.org/bz/editversions.cgi?product=pkg http://defect.opensolaris.org/bz/editmilestones.cgi?product=pkg http://defect.opensolaris.org/bz/editversions.cgi?action=edit&product=pkg&version=unspecified http://defect.opensolaris.org/bz/editversions.cgi?action=edit&product=pkg&milestone=in-preview I think using versions for each distinct build of a package might be the wrong approach (I'm certainly not a fan of my employer's implementation). You should use them to collect a set of bugs, if you find that most versions collect ZERO or ONE bug(s) then your buckets are probably too small (IMO). Imagine someone using the search and selecting a product, 20 version buckets and no other search restrictions, and finding *nothing*, one could say "great, 20 versions, no bugs", but if it really means "20 minor commits yielded versions for which nothing was reported or nothing was tested", you've merely complicated the search interface. I think the current approach used by the OpenSolaris Bugzilla (1 version per snv/in release) seems fine and should scale well enough. If two years from now you want to collapse all bugs from this year into a single version bucket, you could create such a bucket and mass change them (there would be some mail, but hopefully people will configure their mail prefs to exclude resolved [*] bugs or changes without comments [*]). * obviously it'd be good for two year old bugs to be fixed ;-) -- sadly while you can ignore UNCONFIRMED bugs in bugzilla today, you can't actually ignore RESOLVED/VERIFIED/CLOSED bugs (this is a bug, which will either be fixed specifically or by changing the mail prefs) * mass changes shouldn't have a comment, otherwise people can't choose to ignore them http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ----- Note that mozilla.org's approach to versioning should be workable as an alternative to the current OpenSolaris deployment, for mozilla.org, we ask people to paste in their version as part of comment 0 (description) and leave the version mostly for long lived branches (Solaris 8, Solaris 9, Solaris 10, Nevada, Indiana, Nexenta, ...). The tools I've used from Indiana include their version information in text output, which I then have to manually search for in the version field, whereas I can today merely paste it into comment 0 and someone can easily search for the version in comment 0 as the version is formatted in an easy to parse manner. [Again, in future browsers, being able to search a <select> will happen.] These are just food for thought. And yes, I'm aware you aren't a fan of free text fields... _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
