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

[Raphael Hertzog <hertzog@debian.org>]

On Tue, 21 Oct 2008, Jari Aalto wrote:
> This does not prevent them from being documented in "Best ractises" for
> future use.

I don't agree that it is a good practice.

> 1) Keeping upstream information up-to-date is a goal for every package.

We have to keep Homepage and copyrigth up-to-date, for the rest you
propose adding that as a supplementary goal.

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

Yes but those tools can also be developed if the information is available
somewhere else than in the package itself.

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

Indeed, and this is wasted time when the person filing the bug could have
gone to the CRMI website and filled the infos by himself.

> 4) it improves transparency between all parties; developers and people
> needing the information. You can simply:
> 
>          apt-cache show <package>

Aptitude already downloads the changelog when it wants to display it, the
same could be done for any information stored in CRMI.

You propose to clutter even more Packages/Sources files whent they are big
enough already.

> 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.

It is still a problem: not up-to-date information means wrong information.
When you design something you try to avoid unnecessary delays and you aim
for the best.

> 1) someone has to remember "where was that place again"
> 2) It's inconvenient. Jump to another place? Use web interface?

No, the data collected would be transparently used by other applications,
the website is mainly meant to update data not to consult it.

> 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?

and what's the problem here ? you also add debtags through an external
place precisely so that people other than the maintainers can help.
It's a benefit not a loss.

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

I can assure you it's unrelated. We have non up-to-date copyright files
and watch files in Debian package and we have up-to-date debtags outside
of Debian packages.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/