[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#502923: developers-reference: Add new Upstream-* fields for Bts, Upstream-Vcs-Browser, Upstream-Vcs-{Git, Hg, Svn) ...



Raphael Hertzog <hertzog@debian.org> writes:

> On Tue, 21 Oct 2008, jaalto wrote:
>>
>>      Upstream-Bts-Url
>>      Upstream-Vcs-Browser
>>      Upstream-Vcs-*          --''--
>
> Those fields are not accepted by dpkg contrary to the Vcs-* ones. So they
> shouldn't be documented IMO.

This does not prevent them from being documented in "Best ractises" for
future use.

> And I don't like the idea to clutter the control file

1) Keeping upstream information up-to-date is a goal for every package.
And these changes are rare and permanent anough to deserve field.

2) it allow developing tools; similar to debcheckout(1)

3) it allow filing bugs: wishlist to add upstream information, bug to
report that information is out of date.

4) it improves transparency between all parties; developers and people
needing the information. You can simply:

         apt-cache show <package>

to see what you need and quickly access what you want.

> with such upstream information which always require an upload for any
> update/change.

That is not a problem. Not even currently developers upload packages
every time e.g. "Standards-Version" changes. Updates happen naturally;
when new upstream arrives or chnages have accumulated.

> meta-information about source packages: http://wiki.debian.org/CRMI

While it sounds nice, I see problems:

1) someone has to remember "where was that place again"
2) It's inconvenient. Jump to another place? Use web interface?
2) The information is kept *separate* from the place where package is
   being developed. New developer and transfer of package related "other
   issues" that are kept somewhere else?

Separation of information is always bad and leads to "non up-to-date"
syndrom, "problems in knowledge sharing" when package change hands.

INSTEAD

It should be the other way round. The developers keep the packages up to
date as their workflow. The information is already stored in

   debian/control
   debian/copyright

Any extra place is extra work. We should also remember this:

  http://wiki.debian.org/Proposals/CopyrightFormat

SUMMARY

  Automated tools can extract the information to other places like
  http://wiki.debian.org/CRMI

Jari



Reply to: