On Mon, May 3, 2010 at 12:19 PM, yersinia <yersinia.spiros@xxxxxxxxx> wrote: > Sure, I can try. If one software is used many time from many user, directly > or indirectly, and it have not such many problems (e.g bug open on bugzilla > for example ), well this could guide to the decision of the goodness of the > software and the need to delete it or not if the maintainer does not believe > to support it yet. Are you speaking as a member of the QA team? This sounds very hypothetical..and not very specific. I'm really not sure that popcon is going to tell us anything about fitness of a package in a way that bugzilla does not already....especially when popcon its not setup to provide enough details in its summary reports to distinguish individual versions of one against another...let alone whether they are testing versions or what not. I don't see how this data is useful at all compared to abrt and bugzilla in doing any sort of QA for anyone. Here's a little exercise . Go into debian's bug tracking system and compare the rank order popularity of a package in popcon with the rank ordering of number of bugs filed against that package in debian's ticketing system for all time. There is a popular theory that holds that all software is roughly equally buggy and that roughly speaking the number of people reporting problems scales with its popularity...not with its general fitness. To be useful for package QA we'd really have to tie it into bodhi to give detailed information about how many people are using a given testing updates compared to nominal usage to help maintainers feel confident that its seen enough testing even when there's been no karma added or subtracted. But such an integrated system would not look anything like popcon and a there would need to be a sit down discussion with bodhi developers on how to best integrate that sort of client side data. > Conversely, if software is not used - directly or > indirectly - this could facilitate the decision to remove it, in the event > that this possibility emerge. Popcon is designed as an opt-in system. You cannot rely on it giving it accurate results on actual usage for the full breath of our repository. Nor the Debian repository for that matter. We carry a significant number of niche packages...packages that will not be seen by popcon-like data collection unless you get a significant proportion of the userbase running it and catch all possible usage scenarios. If you are proposing that the project employ a data driven package expiration policy.. then lets figure out what that policy needs to be and build data collection to meet its requirements...not build the data collection then build the policy that fits after the fact. I do not want to see data collected just because its possible to collect. I want there to be a specific reason and a firm commitment to using the data that we can communicate to our users. -jef -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
