Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
On Mon, Mar 12, 2012 at 10:06 PM, Paul Wise <pabs@debian.org> wrote:
> On Mon, 2012-03-12 at 21:16 -0400, Michael Gilbert wrote:
>
>> Also, why is "c.execute("PRAGMA foreign_keys=ON")" necessary?
>
> sqlite doesn't enforce foreign key constraints by default:
>
> https://sqlite.org/foreignkeys.html#fk_enable
>
> I'm using those to ensure maintainers are deleted when source packages
> are deleted from the database.
There is a removed_packages table that you can use to check whether
the package is currently in debian or not.
>> At a cursory glance, this seems more complicated that it needs to be.
>> You're creating an "id" for each source package, but that is redundant
>> since the package name itself is a unique id.
>>
>> All you should need is a table with only sourcepkg names and
>> maintainer fields. Then when you process a view on (for example) a
>> maintainer page you can step through all sourcepkg names listed as
>> associated with that maintainer via that table.
>
> The source package name is definitely not unique since there are
> multiple suites that could have a line in the source package table.
It's still the same source package. You could step through each suite
separately on the maintainer pages since yes they will each have
different sets of issues.
> I'm not sure if the foreign key stuff would work with non-numeric keys.
Foreign keys should not be necessary at all.
> If a package gets removed from sid, we still want the issues present in
> stable to be listed on the maintainer's page. Going with your suggestion
> would mean that we would not know which maintainers to remove when a
> package is deleted from one particular suite.
You could limit results by checking that the release is in a supported
release (squeeze,wheezy,sid). All packages are considered in the
archive until they're not in any release.
But I really think you want a listing of issues per suite per maintainer.
Best wishes,
Mike
Reply to: