Community
Participate
Working Groups
Since 4.0 has been added to the Version field, we get a lot of new bugs with that version, although there's no official E4 build yet. Would it be possible to make 3.5 the default version when people file a bug and their browser does not have the corresponding VERSION-<Product> cookie?
+1 (though having 3.4 as default might even be closer to the real world). If we can't agree on the default then I'd prefer to have no default at all rather than 4.0.
Bugzilla doesn't have a notion of a settable default version. It defaults to the latest of a product, or the value in the users' cookie if it is present. I did find this request over at Mozilla, however. There doesn't seem to be much interest in implementing it, though. https://bugzilla.mozilla.org/show_bug.cgi?id=45043 Perhaps 4.0 should be removed from the list?
>Perhaps 4.0 should be removed from the list? Peaople should probably log the bug against 3.x and set the target to 4.0. Adding PMC lead to decide.
*** Bug 244651 has been marked as a duplicate of this bug. ***
Philippe, this is awaiting your approval.
I am reluctant to remove the version 4.0; some may grab early versions of e4 work and want to enter bugs against it, even if there is no official build yet. At some point, we will be both working on 3.x and 4.0 for real. The default is likely going to need to be 3.x still, but there will be some real 4.0 builds in parallel. I think I'd rather have no default version set then (rather than the wrong one). Actually, what do you think Mike as e4 lead.
I'm obviously biased because of e4, but it seems to me that, if the tool we use (i.e. bugzilla) has limitations that are impacting us, then we should be working with that community to get them resolved. Until then, I'd be happiest if we lived with the extra effort of fixing the incorrectly entered bugs, since we are actually using the 4.0 version tag already. To be clear though, I do recognize that there is a problem here; querying for bugs against 4.0 returned a list of about 100 bugs this morning, very few of which are actual 4.0 bugs.
We now have over 500 bugs reported against 4.0 most of which are against 3.x and not mentioning those bugs that were manually corrected by committers.
What is the difference between 4.0 and e4?
> What is the difference between 4.0 and e4? Good point. E4 bugs should go to the E4 product for now, so we should just remove version 4.0 from JDT, PDE, and Platform products. Existing bugs with version 4.0 should get version 3.5.
If the project leads agree with that, I will get it done right away.
+1 for JDT
Removing 4.0 will just have the attribute of causing people to mistakenly leave it set to 3.6, which also exists. Since *both* 3.6 and 4.0 will be required next release, I'd just leave them.
Do we (or will wee soon) have 4.0 version in Platform or JDT? Won't those bugs go against e4?
> Removing 4.0 will just have the attribute of causing people to mistakenly leave > it set to 3.6, which also exists. 3.6 is definitely wrong and should be removed as well. It should only be added after 3.5 has shipped and 3.6 I-builds have started. > Since *both* 3.6 and 4.0 will be required next release, I'd just leave them. That's easy to say for you, but doesn't solve the problem for those of us who actually do the bug triage. The wrong versions make us slow and corrupt our bugzilla data integrity without any advantage. In the long term, could the foundation please look into fixing this issue in Bugzilla?
(In reply to comment #14) > Do we (or will wee soon) have 4.0 version in Platform or JDT? Won't those bugs > go against e4? > "Eclipse SDK 4.0" will ship in July 2010 (1 month after 3.6 ships). Bugs in JDT, that are seen only when testing on pre-release drops of Eclipse SDK 4.0, should be marked Version 4.0 in JDT, not e4. (At least until you prove that it's some other project's fault, in which case you would move it to version 4.0 of that project.) (In reply to comment #15) > That's easy to say for you, ... > Hey! I just went and manually fixed all 165 open bugs that were marked Version 4.0 to have a better value, so I wouldn't say it was *easy* for me. >but doesn't solve the problem for those of us who > actually do the bug triage. The wrong versions make us slow and corrupt our > bugzilla data integrity without any advantage. > I'm actually still not convinced this is a big a deal as you are making it. People *always* get the version wrong. For example, most of the bugs that come in from our product teams that are building on top of Eclipse are actually against *3.4*. If we fix it so that 3.5 is last, they'll still be wrong. To me, making sure the version is correct is just part of triaging. Having "3.5" as the last entry means that you will spend less time changing the Version field -- I get that -- but you still have to verify that it's correct. In any case, for the particular case you are interested in (i.e. having the last number in the list match the release that is currently being worked on), if it just says "3.5" it doesn't actually help you anyway. You really need to know which *build* is being used, to do something useful with the bug. Heck, it isn't even *correct* to say the bug occurs in 3.5, unless you don't intend to fix it before we ship. > In the long term, could the foundation please look into fixing this issue in > Bugzilla? > Again, as described above, all the foundation can do is help us with the number of clicks we have to make in the combo box, *not* the need to validate the field, if you want to avoid corrupting bugzilla. I believe we've wasted enough time on this. If you want the items removed for JDT, Dani as project co-lead has the ability to request it. The same goes for the other project leads. I intend to leave Platform alone, at least until convinced otherwise by the Platform developers.
> Hey! I just went and manually fixed all 165 open bugs that were marked Version > 4.0 to have a better value, so I wouldn't say it was *easy* for me. That's exactly the kind of time-consuming manual work I tried and I'm still trying to prevent. Before the 4.0 version, we usually just left the Version field alone, since it was mostly correct and couldn't err towards the future. We only did manual corrections where we felt it to be important. Now, we have many bugs with an obviously wrong version, so the field lost its value. This will become even worse when the first *real* 4.0 bugs come to life. > Again, as described above, all the foundation can do is help us with the number > of clicks we have to make in the combo box, *not* the need to validate the > field, if you want to avoid corrupting bugzilla. This is an issue we have with infrastructure provided by the foundation, and AFAIK, it's one of jobs of the foundation to provide good infrastructure for developers. Of course, the right open source approach is to fix it in Bugzilla and then submit a patch so that this gets fixed in the next version. And I didn't say this has to be done today.
>I believe we've wasted enough time on this. Agree. Let's move on and thanks for fixing the wrong version in the bugs.
I am seeing the same problem in the Platform/UI: most new bugs are reported with version "4.0". It is OK for now as we can just change it to 3.6 without giving it much thought. However, when 4.0 is released it will become a real issue. From the Bugzilla side, if we add "unspecified" as the version field, would that be picked up as the default?
As I said before, we are responsible for verifying that every bug is actually against the indicated version. This is true regardless of what value is in the field. We see that the signal-to-noise on the field is impacted because it defaults to a particular value. We could reduce the noise by setting it to a known-to-not-match-any-version value, at the cost of forcing more pings from whoever is doing triage ("Please set the version field to the version you found this in"). Of course, this penalizes everyone who *is* reporting a bug against whatever version shows up by default (who did check that it matched what they wanted to report). Given that we can't simply assume the value is correct even if we do force the user to set it, I really don't see much benefit here. In any case, this bug is closed. Let's not re-open it.
