Is Vcs-Browser necessary? [was: Why Vcs-* fields are not at least recommended ?]

[Gordon Ball <gordon@chronitis.net>]

Related question: is it useful (in most cases) to recommend having
Vcs-Browser where Vcs-* is also provided?

As the parent noted, policy doesn't make any strong recommendation here,
as to whether any Vcs-* field should be present or whether Vcs-Browser
should be present also, however lintian does make it a recommendation:

    I: missing-vcs-browser-field

In the most common case (git, salsa, https, default branch), the same
URI will work perfectly well both for both browse and clone (either
with or without the .git suffix). Most packages set the fields like
(random example):

    Vcs-Git: https://salsa.debian.org/apt-team/apt.git
    Vcs-Browser: https://salsa.debian.org/apt-team/apt

Allowing an explicit Vcs-Browser field for unusual cases seems
reasonable, but perhaps we could make the implicit assumption that if

    1) Vcs-* uses scheme https:
    2) Vcs-Browser is not present

then the Vcs-* URI can be assumed to be browsable, and save some
unnecessary duplication in d/control.

Gordon

On Tue, Aug 18, 2020 at 11:10:04PM +0200, Alexis Murzeau wrote:
> Hi,
> 
> 
> I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or Vcs-<type>)
> are not recommended (or maybe even strongly recommended) ? (I mean here that I think
> having Vcs-* fields should be recommended for active packages)
> 
> 
> There is no lintian tag for missing Vcs-* fields (not even a low severity one,
> but I don't know if it's because of lack of interest or because of the policy).
> 
> Maybe the fact that we still have the package' source tarballs for each
> released version is enough, but this loose the VCS history and ongoing work in
> case someone else wants to contribute too.
> 
> I acknowledge that previously, packages might not have been developed using
> a VCS as said in the policy. But I think now most packages have a VCS where
> it is developed.
> 
> 
> Also, I see some orphaned packages in the QA group now actively maintained
> without VCS, which seems counterproductive if someone else wants to contribute
> too.
> In that case, this would be almost like a NMU I guess, but against an
> "non official maintainer" with manual merges (or lost changes).
> 
> Or maybe orphaned package with QA upload are not supposed to be always
> collaboratively maintained ? (I'm new to these concepts, but to me the
> response to this should be "no").
> 
> 
> What do you think about actively developed packages without Vcs-* fields ?
> 
> 
> -----
> Note: I've checked if it was already discussed before on -devel or -policy but did
> not find anything relevant for this exact subject.
> If there is still something somewhere, I would be happy to read it :)
> 
> -- 
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
>