On Tue, Jun 23 2009, Jonathan Yu wrote:
> For me it just seems odd to add fields to d/control that aren't in
> policy, though your explanation makes sense to me.
Policy should be minimalistic. Is there any compelling reason
to pull this into policy?
>
> 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.
There was a lot of discussion
> I'll file a bug report against debian-policy sometime tomorrow, though
> I don't think this is something we can resolve without *much* further
> discussion.
Well, policy is not the place to do Design in. We
> I think given the stuff in the Developer Reference, we have a good
> head start on what to put in Policy for this field, but I'd like to
> see what discussion might have happened surrounding the Vcs fields in
> the first place, and build on that for policy. I think the Developer
> Reference is the closest we're going to get to a "proposed
> specification."
Please go look at the archives.
>
> It looks like the intent of having several fields for different Vcs
> mechanisms is that you can put several systems per package. So if you
> maintain your package in Svn and Git, you could have Vcs-Svn and
> Vcs-Git repositories for that.
You could. But hten you will have to have the discussion,
convince people to agree to the new design, get it into dev-ref, get
the tools patched, and _then_ come back with a compelling argument why
th enew design belongs in policy.
> It seems like it's reached the point where it's an ad-hoc standard and
> I think that makes it a reasonable candidate for inclusion into Debian
> Policy, though this might mean hammering out a clearer standard.
> Hopefully it follows the same fate as Homepage.
The homepage was not really changed before it went into policy;
it was an accepted practice, with a stable policy, by the time it was
included.
Policy is genrally is not the place to pull in new design.
manoj
--
Any man who hates dogs and babies can't be all bad. Leo Rosten, on
W.C. Fields
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
