pe, 2006-02-24 kello 18:27 -0300, Gustavo Franco kirjoitti: > What i thought in a first look to the Lars' list. I think that the > best thing would include piuparts as a infrastructural test (oficially > as a part of our archive code), or due to restrict admin time to do > that, opt for something like piuparts.debian.org as we have > lintian.d.o.
Do you mean that the archive should automatically reject uploads that don't pass a piuparts check? I think that sounds like a nice idea, but we're not yet in a situation where it is feasible. For example, the reason piuparts testing fails may be due to a bug in an unrelated package. This needs to be dealt with manually, and that requires quite a bit of effort. For the time being, at least, I think it is better for Debian to let uploads run smoothly, and do piuparts testing separately. If we are to start doing checks on packages before accepting uploads, I think it would be best to start with some subset of lintian and linda errors. Lintian and linda are faster to run, anyway, and less risky, and less likely to hang. > I would be glad to help with a web interface to show the piuparts html > results in a organized way Something like piuparts-report.py? Anyway, I think it is more productive if package maintainers run piuparts themselves, and then people running piuparts centrally reporting bugs. The lintian.debian.org experience seems to be that having lots of info on the web is nice, but filing bug reports actually gets things fixed. As it happens, however, there is work going on in getting a centralized machine to run piuparts testing, and that machine will be used to publish logs and statistics. I haven't done that so far because the logs are big, and I don't have gigabytes of disk space and bandwidth to spend on them. > Since Lars already did the check (for i386 only, i think), I haven't tested the entire i386, either, only about half or so. The rest is waiting for their dependencies to be fixed, or for something to happen with regards to circular dependencies (which at the moment are likely to make piuparts testing fail). -- Boilerplate programming mean tools lack power. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
