Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-06 Thread Andreas Tille
On Tue, Feb 02, 2016 at 05:38:05PM +, Jonathan Dowland wrote: > I must say that I do not like this proposal. The current situation does result > in under-maintained packages requiring churn, but that's true for many aspects > of them, not least their policy version. It's a good indicator of

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-05 Thread Wouter Verhelst
On Thu, Feb 04, 2016 at 06:54:08PM +, Niels Thykier wrote: > I appreciate this idea and effort. Unfortunately, this is the type of > information we want in the *source* package (at least AFAICT), and to my > knowledge you cannot use substitution variables in those. This surprised me[1], so I

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-04 Thread Andreas Tille
Hi, On Thu, Feb 04, 2016 at 02:21:06PM +0100, Wouter Verhelst wrote: > > Right. So something like... > > debian/control: > Vcs-Git: ${vcs:repo} > Vcs-Browser: ${vcs:browser} > > debian/vcs: > Vcs-Type: Git > Vcs-Host: Debian > Vcs-Path: / > > debian/rules: > override_dh_gencontrol: >

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-04 Thread gregor herrmann
On Thu, 04 Feb 2016 18:54:08 +, Niels Thykier wrote: > Andreas Tille: > > On Thu, Feb 04, 2016 at 02:21:06PM +0100, Wouter Verhelst wrote: > >> > >> Right. So something like... > >> > >> debian/control: > >> Vcs-Git: ${vcs:repo} > >> Vcs-Browser: ${vcs:browser} > >> > >> debian/vcs: > >>

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-04 Thread Wouter Verhelst
Hi Andreas, On Sun, Jan 31, 2016 at 08:59:57AM +0100, Andreas Tille wrote: > Well, debcheckout is not accessing debian/control files of single > packages. My suggestion was obviously not clear enough. We certainly > should keep the old known fields in Packages files etc - but these > should be

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-04 Thread Niels Thykier
Andreas Tille: > Hi, > > On Thu, Feb 04, 2016 at 02:21:06PM +0100, Wouter Verhelst wrote: >> >> Right. So something like... >> >> debian/control: >> Vcs-Git: ${vcs:repo} >> Vcs-Browser: ${vcs:browser} >> >> debian/vcs: >> Vcs-Type: Git >> Vcs-Host: Debian >> Vcs-Path: / >> >> debian/rules: >>

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-03 Thread Guillem Jover
Hi! On Tue, 2016-02-02 at 20:23:08 +, Simon McVittie wrote: > On 02/02/16 17:38, Jonathan Dowland wrote: > > I must say that I do not like this proposal. The current situation does > > result > > in under-maintained packages requiring churn, but that's true for many > > aspects > > of them,

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-02 Thread Simon McVittie
On 02/02/16 17:38, Jonathan Dowland wrote: > I must say that I do not like this proposal. The current situation does result > in under-maintained packages requiring churn, but that's true for many aspects > of them, not least their policy version. It's a good indicator of which > packages need

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-02 Thread Jonathan Dowland
I must say that I do not like this proposal. The current situation does result in under-maintained packages requiring churn, but that's true for many aspects of them, not least their policy version. It's a good indicator of which packages need some attention. That's not what I dislike about the

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-02-01 Thread Debian/GNU
On 01/31/2016 10:47 AM, Jonas Smedegaard wrote: > > Instead of introducing new flags, I suggest to extend existing flags to > support "relative URLs" which are somewhere within Debian. > > E.g. [...] > > Vcs-Git: pkg-perl/packages/ciderwebmail > yes please. i very much liked andreas'

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-01-31 Thread Andreas Tille
On Sun, Jan 31, 2016 at 08:20:20AM -0200, Tiago Ilieve wrote: > On 31 January 2016 at 07:47, Jonas Smedegaard wrote: > > Instead of introducing new flags, I suggest to extend existing flags to > > support "relative URLs" which are somewhere within Debian. > > > > E.g. the

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-01-31 Thread Andreas Tille
On Sun, Jan 31, 2016 at 08:51:55AM +0100, Geert Stappers wrote: > > Yes, it makes sense > to have a both Vcs-{Git|Svn|...} and a separate Vcs-Browser field. > > Keep the possibility to copy-and-paste an VCS-URL for "manual checkout" > > Keep a working Vcs-Brower URL. Because: > * site admin is

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-01-31 Thread Jonas Smedegaard
Quoting Andreas Tille (2016-01-31 12:53:11) > over time I have seen several changes in the values we should put in > to Vcs-* fields. The latest one is s/http:/https:/. While using > config model editor helps a lot to follow those changes we will > probably see more and more packages inside

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-01-31 Thread Tiago Ilieve
On 31 January 2016 at 07:47, Jonas Smedegaard wrote: > Instead of introducing new flags, I suggest to extend existing flags to > support "relative URLs" which are somewhere within Debian. > > E.g. the following: > > Vcs-Git: git://anonscm.debian.org/pkg-perl/packages/ciderwebmail

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-01-30 Thread Geert Stappers
On Sun, Jan 31, 2016 at 08:23:11AM +0100, Andreas Tille wrote: > Hi, > > over time I have seen several changes in the values we should put in to > Vcs-* fields. The latest one is s/http:/https:/. While using config > model editor helps a lot to follow those changes we will probably see > more

Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

2016-01-30 Thread Andreas Tille
Hi, over time I have seen several changes in the values we should put in to Vcs-* fields. The latest one is s/http:/https:/. While using config model editor helps a lot to follow those changes we will probably see more and more packages inside the archive that never changed but start