[DEP 12] Why chosing YAML.

[Andreas Tille]

[sorry for full quote but I putted debtags-devel at lists.alioth.debian.org
 in CC to enable people there to confirm or object to my opinion about
 the difference between debian/upstream and debtags data.]

Hi,

On Sun, Jan 27, 2013 at 11:35:42AM +0900, Charles Plessy wrote:
> Le Sat, Jan 26, 2013 at 02:24:32PM +0100, Guillem Jover a écrit :
> > 
> > Although the more I think about it, given the context, the more I get
> > the impression that this data might not belong in the package anyway,
> > because most of the things it describes are more or less independent
> > of the source package, and because having it somewhere else, where the
> > maintenance could be shared with other distributions beside Debian
> > would be really nice. The only drawback would be not having the
> > information self-contained in the package itself, but there's
> > precedent for that too, like debtags. But then it feels like I'm
> > starting to repeat myself, so I think I'll leave this here.
> 
> Hi Guillem,
> 
> I started to work on debian/upstream with one design goal in mind: to be able
> to update the information without uploading a source package.  For this, we
> (where we is intitially the Debian Med team) need a place where people can add
> and modify information.  Also, if we want to propagate this information without
> much review, we need some access control.  Lastly, we need the system to be
> easy to use for the package maintainers, since we expect them to be the primary
> suppliers of information about their packages.
> 
> The solution I found was to store the information in debian/upstream and
> retrieve it from the VCS where the source package is stored.  For the moment it
> works well.  From the blends.debian.net machine (currently down),

It's a shame that this machine is down since two weeks - I can not reach
the sponsor of this box.  I'm planing a move as soon as possible.  It
would simplify the current discussion if we could better show the
current usage of debian/upstream files.

> using the
> umegaya package, we are collecting up-to-date debian/upstream files in a pool
> (which is made available to others through the collab-qa Subversion
> repository), and then custom scripts digest this and feed the UDD.  The UDD is
> the primary distribution point of the contents of the debian/upstream files,
> and the maintainers can update it trivially by commiting to their source
> package's VCS.
> 
>     http://wiki.debian.org/UpstreamMetadata
> 
> I completely agree that a cross-distro effort would be greater.

+1

> But it is
> completely beyond my skill, energy and free time to organise this.  But if
> something serious would emerge, I would be happy to throw away debian/upstream
> to the bin (after feeding the information we already collected) and use this.

Due to the currently existing structured information I'd consider it
quite easy to convert the exsiting data (I'm hesitating to phrase this
as "throwing away" ;-))

> Altogether, I would like to keep the question of the information flow for
> another DEP, and focus this one on the structure and syntax of the data...
> more on this in another thread. 
> 
> (And for debtags, I think that, while the current interface was instrumental
> in bootstraping the system,  I would manage my package's debtags better
> if they were in the source package.)

>From my perception there is a very big difference between DebTags and
the upstream data we are gathering:  In DebTags we need to agree upon a
structure of tags we want to use.  It is not clear from the beginning
what tags might make sense and what not.  As a consequence I regard the
current way to handle DebTags as sensible because there is some
collection point were the data is validated and observed whether there
is some need for changing the DebTags scheme.

For the upstream data we have a set of fields like Reference where there
is no uncertainty about the field and its content (well, we could
discuss what data of a usual reference record should be collected or not
but to change this it is just a Wiki edit and there is no discussion
about the name or the content of the field.)  Or other fields in itself
are quite clear and do not show any relation to other packages while
a DebTag makes only sense if you have a reasonable set of packages that
fits into the tagging.  So there is some kind of 1:1 relation between the
content of debian/upstream and the package source.

Under this circumstances from a maintenance point of view it makes sense
to attach the file directly to the source, specifically because we try
to make maintenance in VCS the default and thus the information is
actually available via web and thus available to other distributors.
However, I admit that if other distributors would really like to profit
from this effort some more central way to obtain and commit data would
be better.  (But as far as I know other distributors do also not try to
gain profit from DebTags.)

Kind regards

         Andreas.

-- 
http://fam-tille.de