Re: Bugsplashing
On Sun, Jun 3, 2012 at 10:41 PM, Marco Martin notm...@gmail.com wrote: 2) Are the components useful? I could see a lot of use for grouping bugs, and trying to keep a component bug free. But again - only when it is in use. And what is the difference between e.g. containment-desktop and desktop? i think components are fine, maybe there could be a couple more but thise are fine. in this particular case containment-desktop means strictly what happens in the desktop background area, while desktop is the plasma desktop shell application, the actual executable that creates desktops, panels etc. yeah i know, jargon :/ OK, clear. If there is one place where jargon is allowed, it is BKO, as long as it is being used consistently. I guess there has been a fair amount of mix up there, but I'll check. 3) There is a fair amount of bugs that need to be treated with the authority and wisdom of a developer. I can be almost certain that a bug is a wont fix, but only a dev can mark it as such. I could keep a list of such bugs, and throw them over this mailing list once in a while, or perhaps a flag for_devs could work here. This would not be meant as a kicking devs to fix a bug, but should only take 2 minutes of time to comment/check out/close/whatever. something that would be very useful i think is a day of irc meeting with you guys to do this kind of not immediately obvious prioritization and maybe with people taking tasks for actually fixing the ones with more priority. next weeks are quite thehorror (talking at least for me and probably aaron) we could manage to do something in the second half of june a bit before akademy perhaps? I'll try and keep a list of bugs to check. When life allows it, I lazily am around at irc, so if anyone is bored ;) A (minor) bugdays would be useful, but in the case of late June I would combine oldbug-compression with the beta-polishing and a focus on the latest bugs and regressions. Other than that, there is no real urgency for me - as long as we can work our way to a reliable (and short) buglist. Thijs ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Bugsplashing
On 06/04/2012 11:41 AM, Thijs Heus wrote: On Sun, Jun 3, 2012 at 10:41 PM, Marco Martin notm...@gmail.com mailto:notm...@gmail.com wrote: 2) Are the components useful? I could see a lot of use for grouping bugs, and trying to keep a component bug free. But again - only when it is in use. And what is the difference between e.g. containment-desktop and desktop? i think components are fine, maybe there could be a couple more but thise are fine. in this particular case containment-desktop means strictly what happens in the desktop background area, while desktop is the plasma desktop shell application, the actual executable that creates desktops, panels etc. yeah i know, jargon :/ OK, clear. If there is one place where jargon is allowed, it is BKO, as long as it is being used consistently. I guess there has been a fair amount of mix up there, but I'll check. 3) There is a fair amount of bugs that need to be treated with the authority and wisdom of a developer. I can be almost certain that a bug is a wont fix, but only a dev can mark it as such. I could keep a list of such bugs, and throw them over this mailing list once in a while, or perhaps a flag for_devs could work here. This would not be meant as a kicking devs to fix a bug, but should only take 2 minutes of time to comment/check out/close/whatever. something that would be very useful i think is a day of irc meeting with you guys to do this kind of not immediately obvious prioritization and maybe with people taking tasks for actually fixing the ones with more priority. next weeks are quite thehorror (talking at least for me and probably aaron) we could manage to do something in the second half of june a bit before akademy perhaps? I'll try and keep a list of bugs to check. When life allows it, I lazily am around at irc, so if anyone is bored ;) A (minor) bugdays would be useful, but in the case of late June I would combine oldbug-compression with the beta-polishing and a focus on the latest bugs and regressions. Other than that, there is no real urgency for me - as long as we can work our way to a reliable (and short) buglist. Thijs Some bugs need to be fixed before 4.9 is out: for example the Weather Station applet does not display anything anymore (API changes from ions I suppose) so it'll be either fixed or removed as we cannot seriously ship things that are really broken. Anne-Marie ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Bugsplashing
On Mon, Jun 4, 2012 at 12:35 PM, Anne-Marie Mahfouf annemarie.mahf...@free.fr wrote: On 06/04/2012 11:41 AM, Thijs Heus wrote: On Sun, Jun 3, 2012 at 10:41 PM, Marco Martin notm...@gmail.com wrote: 2) Are the components useful? I could see a lot of use for grouping bugs, and trying to keep a component bug free. But again - only when it is in use. And what is the difference between e.g. containment-desktop and desktop? i think components are fine, maybe there could be a couple more but thise are fine. in this particular case containment-desktop means strictly what happens in the desktop background area, while desktop is the plasma desktop shell application, the actual executable that creates desktops, panels etc. yeah i know, jargon :/ OK, clear. If there is one place where jargon is allowed, it is BKO, as long as it is being used consistently. I guess there has been a fair amount of mix up there, but I'll check. 3) There is a fair amount of bugs that need to be treated with the authority and wisdom of a developer. I can be almost certain that a bug is a wont fix, but only a dev can mark it as such. I could keep a list of such bugs, and throw them over this mailing list once in a while, or perhaps a flag for_devs could work here. This would not be meant as a kicking devs to fix a bug, but should only take 2 minutes of time to comment/check out/close/whatever. something that would be very useful i think is a day of irc meeting with you guys to do this kind of not immediately obvious prioritization and maybe with people taking tasks for actually fixing the ones with more priority. next weeks are quite thehorror (talking at least for me and probably aaron) we could manage to do something in the second half of june a bit before akademy perhaps? I'll try and keep a list of bugs to check. When life allows it, I lazily am around at irc, so if anyone is bored ;) A (minor) bugdays would be useful, but in the case of late June I would combine oldbug-compression with the beta-polishing and a focus on the latest bugs and regressions. Other than that, there is no real urgency for me - as long as we can work our way to a reliable (and short) buglist. Thijs Some bugs need to be fixed before 4.9 is out: for example the Weather Station applet does not display anything anymore (API changes from ions I suppose) so it'll be either fixed or removed as we cannot seriously ship things that are really broken. Anne-Marie The official KDE Quality team bug day is next weekend. 9th/10th. It will be mentioned in the KDE beta announcement. There is a full checklist of things to go through on the new QML plasmoids, and that is the part I'm leading. One of the items is to go through and remove any now-invalid bugs, which should hopefully help these efforts. David Edmundson ___ 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
Re: Bugsplashing
The official KDE Quality team bug day is next weekend. 9th/10th. It will be mentioned in the KDE beta announcement. There is a full checklist of things to go through on the new QML plasmoids, and that is the part I'm leading. One of the items is to go through and remove any now-invalid bugs, which should hopefully help these efforts. David Edmundson Cool, will be there, just setup the 4.9 virtual box. But the focus at bug day is a bit different, I guess: I'd argue I'd like to go for checking all the bugs that I can reproduce in 4.8 against 4.9, rather than deflating the backlog of older bugs. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Bugsplashing
On Saturday 02 June 2012, Thijs Heus wrote: Hello Plasma-devvers, Myriams actions at bugs.kde.org stirred my email box last week, and actually got me to do plasma bug triaging myself again. It is awesome to see that the number of bug reports for plasma is now less than half of what it was 180 days ago. With plasma and kwin down so much in bugcount, we can boast a desktop that starts to approach rock steady again -with the numbers to prove it. this effort has been very, very, appreciated Anyway, my usual hobby is to a) make sure that new bugs are checked for dupes and reproducability as far as I can, and b) go through the old end of the database and see what bugs are still valid. Currently there are about 150 open reports without comment in the past half year, and that should go down to close to zero. Now I have a few questions: 1) Do you guys care? The entire exercise only makes sense if the devs want to use BKO the way Martin wrote it in his blogs. 2) Are the components useful? I could see a lot of use for grouping bugs, and trying to keep a component bug free. But again - only when it is in use. And what is the difference between e.g. containment-desktop and desktop? i think components are fine, maybe there could be a couple more but thise are fine. in this particular case containment-desktop means strictly what happens in the desktop background area, while desktop is the plasma desktop shell application, the actual executable that creates desktops, panels etc. yeah i know, jargon :/ 3) There is a fair amount of bugs that need to be treated with the authority and wisdom of a developer. I can be almost certain that a bug is a wont fix, but only a dev can mark it as such. I could keep a list of such bugs, and throw them over this mailing list once in a while, or perhaps a flag for_devs could work here. This would not be meant as a kicking devs to fix a bug, but should only take 2 minutes of time to comment/check out/close/whatever. something that would be very useful i think is a day of irc meeting with you guys to do this kind of not immediately obvious prioritization and maybe with people taking tasks for actually fixing the ones with more priority. next weeks are quite thehorror (talking at least for me and probably aaron) we could manage to do something in the second half of june a bit before akademy perhaps? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Bugsplashing
Hello Plasma-devvers, Myriams actions at bugs.kde.org stirred my email box last week, and actually got me to do plasma bug triaging myself again. It is awesome to see that the number of bug reports for plasma is now less than half of what it was 180 days ago. With plasma and kwin down so much in bugcount, we can boast a desktop that starts to approach rock steady again -with the numbers to prove it. Anyway, my usual hobby is to a) make sure that new bugs are checked for dupes and reproducability as far as I can, and b) go through the old end of the database and see what bugs are still valid. Currently there are about 150 open reports without comment in the past half year, and that should go down to close to zero. Now I have a few questions: 1) Do you guys care? The entire exercise only makes sense if the devs want to use BKO the way Martin wrote it in his blogs. 2) Are the components useful? I could see a lot of use for grouping bugs, and trying to keep a component bug free. But again - only when it is in use. And what is the difference between e.g. containment-desktop and desktop? 3) There is a fair amount of bugs that need to be treated with the authority and wisdom of a developer. I can be almost certain that a bug is a wont fix, but only a dev can mark it as such. I could keep a list of such bugs, and throw them over this mailing list once in a while, or perhaps a flag for_devs could work here. This would not be meant as a kicking devs to fix a bug, but should only take 2 minutes of time to comment/check out/close/whatever. Cheers, Thijs ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
