Thoughts about the future of PET

[gregor herrmann]

On Thu, 04 Sep 2008 22:51:27 -0300, Martín Ferrari wrote:

> To put them on writing before my mind forgets something. :)

Good idea :)
 
> Regarding buildstat:
> As I said before, I think that now the post interesting and easy thing
> to do is to somehow access the build status and lintian reports, so
> those can be shown along the rest of the current information in pet.

Or more general: to have these informations in a central place where
other tools, like PET, can get and use them for showing.

> If we want to merge the two tools, we need to discuss what to keep
> from each. 

I guess each tool has several components: parts test thhings or
collect informations, parts store data, and parts use the stored data
for presentation. So the discussion should focus on what unique
information each tool creates and what's useful for presentation.

> I know Gonéri is interested in keeping the database schema,
> but if we're heading to use udd or something similar in the future,
> converting all the fuzzy and amorphous data structures of pet into
> buildstat schemas will be too much effort that will be discarded in
> the near future.

Ack, I think we should try to get everything into UDD.

What I don't know yet is how data gets into UDD; will it be possible
for "external" scripts to INSERT/UPDATE records in special tables or
does it "only" import some provided data by its own scripts or
something else?
 
> Regarding udd, ddpo and pet itself:
> pet is completely vcs-centric, that's why it can run everywhere. It's
> not tied to alioth, or any other debian machine. At the same time that
> impedes the merging with the other two.

Depends on the interaction between PET and UDD. If there is a defined
and easy way to get that from/about a repo into UDD the database can
replace PET's caching.

> In moving to something that's repository-wide, you have the problem of
> reaching personal repositories which aren't hosted in alioth, and may
> never be. 

Yup, that's one of the open questions.

> There's also the problem of mining data for packages that have no
> known repository. 

Well, if these packages don't have entries in UDD's repos_data table
then the presentation scripts leave this part out ...

> Other problems: you cannot reasonably process 10000 source packages in
> one run, different repositores can overlap while a package is being
> adopted (in pkg-perl there's about 100 packages which are adopted but
> not uploaded with the new maintainer set)

Newest mtime wins :)
 
> In any case, the flow would have to be completely rethought. I guess
> that breaking the code in many small "providers" would be the best
> option, the big question mark is in how to reach the many repositories
> out there.

2x ack!
 
> A problem that I see with udd is that it could result too rigid; a
> good thing of the horrible data structures that pet uses is that
> adding information is trivial. How do you think that UDD will evolve?

Hm, maybe the need to keep the data(base) structure more consistent
is not bad :)

> Also,. the data there still needs a lot of processing. Some other
> intermediate storage for pre-computed data would be needed. Remember
> that PET shows data in real time, it's very different to most other
> services in debian that prepare reports in batch.

Right, that's IMO _the_ awesome aspect of PET
 
Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-    NP: Supertramp: Take The Long Way Home
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pet-devel/attachments/20080905/17ecd478/attachment.pgp