Re: Experiment to gather information about prospective packages (Was: [Blends-commit] r3275 - /blends/trunk/machine_readable/fetch-machine-readable)
On Sat, Apr 21, 2012 at 12:58:27PM +0900, Charles Plessy wrote:
> I have started to use the header License field of the machine-readable
> copyright format,
> to attempt to summarise the license of a package as a whole.
> Since we are gathering the copyright files, I hope it can help to move more
> meta-information out of the tasks files. Writing license summaries is not that
> easy, and I am not entirely sure what is the consequence when being wrong, but
> provided that in doubt we simply refrain from writing something, I think that
> it would be a good next target after the bibliographic information is under
The only datum I currently want to draw from these files is the License
field (short name!) from the "Files: *" section. As I also said I'm
interested in *not* *yet* released packages - because this is
information I would like to replace in the Blends tasks files.
> I see that you also have interest in the source package control files. I think
> that it would be indeed a good idea to have them. It would also make the
> metadata repository more self-contained, as these files contain the VCS URLs
> needed to refresh themselves and the other files. In that sense, I do not
> think that we would need an additional file to indicate the VCS URLs, but
> rather simply fix them in the source package's VCS and in the medatada
> repository in case of unresolvable mismatch.
I get the Vcs-Data in the most direct way you might imagine: I'm
actually browsing the Vcs repositories of the Blends teams and thus I
*know* the Vcs fields in advance. My plan is to issue warnings about
impropely set Vcs fields in the debian/control file rather than trusting
them. In short: I'm currently experimenting with some QA means of those
packages that are not yet released and some simplification of the tasks
files. I'm not sure where this experiment will end and I'm not in a
status where it is worth reporting about things which might end up in a
failure. You asked me to report about it and so I did, but please do
not overestimate this tiny bit of coding.
> I would like if possible to have more slow-paced prospective discussions,
> hopefully involving other persons than just the two of us, in order to
> better coordinate our efforts.
I admit I'd love to see more persons involved. However, it is hard to
force people into discussion. My goal is to find out whether I will be
able to replace a mentionable amount of information about prospective
packages in the tasks files by something I could gather automatically.
I'm also thinking about parsing WNPP bug reports. But all this is not
yet ripe to make much words about it before I know whether the effort
has some promising results. I do not intend to steal other peoples
time with some crazy idea of mine.