Quality Portal report: quality central does not work
Quality Portal report: quality central does not work
It is kind of funny and tragic at same time.
https://quality.embarcadero.com/browse/RSP-9702
It is kind of funny and tragic at same time.
https://quality.embarcadero.com/browse/RSP-9702
I guess it is the authentication issue.
ReplyDeleteNice. Not the way I usually think of minimizing defects.
ReplyDeleteQC web client works as usual, but Windows client has been broken for weeks now. Which would not be so tragic if new QP would contain all open issues and if people would not have problems logging into new QP too.
ReplyDeleteThe new QP will probably also be too slow if there is a lot of traffic. IMO the same with the new community site.
ReplyDeleteDalija Prasnikar The windows client does not work because the login takes so long and it times out. I told Marco Cantù about that issue and he passed that along to whoever is responsible.
ReplyDeleteThe non-web QC clients are all moot anyway: they pass your plain text EDN username and password over http (not https).
ReplyDeleteToo bad the new system hides all issues behind credentials so that Google cannot index them.
Wish they did, but two wrongs don't make a right.
Jeroen Wiert Pluimers I thought that web QC client sends your data over plain http
ReplyDeleteJeroen Wiert Pluimers I had to use Google for searching through QC only because QC is a mess.
ReplyDeleteJIRA is much better in finding issues you are interested in, at least that is my experience. Though QP still needs fine tuning with basic grouping and labeling of reported issues.
Dalija Prasnikar even for JIRA, Google usually finds better results.
ReplyDeleteI find it a really bad direction that Embarcadero is following by closing QP for anonymous read access. Whereas virtually all companies are opening up, Embarcadero does the reverse.
They trolled too much in the newsgroups... I guess.
ReplyDeleteWe know about the QC login issue, and I know a person has been working on it. The issue with some of the old systems, is they are a bit orphaned, and when something crashes after years, things take time to be understood.
ReplyDeleteAs for the new quality portal, we are going to open up access, but probably not public access. Ideally, we'd reserve logging bugs to registered users, but seems there would be too many exceptions to handle.
I find searching in JIRA quite powerful, even if it takes a little to learn how to create custom complex queries.
Marco Cantù It's possible to make sites indexable by search engines and then require a logon for a normal person to see the content. Could you do that here, perhaps? Searching for known bugs is a very useful thing to be able to do.
ReplyDeleteEven just the step of being able to see the bug title and description when linked to, eg the above, would be useful.
Being open about bugs, directions, fixes etc is great too - Emb has a (fairly) closed culture - not sure how much is policy and how much is cultural - and it would be great to see that open up a bit more. It's been very positive in the past when there were technical blogs about what people were working on internally, previews, etc. The more of that, the better.
Marco Cantù let me put it this way: for products available to the public without a bug reporting system that is also available to the public in a read-only way, I will not put bug entries in that system. This is not limited to Embarcadero: I've done that for any company or product involved. For those, I publish issues myself in a public way (like on my blog) so they can benefit from it.
ReplyDeleteIt's different for products that are not available to the public, or for reports that are very sensitive in nature (like zero day vulnerabilities): those get direct bug reports from me whenever possible.
Jeroen Wiert Pluimers When you say "available to the public" you are indicating a rather general statement that cannot be applied in the same way to all software products. Our product is available to the public, but (for example) our library source code is not open or shared.
ReplyDeleteRequiring a totally free EDN account doesn't look such a big barrier. Would you create a source forge account to log or view bug on open source projects there?
Anyway, your take not to report issues. But reporting on a blog post is NOT a way to get a bug fixed, just to get it noticed. Which is quite different.
Marco Cantù Would a middle ground be that bugs are visible publicly, but you have to log in to edit / comment / modify / create? (Having to do that seems quite sensible, actually.)
ReplyDeleteOpenness is important and that goes for more than bugs. It's really strange to link a bug from here and see the preview be the login page, not the bug headline and snippet. I really want to stress this, because it's concerning seeing Emb default to a closed view, and because I would really like to see far more openness from the company. Future plans, blog posts about what people are doing, etc. Look at MS or even Apple (!! of all closed companies, yet they started a blog for Swift) for examples. You yourself are actually a great example because you blog - and we read it :) It's really appreciated by those companies' developer communities, and it helps foster the community too.
Edit: I don't know if you need a SourceForge account to view bugs, but earlier today I was looking at the Virtual Treeview bug list, and I don't have to log in for that. https://code.google.com/p/virtual-treeview/issues/list
David Millington I would not compare an open source project to a commercial software regarding their way of bug tracking.
ReplyDeleteHowever I would prefer if they would make the issues publicly visible (as it was in QC). I don't know for Apple but at least Microsofts (connect.microsoft.com) is publicly visible (I found it several times through google search).
If that all is hidden in the future behind a login that will be very bad.
Stefan Glienke I wasn't comparing it; Marco asked "Would you create a source forge account to log or view bug on open source projects there?" And so my point was no, you shouldn't have to be logged in to view a bug list there, nor do you have to in practice for at least one well-known Delphi project.
ReplyDeleteAbsolutely agreed re QC, MS Connect, and hiding being bad.
The point of my post, which perhaps I communicated badly, was to encourage openness, and to express concern that closed-ness is being chosen, because I don't think it's the right approach in the modern software world.
David Millington Making bugs visible without login is certainly an option we could consider. I see the advantage of deep linking, but we'd also prefer to use the quality portal to host conversations about bugs as much as possible.
ReplyDeleteAbout openness, I think a small part of the community engaging aggressively and a few individuals spreading internal information didn't help in that respect. But we can do better.
Marco Cantù I don't mind logging in to report a bug, as long as after reporting, that report is publicly available on a read-only way without the need for logging in.
ReplyDeleteDavid Millington I see, I somehow missed that statement from Marco. For entering a report I expect to have an account (I actually dislike anonymous bug reporting) but not for reading them as we all agree it seems.
ReplyDeleteDalija Prasnikar Recently I discovered that the QC Client works if disable EDN/BDN authentication in the INI file (BDNAuthentication=0) under "C:\Users\{YOUR_USERNAME}\AppData\Roaming\QualityCentral\QualityCentral.ini"
ReplyDelete