Re: Announcement: New bugs pages, status of renaming
Andreas Tille [EMAIL PROTECTED] writes: On Thu, 13 Nov 2008, Chris Walker wrote: You might also want to ignore, or reduce the weight of bugs under a certain age - perhaps an absolute cut off of 28 days, or perhaps a sliding scale depending upon severity - with critical bugs becoming important immediately. This might not be worth the effort of implementing though. I do not think that the age of a bug should have an influence on the result. Open bugs are just open bugs and should be fixed. Help is needed for old and new bugs. That's true, though if the although a normal bug fixed The reason IYes, that's true. The rationale behind suggesting it was that it With the exception of Mathematics-dev and biology, all the tasks have the red status, and biology would too if it reflected the state of the underlying tasks. I think therfore you're too harsh - and should make it easier to obtain satisfactory status (but if/when we get good at fixing bugs you could change it). Yes, I realised that my measure is quite harsh and I see the problem that if people who are willing to work on the bugs will not see any result on the status might loose interest. So we should take this serious. So if enybody wants to make suggestions on better limits for the assessments (see Legend on overview page) I keen on hearing this. After lenny is released would be a better time to tune the number - at the moment there is, quite rightly, some relectance to upload new packages. Moreover I wonder whether I should make theses limits configurable per Blend. There is a configuration file per Blend anyway - putting the limits there to adapt to the specific blend (metapackages with less dependencies will be easier to get into shape than those with more). That's probably a good idea. I don't think you should give different severities the same score - as you do for critical grave and serious, but I'm not sure I can come up with a better set of numbers than you have. I agraa this was a rough estimate for the first shot. I was guided by the fact that all of these three are release critical and so all of them should be fixxed immediately. That's true, but there is a difference between not meeting policy requirments and breaking the whole system and causing severe data loss. So what would be the proper score for even more immediately??? I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. Chris PS if you added an orange level, you would have one more level to play with. I'm assuming here bug severity goes in the order of colours of the rainbow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Thu, 13 Nov 2008, Chris Walker wrote: That's true, though if the although a normal bug fixed The reason IYes, that's true. The rationale behind suggesting it was that it ... ups this paragraph is unfinished ... After lenny is released would be a better time to tune the number - at the moment there is, quite rightly, some relectance to upload new packages. This after lenny remark brings up another issue: The current bug pages do not respect any stable / frozen / testing / unstable differentiation. This might be interesting, but currently I do see more urgent problems to solve - feel free to spend some time on it if you regard this as an urgent problem. A bit more interesting might be to leave out bugs tagged wontfix (and it is simpler to implement). That's true, but there is a difference between not meeting policy requirments and breaking the whole system and causing severe data loss. Sure. I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. Understand the principle. The much higher score of the critical ones also might reduce the influence of a lot of minor / normal bugs in a metapackage with much dependencies. Do you have any suggestions for the limits that fit these scores. PS if you added an orange level, you would have one more level to play with. I'm assuming here bug severity goes in the order of colours of the rainbow. Well, any volunteer to work on a proper css file. I wished some people would start working in SVN on this stuff. Testing is easy by just doing rsync -a alioth.debian.org:/var/lib/gforge/chroot/home/groups/cdd/htdocs . and you have your local copy of the result. Than you can play with the CSS file (which differentiates those bugs). Then you can check in the new css if you are happy about it. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
Andreas Tille [EMAIL PROTECTED] writes: On Thu, 13 Nov 2008, Chris Walker wrote: That's true, though if the although a normal bug fixed The reason IYes, that's true. The rationale behind suggesting it was that it ... ups this paragraph is unfinished ... What I meant to say is: As the aim of these pages is to encourage people to take an overview of where help is required, packages where the maintainer deals with bugs in a timely manner are much less in need of help than packages where the bugs have built up over time. But, as you say, a bug is a bug, so it's not clear how much advantage there is in implementing this. After lenny is released would be a better time to tune the number - at the moment there is, quite rightly, some relectance to upload new packages. This after lenny remark brings up another issue: The current bug pages do not respect any stable / frozen / testing / unstable differentiation. This might be interesting, but currently I do see more urgent problems to solve - feel free to spend some time on it if you regard this as an urgent problem. A bit more interesting might be to leave out bugs tagged wontfix (and it is simpler to implement). Yes, that makes sense. That's true, but there is a difference between not meeting policy requirments and breaking the whole system and causing severe data loss. Sure. I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. Understand the principle. The much higher score of the critical ones also might reduce the influence of a lot of minor / normal bugs in a metapackage with much dependencies. Do you have any suggestions for the limits that fit these scores. An immediately attractive idea would be the value of one critical bug - in which case, suggestion B might be better than A. Then perhaps a linear spacing: red: 729 *4/4 (80+ normal bugs) yellow: 729*3/4 (60+ normal bugs) green: 729*2/4 (40+ normal bugs) blue: 729*1/4 (20+ normal bugs) but I haven't actually tried it to see if it would work. PS if you added an orange level, you would have one more level to play with. I'm assuming here bug severity goes in the order of colours of the rainbow. Well, any volunteer to work on a proper css file. I wished some people would start working in SVN on this stuff. Testing is easy by just doing rsync -a alioth.debian.org:/var/lib/gforge/chroot/home/groups/cdd/htdocs . and you have your local copy of the result. Than you can play with the CSS file (which differentiates those bugs). Then you can check in the new css if you are happy about it. I'll see if I can make time to have a look, but don't hold your breath. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Thu, 13 Nov 2008, Chris Walker wrote: I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. An immediately attractive idea would be the value of one critical bug - in which case, suggestion B might be better than A. Then perhaps a linear spacing: red: 729 *4/4 (80+ normal bugs) yellow: 729*3/4 (60+ normal bugs) green: 729*2/4 (40+ normal bugs) blue: 729*1/4 (20+ normal bugs) but I haven't actually tried it to see if it would work. Well, it sounds reasonable to go with B because I have this additional feature that bugs in dependent packages are weighted three times higher than those that are only suggested. So a grave bug in a dependent package would score the same as a critical bug in a suggested package and we get color red for both cases. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
Andreas Tille [EMAIL PROTECTED] writes: Ahh, yes. This is definitely planed. I also wanted to link from the tasks pages to the bugs pages somehow indicating the bug status as well. But I wanted to gather some comments on my estimation of the status first. I really like the idea - so here are my comments: The biology status doesn't take into account the bugs in the two metapackages it depends on (though how you'd do this, I'm not quite sure). As we've said in private e-mail, absolute bug counts are a measure of help required, whereas quality would best be measured by normalising to number of packages. I think you've made the right choice here. You might also want to ignore, or reduce the weight of bugs under a certain age - perhaps an absolute cut off of 28 days, or perhaps a sliding scale depending upon severity - with critical bugs becoming important immediately. This might not be worth the effort of implementing though. With the exception of Mathematics-dev and biology, all the tasks have the red status, and biology would too if it reflected the state of the underlying tasks. I think therfore you're too harsh - and should make it easier to obtain satisfactory status (but if/when we get good at fixing bugs you could change it). I don't think you should give different severities the same score - as you do for critical grave and serious, but I'm not sure I can come up with a better set of numbers than you have. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Fri, Nov 7, 2008 at 7:11 AM, Andreas Tille [EMAIL PROTECTED] wrote: For the moment I hesitate to announce the DebiChem project here because this is work is neither finished nor do I want to take over the fame of announcing somebody elses project, but you might like to have a preliminary look at DebiChem: http://cdd.alioth.debian.org/debichem/bugs as well. Very nice overview! I really like this. One thing I miss (wishlist), is a link to a page indicating which packages belong to which task... particularly, where do I find bodr and libcdk-java? Egon -- http://chem-bla-ics.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Fri, Nov 7, 2008 at 1:17 PM, Andreas Tille [EMAIL PROTECTED] wrote: On Fri, 7 Nov 2008, Egon Willighagen wrote: Indeed. BTW, I like the idea of that page. Which one. The Wiki page or the tasks page which lists (translated) descriptions, links etc? Both actually :) but I was referring to the wiki page... I'm also part of DebiChem, though unfortunately rather dorment in the last two years... I'll check the discussion asap again, and comment on it to the debichem ML. Ahh, that's good to know. For my perception only Michael and Daniel formed the team. Perhaps you are volunteering to maintain the tasks pages for the moment. Its a simple editing of debian/control - like files. Just ask me if I should add you to CDD Alioth group ... Let's see... might be a good way to do some Debian work again... and I should more time for these things again... and with a bit of luck, for packaging bioclipse too... anyway... need to properly settle in my new environment (like learning Swedish and sorts)... and this would be a simple, short task... I'll get back on this. Egon -- http://chem-bla-ics.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Fri, Nov 7, 2008 at 4:17 AM, Andreas Tille [EMAIL PROTECTED] wrote: On Fri, 7 Nov 2008, Egon Willighagen wrote: I'm also part of DebiChem, though unfortunately rather dorment in the last two years... I'll check the discussion asap again, and comment on it to the debichem ML. Ahh, that's good to know. For my perception only Michael and Daniel formed the team. Perhaps you are volunteering to maintain the tasks pages for the moment. Its a simple editing of debian/control - like files. Just ask me if I should add you to CDD Alioth group ... There is also Nicholas Breen and myself who do some work in Debichem. I'm also a sometimes contributor to Debian Science. I'm sorry if my lack of emails indicated that I didn't care about your task pages. I just didn't have any complaints :-) For my part, I'm still trying to figure out what exactly all this CDD/Blends/Tasks infrastructure stuff is all about. I love the generated pages but I'm not sure what *I* can do to help. What exactly does it mean to maintain these task pages? -Jordan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Fri, 7 Nov 2008, Egon Willighagen wrote: DebiChem: http://cdd.alioth.debian.org/debichem/bugs as well. Very nice overview! I really like this. Thanks. One thing I miss (wishlist), is a link to a page indicating which packages belong to which task... particularly, where do I find bodr and libcdk-java? You mean an alphabethically sorted list of packages that is in the list of dependencies naming the task(s) it is used in? This might be possible - but I'm not really convinced that this is urgently needed. For example an easy answer to your question is given by $ apt-cache rdepends bodr libcdk-java libcdk-java Reverse Depends: science-chemistry science-chemistry bodr Reverse Depends: science-chemistry science-chemistry libgcu0 so both packages currently belong to the Chemistry task of Debian Science. My guess that the real problem of your question is that you are missing these packages inside the DebiChem project. You might remind that I wrote: Please keep in mind that the tasks of this project are far from ready actually I did not even heard from any DebiChem member whether they like my step to create tasks files for their project or not. If I'm not missleaded the DebiChem project is currently basically a packaging effort runned by two people. Michael Banck seems to be in favour of my effort (at least he told me that he likes the tasks pages I did for Debian Science and I hope that he likes the (half done) start of DebiChem pages [1] as well. As I wrote in one of my previous mails[2] I did not finished the job to turn the categorisation which was done in the Wiki[3] (btw, it lists your packages in question amongst Other) because I will not spend my time into stuff which might not be accepted. So until I hear something positive about my work from the DebiChem people I will not continue with the tasks files. But feel free to go on with this work - it's all in SVN and if you want permission for editing - just tell me you Alioth login to add you to the project. Kind regards Andreas. [1] http://cdd.alioth.debian.org/debichem/tasks [2] http://lists.debian.org/debian-science/2008/10/msg00138.html [3] http://wiki.debian.org/DebianScience/Chemistry -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
Jordan Mantha [EMAIL PROTECTED] writes: On Fri, Nov 7, 2008 at 4:17 AM, Andreas Tille [EMAIL PROTECTED] wrote: On Fri, 7 Nov 2008, Egon Willighagen wrote: I'm also part of DebiChem, though unfortunately rather dorment in the last two years... I'll check the discussion asap again, and comment on it to the debichem ML. Ahh, that's good to know. For my perception only Michael and Daniel formed the team. Perhaps you are volunteering to maintain the tasks pages for the moment. Its a simple editing of debian/control - like files. Just ask me if I should add you to CDD Alioth group ... There is also Nicholas Breen and myself who do some work in Debichem. I'm also a sometimes contributor to Debian Science. I'm sorry if my lack of emails indicated that I didn't care about your task pages. I just didn't have any complaints :-) AIUI, the goal of Debian Science is to improve support for science in Debian. People differ in their priorities, but some things that I think are important are: Packaging a wide range of useful software with high quality - Making sure these packages don't become out of date - Fixing bugs Advertising/Documenting what software is available and what problems it solves - and perhaps how to use several packages together. Personally I think we should also steer people away from obsolete software. Producing a LiveDVD of science packages For my part, I'm still trying to figure out what exactly all this CDD/Blends/Tasks infrastructure stuff is all about. The tasks infrastructure is a way of easily installing packages appropriate to a particular area of science. It also serves to advertise that debian provides those packages. The bugs pages will make it easier to spot if a maintainer has gone MIA/is in need of help by highlighting bugs in a particular area. It also makes it easier for Non DDs and those with limited time to find bugs that they can help with. I love the generated pages but I'm not sure what *I* can do to help. Ah yes, that reminds me - I've added some text to the Contributing to Debian Science on the wiki http://wiki.debian.org/DebianScience with suggestions about how DDs and non debian developers can help. I'm not sure I link sufficiently well to the Efforts that could be undertaken. Comments please - either here, or by editing the wiki. Am I repeating something that is described elsewhere? What have I missed? What exactly does it mean to maintain these task pages? Adding new packages to appropriate tasks. Removing obsolete packages. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Announcement: New bugs pages, status of renaming
Hi, I'm proud to announce a new QA tool for all CDD^W Blends: Overview about all bugs about Dependencies of our metapackages. For the impatient here is a list of these pages: Edu: http://cdd.alioth.debian.org/edu/bugs GIS: http://cdd.alioth.debian.org/gis/bugs Jr: http://cdd.alioth.debian.org/junior/bugs Med: http://debian-med.alioth.debian.org/bugs Science: http://cdd.alioth.debian.org/science/bugs For the moment I hesitate to announce the DebiChem project here because this is work is neither finished nor do I want to take over the fame of announcing somebody elses project, but you might like to have a preliminary look at DebiChem: http://cdd.alioth.debian.org/debichem/bugs as well. Please keep in mind that the tasks of this project are far from ready and there are also some remaining problems in obtaining the metapackage name in the page rendering code - I will fix this once the Debichem Project might agree to join the Blends effort and decides for a name. If you not care about the details of these pages but are interested in the status of CDD - Blends renaming you can skip some paragraphs now. Motivation for the bugs pages - My main motivation for Debian Pure Blends is that I see a need to find some substructure in the large flat package pool of Debian. I'm absolutely convinced that this has to be done based on user interest and needs and so every Blend should be an entry point for a specific user group into the large world of Debian. I think that a specific user group is interested in a specific set of packages and consequently they might care more about the bugs of these packages than in any random package. So how should we attract users to have a look into this very specific package bugs? The answer are these bug pages. Assume you are a mathematician and have some time to spend on bugs inside Debian. Where would you like to start seeking where to spend your time best? It should be helpful for both: For Debian and for you personal work and you should feel competent about the package you want to work on. Since today the answer is simple: Go to http://cdd.alioth.debian.org/science/bugs/mathematics.html and watch for bugs. On top of the page you see the note: Immediately looking into bugs of the dependencies of this metapackage is advised so your help is obviosely welcome. You also see immediately that there are two serious bugs in packages which are in the list of dependencies (not only suggested) of science-mathematics. So you found your targets quickly. The Bugs pages are not (yet) internationalised. I'm a little bit undecided whether this is really needed. I'm actually very keen on translations whereever needed - but if we want to attract people fixing the bugs they have to understand the bug report in English language anyway. So people unable to understand the navigation might probably be not able to work on the bugs. What do you think about this? Realisation of the evaluation of bug status --- I tried to find a measure how much help is needed for the dependencies of a metapackage. This measure is not about the quality of a metapackages because this would require a normalisation according to the number of packages. For instance a metapackage with 5 bugs in 25 dependendent packages is probably of a better quality than a metapackage with 3 bugs in 5 dependant packages. But I think we should care about the absolute number of bugs if we want to attract people who are willing to fix them and not about making some ranking inbetween metapackage quality. Moreover I think that bugs in packages that are in the list of Depends and Recommends should be weighted higher than those packages which are only suggested. This is reflected in the fact that the dependent packages are listed on top in a separate list. Below is a list of suggested packages. The bugs which are done are listed as well for historical reason - but they do n ot influence the bug status of the metapackage - done bugs do not need to attract our attention that much. The evaluation is done by finding some weighting numbers for the different severities ranging from 10 for the RC bugs until 0 for wishlist bugs (see the currently used numbers in the footnote on the bottom of each page). I decided to weight wishlist bugs with 0 not because I think that wishlist bugs are not very interesting. IMHO every bug should be fixed - but I think that it might be a very rare situation that on one page only bugs with severity wishlist and so chances are quite low that wishlist bugs are just overlooked because there is no mark on the index page to visit this page. These weighting numbers are multiplied by 3 if the package in question is a dependent or recommended package to reflect their higher importance. Lets make a simple example: http://cdd.alioth.debian.org/science/bugs/linguistics.html 1 serious
