Re: Re: the utter failure of bugzilla (and us?)
Sorry to rain on the parade, but it has to be done unfortunately. First - Sysadmin decided long ago that KDE would be using a single bug tracker - and that we would maintain only one bug tracker. Hence why the bug tracking capabilities of Redmine are disabled. Second - I suspect that all the options that have been floated so far would collapse under the sheer number of bugs KDE currently has. Note that sysadmin will not permit the discarding of the current content of the KDE Bugzilla instance. It isn't permissible - it has to be imported into the new installation (if one were to be setup) Third - Nobody here has contacted sysadmin to find our current plans with regard to Bugzilla. Assuming everything goes well, Bugzilla will be moved at some point in the future to a much more powerful server, and will be upgraded to Bugzilla 4. Further, plans to implement a Sphinx based search backend to Bugzilla have been floated. Do note that simply changing the bug tracker will not increase the number of people which triage the bugs we currently have, nor will it fix the issue of users being permitted to report bugs freely. And changing the bug tracker would also completely break DrKonqi. Restricting users based on their karma or other measures would not be a publicly acceptable measure either I guess (although placing them into a different category probably would be accepted - but Bugzilla does that anyway). Note that Bugzilla itself is capable of restricting users from commenting/posting new bugs/etc as far as I am aware. Regards, Ben ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the utter failure of bugzilla (and us?)
Hi, What about a massive bug crush week-end where all devels commit themselves to triage and fix, that would clear out most of the reports as once you get into it you tend to be more efficient as you know backtraces and all. This would require people to commit to it because last bug squad I did (not Plasma) was reduced to 2 people or so... Week-end of 4th - 5th June or 11th-12th or next one? I can setup a community webpage with batches of 5 reports and blog about it. I am willing to get it into action but it needs strong commitment from everyone. Anne-Marie On Wednesday 25 May 2011 19:14:13 Aaron J. Seigo wrote: hi ... so, congratulations everyone, plasma is #3 in bugs.kde.org with over 1300 reports: https://bugs.kde.org/weekly-bug-summary.cgi trawling through some right now, it seems that probably ~5% are actual issues, 5-15% more are things that could be improved, and the rest is mostly duplicates, downstreams/upstream or flawed reports. thing is, with 1300 reports, doing 1 per minute would take 21+ hours. and with bugzilla it is a LOT more than 1 minute per bug. probably closer to 10 for full inspection and resolution. which means 210 hours, at best. that we got here is beyond me. i think the issues are obvious: * we don't have a sufficient bug triage team * the user community is enabled to stuff any crap they wish into the database, making the signal-to-noise ratio absolutely horrid * bugzilla is slow * bugzilla has horrifically bad usability we ought to find a way to improve on this situation, but tackling one or more of the above. i don't have any answers right now, just frustrations. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Expanding PlasmaCore.Dialog in Qml
On Monday 23 May 2011, Onur-Hayri Bakici wrote:
Hey,
When i use PlasmaCore.Dialog inside an Item with a fix height and width
Item {
id: dialogItem
height: 200
width: 200
PlasmaCore.Dialog {
// some stuff
}
onEvent: {
dialogItem.height += 32
}
}
and try to change the height and width of the item(since dialog has no
height and width property), however the height property change is not
visible. Moreover does it change when I output the properties in the
terminal. Does anyone know what am I doing wrong?
thank you
the dialog is a top level widget/window (it's used to have standalone
windows), and is not influenced by its parent widget.
instead, you put an Item inside the dialog and to control the size you
either set the one of the dialog or its internal widget
Thank you for the clou, however I came across another limitation. The
PlasmaCore.Dialog Component only requires a QGraphicsWidget as the mainItem.
When I put a ListView into the QGraphicsWidget, it doesn't get displayed. Is
there maybe any other way to bypass this problem?
Thank you
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Expanding PlasmaCore.Dialog in Qml
On Thursday 26 May 2011, Onur-Hayri Bakici wrote: the dialog is a top level widget/window (it's used to have standalone windows), and is not influenced by its parent widget. instead, you put an Item inside the dialog and to control the size you either set the one of the dialog or its internal widget Thank you for the clou, however I came across another limitation. The PlasmaCore.Dialog Component only requires a QGraphicsWidget as the mainItem. When I put a ListView into the QGraphicsWidget, it doesn't get displayed. Is there maybe any other way to bypass this problem? that strange, in the source code (you can take a look atkde- runtime/plasma/declarativeimports/core/dialog.cpp ) there are 2 different code paths for qgraphicswidgets and qdeclarativeitems, there could be a bug there, but iirc i'm already ising normal qdeclaraticeitems elsewhere (note that they have to have a width and height set before being setted in the dialog, or the dialog could remain with 0,0 size) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the utter failure of bugzilla (and us?)
- Ursprüngliche Mitteilung - Hi, What about a massive bug crush week-end where all devels commit themselves to triage and fix, that would clear out most of the reports as once you get into it you tend to be more efficient as you know backtraces and all. This would require people to commit to it because last bug squad I did (not Plasma) was reduced to 2 people or so... I do that from time to time for KWin and am not able to triage more than 20 bugs/hour. Sorry to say, but it doesn't scale and you don't notice the duplicates if several people are working on it. Week-end of 4th - 5th June or 11th-12th or next one? I can setup a community webpage with batches of 5 reports and blog about it. I am willing to get it into action but it needs strong commitment from everyone. Anne-Marie On Wednesday 25 May 2011 19:14:13 Aaron J. Seigo wrote: hi ... so, congratulations everyone, plasma is #3 in bugs.kde.org with over 1300 reports: https://bugs.kde.org/weekly-bug-summary.cgi trawling through some right now, it seems that probably ~5% are actual issues, 5-15% more are things that could be improved, and the rest is mostly duplicates, downstreams/upstream or flawed reports. thing is, with 1300 reports, doing 1 per minute would take 21+ hours. and with bugzilla it is a LOT more than 1 minute per bug. probably closer to 10 for full inspection and resolution. which means 210 hours, at best. that we got here is beyond me. i think the issues are obvious: * we don't have a sufficient bug triage team * the user community is enabled to stuff any crap they wish into the database, making the signal-to-noise ratio absolutely horrid * bugzilla is slow * bugzilla has horrifically bad usability we ought to find a way to improve on this situation, but tackling one or more of the above. i don't have any answers right now, just frustrations. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
No icon displayed on plasmoid once installed
Hello to all devs. I have a strange problem. When launching a plasmoid with plasmoidviewer I can see protocol icons (im-protocol) but when I install the plasmoid, this protocol is not visualized leaving an empty space. Screenshot[1]. Do you guys know what's going on? Thanks, Francesco [1]http://postimage.org/image/2budewwis/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the utter failure of bugzilla (and us?)
On Thursday, May 26, 2011 20:05:11 Ben Cooksley wrote: Sorry to rain on the parade, but it has to be done unfortunately. let me return the favour then ;) bugzilla in its current state is not sufficient. we can offer all the reasons we want to as to why it will be hard to move away from it or why we should stick with it. it does not change the reality that right now our workflow is not just crap, it is non-existent. we have a lot more than just bugzilla to look at however. we also have our team and social practices to examine and re-tool. i'm done with us keeping our heads in the sand, however. Third - Nobody here has contacted sysadmin to find our current plans with regard to Bugzilla. Assuming everything goes well, Bugzilla will because we don't quite yet know what we need yet either. sysadmin is not the first stop on our way to understanding our needs :) honestly, i'm less interested in us looking at software options as i am at us figuring out what support we need from a defect tracker and how we'd like to mold our practices around it. i'm happy it sysadmin does the solution shopping with that information in hand. Do note that simply changing the bug tracker will not increase the number of people which triage the bugs we currently have, nor will it but it can allow us to be more effective and efficient with triage, allowing us to keep up better. fix the issue of users being permitted to report bugs freely. And no, but we could address this at the same time changing the bug tracker would also completely break DrKonqi. that's a very real issue indeed Restricting users based on their karma or other measures would not be a publicly acceptable measure either I guess (although placing them i think we need to place more emphasis on enabling developers to be effective rather than making cranky users feel better at the cost of our productivity and therefore the resulting quality of the product. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the utter failure of bugzilla (and us?)
On Wednesday, May 25, 2011 21:16:13 Kevin Ottens wrote: What about the elephant in the room? That is redmine, it's already deployed by KDE sysadmins and used, it's just that the ticketing system isn't activated. redmine really ought to be the first option analyzed because it exists and is integrated with our infrastructure, as you note. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: No icon displayed on plasmoid once installed
On Thursday 26 May 2011 21:33:18 Marco Martin wrote: On Thursday 26 May 2011, Francesco Nwokeka wrote: Hello to all devs. I have a strange problem. When launching a plasmoid with plasmoidviewer I can see protocol icons (im-protocol) but when I install the plasmoid, this protocol is not visualized leaving an empty space. Screenshot[1]. Do you guys know what's going on? Thanks, Francesco [1]http://postimage.org/image/2budewwis/ uhm, could be an icon cache issue? Rebooted and icons came back. Why this? Is there a way to refresh the icon cache? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the utter failure of bugzilla (and us?)
On Thursday, May 26, 2011 10:22:06 Anne-Marie Mahfouf wrote: Week-end of 4th - 5th June or 11th-12th or next one? I can setup a community the platform sprint is next week, so those first dates won't work. 11/12th might ... but before we go charging off on a bug crush weekend, i'd like to have some clarity on what we are trying to achieve with our bug handling processes. e.g. it seems that to be effective we need a more agressive categorization of bugs into useful products/categories such as: * libplasma, probably divided out into functional areas (SVG, DataEngine/Services, Widgets, etc) * one product per shell * one product per plugin (this, btw, is an area that i find bugzilla is not very easy to work with) guidelines for when we close a bug without prejudice, e.g. more than N releases old, insufficient feedback from user, non-critical functionality. we can't just keep letting reports float around because we're too concerned about closing things that might be able to be closed if magical fairies appear in bugzilla ;) we need some way of gathering useful information for reference such as common backtrace fingerprints that point to invalid reports or known upstream/downstream issues somewhere that we can all find it and add to it. community.kde.org seems like a good place. i suggested to asraniel on irc that he picks a few plugins at random, gathers all the reports up on those, and then we focus on those BR's for the next few weeks. repeat ... i'd really like to see us have, in other words, something like a strategy before we go off trying to slay the dragons :) webpage with batches of 5 reports if we take just the most recently reported half of the reports, that's 150 batches of 5! :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
