Community
Participate
Working Groups
I20080305-1100 Sorry, I don't have steps, but my workspace got into a state where a project showed a build path problem. Somehow, one of the projects (org.mozilla.javascript, version 1.6.6 from Orbit) ended up with a dependency on another project (com.steadystate.cssparser) even though that dependency was not declared anywhere. I previously had another project with a dependency on com.steadystate.css and somehow, that dependency seemed to leak into the build path for org.mozilla.javascript. Again, sorry for this confusing bug report, but I was offline at the time and needed a working workspace again. I think I closed and reopened projects, followed by a full build, to get rid of the problem. Kevin ran into this as well, maybe he can explain it better?
Sorry, but there nothing we can do with this little information. Please reopen if you have more information.
Verified for 3.4M6
Yes, I got exactly the same error. I understand you can't proceed without a reproducable case, but why 1) was this bug marked as invalid? 2) in comment #2 said to be verified? (as what fixed? non existant?)
(In reply to comment #3) > Yes, I got exactly the same error. > I understand you can't proceed without a reproducable case, but why > 1) was this bug marked as invalid? > As Jerome said, the bug description wasn't clear enough to start any investigation (even the reporter had the same feeling). As you were asked to explain it better but didn't add comment after two weeks, we considered that this bug might be closed. > 2) in comment #2 said to be verified? (as what fixed? non existant?) > The INVALID bugs verification is done on the bug itself, not on code change as none was done. The verifier reads the bug history and must agree on the final explanation of the JDT/Core committer while setting it as INVALID... BTW, if you now have a reproducible test case or more information to help us to understand what could be the problem, feel free to reopen the bug...
>>As you were asked to >>explain it better but didn't add comment after two weeks, we considered that >>this bug might be closed. We were at EclipseCon! OK whatever.
Kevin, there is nothing personal in closing a bug as invalid. If you have more information that can help us, please do not hesitate to reopen.
I personally disagree that INVALID is the right resolution in this case. There is clearly something wrong even if there are no steps to reproduce. From my point of view, the right resolution should be WORKSFORME as long as there is no further information provided to reproduce this issue.
I didn't take it personally :) however: 1) Two weeks isn't much time to expect feedback. Case in point we were busy getting ready for, then at EclipseCon. Or I could've been on vacation. If that's the team's policy then ok (hence the "whatever") but its an unrealistic expectation of the community. 2) I agree "invalid" is the wrong resolution. There's definitely a bug there. Invalid says that the report was wrong. I understand the need to keep inboxes clean but its also a mistake to eagerly discard reports that do point to real bugs. When a report is closed we discourage any further effort on the part of the reporter. This is just a failure in our ability in bugzilla to distinguish active vs. inactive. Anyway I don't mean to hijack this bug for a discussion on bug triaging pros and cons. If we see this case again we'll provide more data and reopen.
I re-read Bugzilla's definition of INVALID, and I agree that it was not the most appropriate resolution. It should have been WORKSFORME. Sorry about that.
I think I would keep the bug open until end of M7 to give a chance to hear back. We were all in a rush near M6, between EclipseCon and issues in integration. The symptoms are quite interesting, and I would like to see this investigated a bit more.
Reopening.
Clearing target milestone.
ping
We should probably close this. The problem case we hit was setting up for the EclipseCon demo and I don't know if we could reproduce it.
Thanks Kevin. Closing then.
Verified for 3.5M2 using I20080914-2000.
