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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120311120430.ga11...@falafel.plessy.net