Re: Status bibref gatherer (Was: Tasks pages (close to) fixed; Bibref does not seem to be updated automatically)

[Charles Plessy <plessy@debian.org>]

Hi again,

I am really frustrated.  You pointed at problems, I worked to solve them, and
now you come again and again with the same story that the system is not
reliable.  Please remember that 1) the bugs you report can be fixed and 2) no
program is ever prefect from the first release.

It is the same program that generates the YAML file at
http://upstream-metadata.debian.net/~plessy/biblio.yaml and that
generates the pool of debian/upstream files.  If you trust the pool,
trust the the YAML file.  And if its content is not enough or if you
prefer another format, why not clearly writing down what you need exactly
for the UDD, instead of immeditely forking the system ?

I agreed to provide a pool for everybody, and did not agree to anything else.
And I am not going to provide the pool any longer if as a consequence I lose my
word to say about the system that I have started.

I wrote a spec that has been available at http://wiki.debian.org/UpstreamMetadata
for three years.  That spec lists fields, and their contents, and indicates
that they are YAML fields.  Perhaps it is not clear enough that they
are all scalar fields ?

Introducing arrays or hashes is a big change, and I do not want to make it in a
rush as it is happening now.  And I do not accept your arguments implying that,
since the UDD is universal, there is no need to even think about parallel
systems.  For example, among the feedback I had on the debian/upstream files,
there was the export of the data in semantic web formats.  If your opinion is
that any of such attempts has to go through the UDD instead, please convince
by yourself the people who made this suggestion; it is not my opinion.

This thread is exhausing me completely.  I will not do more development until
we reach an agreement.  And please, let's try to advance on the issues one at a
time.  Point-to-point answers are confrontational, divertive and unfocusing.

We need:

 0) To agree on the syntax of the debian/upstream file in general.  As I have
    specified them, they are a collection of field - value statements, similarly
    to Debian control data files.  Hashes or arrays are not supported.  What
    uses YAML there is that, in contrary to Debian control files, it is
    not necessary to specify if each field is single-line multi-line or folded.
    YAML provides direct support through quotes and the ">" and "|" operators
    
    I propose to revert the current ambiguous notations and use field names such as
    Reference-Author, Reference-PMID, etc., as described on the spec at
    http://wiki.debian.org/UpstreamMetadata .  In any case, let's fix the
    spec first before it confuses more people.

 1) To agree how to represent the bibliographic data in the debian/upstream files.
    You proposed to introduce the concept of "rank", and I objected that it
    complicates the syntax.  How do you plan to use the ranks when preparing
    the Blends tasks pages ?  If a package contains two programs described
    in two articles, to which will we give a rank of zero ?  Currently, we
    are not supporting this situation either when injecting the bibliography
    on the tasks files.  I propose a) to keep the Reference-* fields as they
    are, b) to use the References field to indicate an URL when the instructions
    for picking the appropriate article to cite are complicated and c) to
    have the extra references in a separate file unless we really have a solid
    strategy to display them in the Blends tasks pages.

 2) To agree how the information flows from the debian/upstream files to the UDD.
    If you propose that you do everything by yourself, great.  Otherwise, we
    need to make concessions.

Let's agree on 0) first.  I can repeat my arguments for 1) and 2) later.  I
would really prefer if we do not discuss too many issues in parallel.

Cheers,

-- 
Charles