[Qa-debsources] patch-tracker DB schema

[Orestis Ioannou]

On 01/21/2016 03:45 PM, Stefano Zacchiroli wrote:
> Heya, sorry for the delay!
> 

no worries :)

> 
> 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.
> 


So the thing is that when providing the summary of a package we have:

- File delta
- description

Taking https://sources.debian.net/patches/summary/gnubg/1.05.000-3/ the
idea is having a json object like (not with the name file_deltas am
sorry that was wrong):

{
	description: "------"
	file-delta: {
		'eval.c': '10 6 + 4 - 0 !',
		'util.h': '3 3 + 0 - 0 !',
		summary: '2 files changed, 9 insertions(+), 4 deletions(-)'
	}

}

Well pfff i am not sure if this is really needed. It is just to avoid
parsing all the patches for these informations on the fly on each
request. Its not that it is slow to do it on the fly. Do you think it is
better not to do it? In this case i think this table is not needed at all.


>> 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.
> 

ack agreed, a separate table is better

>> 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...
> 

Ok good for me as well


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/qa-debsources/attachments/20160121/ead6ceaf/attachment.sig>