Hi *! On 2004-03-08 17:47 +0100, Jeroen van Wolffelaar wrote: > On Mon, Mar 08, 2004 at 05:37:37PM +0100, Martin Pitt wrote: > > On 2004-03-08 16:46 +0100, Jeroen van Wolffelaar wrote: > > IMHO the date of last upload is a very bad indicator of the current > > state of a package; the bug count besides certainly does much better. > > It all adds together. Of course. But as you say, many packages just don't need much maintenance; but as long as these numbers are viewed in context and are interpreted by a human (as opposed to automatically marking maintainers as MIA or packages as orphaned when last activity >= treshold), only conerning the last upload should not be much of a problem. However, IMHO the last bug activity would still be interesting. > > Nevertheless, your script works (apart from using outdated numbers) > > I just calculated my get-old-versions script needs to run for another 10 > days until it has all info. I then have a 'historical madison', you can > get madison-like output from any date starting with the snapshot.d.n > epoch (June 4th 2002). Web interface on it's way. This was not intended to be criticism, I know that it is just a prototype by now :-) > > and generally I like the idea of an "activity meter". But maybe you > > can alter the concept a little bit? My idea would be to give each > > package only one "last activity" figure and calculate it (maybe) as > > > > last activity = MIN (last upload, last reply to bug, > > last tag setting to bug) > > This is possible, though it is very easy to 'reset' activity then, by > simply being provoked one bug reaction, you reset it. That was the idea. I think many de-facto orphaned packages don't even have bug replies by the maintainer. Of course the criteria could be narrowed, but there will always be a way to fool (reset) the activity meter without actually improving the package (at least one could upload the same package with an increased Debian revision again). > I think one general 'last activity' says too little about a package. > Still, some packages simply don't NEED much activity. Then maybe the obvious compromise would be to have two numbers: last upload / last BTS activity ? > > Why have packages whose Sid version is also in testing two numbers? > > What do they say? > > The left one says when that version entered testing, the right one when > that version hit sid. Thanks. On my page (login=mpitt) many of these number pairs are equal or differ only by one day, but this may get right if used with current data. > > If you alter your measuring to only one number, then I would favor a > > new row; currently the version cells contain disturbingly many > > numbers. If you keep the per-distribution activity, I think it is > > quite okay since versions and last-upload days have different colors. > > :). About activity, that is currently hard to do, no script yet extracts > last bug activity from the maintainer. I also don't know none that recors this. As a last resort one could parse the bug pages, but that will certainly be non-trivial. Maybe one could get read-only access to the BTS database? Have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer martin@piware.de mpitt@debian.org http://www.piware.de http://www.debian.org
Attachment:
signature.asc
Description: Digital signature