I've been thinking about our GNOMEVER keywords, and trying to come up with a way to do it better And failing miserably :) hehe yeah it's not an easy problem But I've written a brainstorm and want to talk about it (note the implementation could be crap without the design... or vice versa) please look at http://www.gnome.org/~aes/bug_versions.html opening OK so It rather assumes that custom fields: * Do not cause spam OR can be mass changed without causing spam * Can be deleted/added without too much pain (1) depends on implementation, but presumably we can twiddle the database without too much pain. (2) we don't know about yeah Also (3) we can add custom fields to the new bugzilla and (4) this actually gives us advantages and (5) it doesn't have any disadvantages over keywords (those are assumptions) well if the UI is clean/easy, I think it's clear that (4) is a safe assumption (5)... only possible disadvantage I can think of is that it makes tracking old versions hard so, say Sun wants to maintain 2.0 for the next five years (which they do, though it's unclear if they care about things filed in b.g.o) this UI makes it real hard to keep a 'is present in 2.0' field around for 5 years (i.e., 10 versions) I don't know if we actually care about that case or not, but it's the only negative I can think of. Nobody is really keeping track of 2.0 properly in bugzilla anyway (3) of course is the hard part People close bugs when fixed on head hypothetically it would be nice to be able to do that, though. /very/ hypothetical, though. anyway, aside from (3) and that very, very hypothetical bit about (5), sounds great. What I'm really worried about is migration, whatever method we use yeah, but that's a problem for all of bugzilla as a whole yeah it really depends on the database layout of the custom fields I mean migration of old versions of bugs to new versions of bugs, aka GNOMEVER2.0->GNOMEVER2.2 The real problem is it needs manpower, possibly more than we've got, or wild guessing for mass changes ah yeah that's just going to be a manpower problem I wish I had more time to focus on that :/ fair enough Thursday is GNOMEVER2.0 day cool. clean, clean, clean. might want to start with the old TARGETs. I'm sure some of those have been fixed unawares, and if not, they need to get promoted and publicized. gulp. There's not too many of those Anyway How OK is it to _remove_ the GNOMEVER2.0 keyword from bugs? Considering what you said about sun Because I've been doing it for a while hrm I think it's OK they haven't asked/indicated anything otherwise if it starts irritating them, they'll say something and we'll work from there. :) OK The other versioning issue is for enhancements (and they really bit me earlier today) A GNOMEVER keyword, custom field, whatever gives _no_ extra information for enhancement requests None yeah Other than being a PITA to migrate every 6 months the 2.[stable+1] was sort of a hack to make sure it had /something/ but you're probably right it doesn't need anything. Just need to update scripts accordingly. Is it 2.16 we're heading towards? (bugzilla version) hypothetically that seems to be happening in fits and starts, though Since 2.16 has that nice query interface, then we can probably drop adding GNOMEVER to enhancements. Right now we probably need it since we can't set up 2 queries and OR them together To get "Bugs in current unstable", we'd need a query for bugs with GNOMEVER set OR set as enhancements Which we can't do right now