[Qa-debsources] patch-tracker DB schema

[Stefano Zacchiroli]

Heya, sorry for the delay!

On Mon, Jan 18, 2016 at 11:09:57AM +0100, Orestis Ioannou wrote:
> ++++++++++++++++++
> |||||Patches||||||
> ++++++++++++++++++
> |     id         |
> +----------------+
> |     file_id    |
> +----------------+
> |   package_id   |
> +----------------+
> |  file deltas   |
> +----------------+
> 
> The file_id points to the file in debian/patches.

Can you post the actual SQL for the above schema? I've plenty of
specific questions about the different fields, but commenting SQL will
be easier for everyone, I think :)

> Maybe file deltas are useless, the idea behind storing them is that we
> could possibly in the future have the following use case:
> 
>     - Which are the patches that have been applied to this 'file' in
> this 'package'
> 
> They can be a JSONB object.

I don't understand what you plan to store in the file deltas JSON. Here
too, an example (or a JSON schema) would help the discussion.

> I propose another two modifications for the package table:
> - store the patches format

I guess this means adding a nullable, enumerated column, with the
detected package format. I agree that this is useful information to have
in the DB. OTOH, I'm not sure we should put it into the packages table.

To me, it looks like that we are going to have two kind of patches
information: some that are specific of a package as a whole (like the
patch format), some that are specific of a given patch (like the various
fields you mentioned above, I think). How about having those 2 as
separate tables, rather than 1 table + a modification of the current
packages table?

> - store the SHA256 of the orig.tar.gz. This was something in the old
> patch tracker and I think its usefull for upstreams (Easily find out if
> maintainer changed something).

Same comment as above: useful information, but I'm not sure yet it
should be in the packages table. How about adding a source package
table? Thinking of it, this table might be the same that contains both
the SHA256 (and possibly other checksums) and the patch format.

> In the use stories (in doc/patch-tracker.txt) I thought of the
> possibility of proposing to download and view a diff of the orig.tar.gz.
> With the proposed schema this is not possible. Are we maintaining this?
> I guess to do this we will need to store the diff while we extract the
> package.

I don't remember this specific use case. Am I reading you right, by
saying that what was desired here is a global diff w.r.t. upstream,
uniting all patches together? Frankly, I'm not sure it would be that
useful as a use case...

Cheers
-- 
Stefano Zacchiroli  . . . . . . .  zack at upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/qa-debsources/attachments/20160121/23b6401c/attachment.sig>