On Wed, Jun 24 2009, Andrew McMillan wrote:
> Not at all. There is experimentation in advance of acceptance in this
> case, and I really don't believe that the overhead of sending every
> wacky proposal through policy before allowing it to be in the control
> file would not help the development of new features.
True. And the experiment came up with a widely accepted
behaviour, which seems to be accepted by other tools (the PTS et al).
>> > proposed specification. For Lintian, we had trouble finding
>> > documentation for what the contents should be for some cases,
>> > particularly Vcs-Mtn.
>> >From the Developer's Reference, Vcs-Mtn refers to the mtn (Monotone)
>> version control system.
>>
>> I don't really think that each version control system should have its
>> own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not
>> very future proof in my opinion. On the other hand we've got
>> situations where there are lots of Version Control systems that use
>> HTTP and WebDAV (like SVN via http://) so it's hard to detect what
>> type of repository something is simply given the URL.
>
> I tend to agree, though in reality we essentially do have a two-part
> identifier, and if we define it as such there is no reason why we can't
> say that the field is 'Vcs-' + vcs-type + ':' + vcs-url, and future
> proof it by allowing the list of vcs-types to be defined outside of
> policy.
In this case, if y'all are going to change the practice, you
should again do so in the dev-ref, and come to policy when the
shiny new design has been deployed, and the tools fixed to match.
Until then, it is not yet ready for policy standardization.
manoj
--
The perpetual obstacle to human advancement is custom. -- John Stuart
Mill
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
