On Thu, Jun 25, 2009 at 10:04:59PM -0700, Steve Langasek wrote:
On Thu, Jun 25, 2009 at 11:33:12PM +0100, Roger Leigh wrote:
I often have branches for:
- unstable
- experimental
- stable
- backports
and there may be others of course. Each of these may be branched
off the upstream
On Thu, Jun 25 2009, Raphael Hertzog wrote:
On Thu, 25 Jun 2009, Julien Cristau wrote:
On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
As far as branches are concerned, the default branch should point to
the debian packaging branch and that's it.
And how do you do that,
On Thu, 25 Jun 2009, Ben Finney wrote:
Vcs: git:http://git.debian.org/...
Vcs: svn:http://svn.debian.org/...
(This means that dpkg does not have to be updated for each new VCS).
I'm unaware of this issue. I was under the impression that dpkg can
simply handle fields transparently if
On Wed, 24 Jun 2009, Jonathan Yu wrote:
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
On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
If one is using a tool such as git-buildpackage, the debian and
upstream branches are the *minimum* required information however.
That sounds to me like a defect in git-buildpackage, then.
--
Steve Langasek Give me
On Thu, Jun 25, 2009 at 01:04:59AM -0700, Steve Langasek vor...@debian.org
wrote:
On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
If one is using a tool such as git-buildpackage, the debian and
upstream branches are the *minimum* required information however.
That sounds to
On Thu, Jun 25, 2009 at 01:04:59AM -0700, Steve Langasek wrote:
On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
If one is using a tool such as git-buildpackage, the debian and
upstream branches are the *minimum* required information however.
That sounds to me like a defect in
On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
As far as branches are concerned, the default branch should point to
the debian packaging branch and that's it.
And how do you do that, when the debian and upstream repos are the same?
That seems to be a fairly arbitrary
On Thu, 25 Jun 2009, Julien Cristau wrote:
On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
As far as branches are concerned, the default branch should point to
the debian packaging branch and that's it.
And how do you do that, when the debian and upstream repos are the
On Thu, Jun 25, 2009 at 01:49:17PM +0200, Raphael Hertzog wrote:
On Thu, 25 Jun 2009, Julien Cristau wrote:
On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
As far as branches are concerned, the default branch should point to
the debian packaging branch and that's it.
On Thu, 25 Jun 2009, Steve Langasek wrote:
On Thu, Jun 25, 2009 at 01:49:17PM +0200, Raphael Hertzog wrote:
On Thu, 25 Jun 2009, Julien Cristau wrote:
On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
As far as branches are concerned, the default branch should point to
Raphael Hertzog hert...@debian.org writes:
As far as branches are concerned, the default branch should point to
the debian packaging branch and that's it. Then if you have the need
to encode more about how the repo is used, it should be somewhere in a
supplementary file in debian/source/. And
Steve Langasek vor...@debian.org writes:
On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
If one is using a tool such as git-buildpackage, the debian and
upstream branches are the *minimum* required information however.
That sounds to me like a defect in git-buildpackage, then.
On Thu, Jun 25, 2009 at 01:49:17PM +0200, Raphael Hertzog wrote:
On Thu, 25 Jun 2009, Julien Cristau wrote:
On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
As far as branches are concerned, the default branch should point to
the debian packaging branch and that's it.
On Thu, Jun 25, 2009 at 11:33:12PM +0100, Roger Leigh wrote:
I often have branches for:
- unstable
- experimental
- stable
- backports
and there may be others of course. Each of these may be branched
off the upstream stable/development branches at the appropriate
points. This allows
Jonathan Yu jonathan.i...@gmail.com writes:
For me it just seems odd to add fields to d/control that aren't in
policy, though your explanation makes sense to me.
Debian policy is, ideally, descriptive instead of proscriptive. In other
words, it (ideally) changes only in response to
Hi!
On Tue, 2009-06-23 at 21:02:53 -0700, Russ Allbery wrote:
I don't remember if there's a bug filed asking for inclusion of the
Vcs-* fields already. If there isn't and you feel like tracking this
down, a bug that has a pointer to the specification would be great, or a
proposed
On Jun 24, 2009, at 8:22, Ben Finney wrote:
Jonathan Yu jonathan.i...@gmail.com writes:
For me it just seems odd to add fields to d/control that aren't in
policy, though your explanation makes sense to me.
Debian policy is, ideally, descriptive instead of proscriptive. In
other
words,
On Wed, Jun 24, 2009 at 04:22:48PM +1000, Ben Finney wrote:
Jonathan Yu jonathan.i...@gmail.com writes:
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.
What's
On Wed, Jun 24, 2009 at 01:44:10PM +0200, Bill Allombert wrote:
On Wed, Jun 24, 2009 at 04:22:48PM +1000, Ben Finney wrote:
Jonathan Yu jonathan.i...@gmail.com writes:
I don't really think that each version control system should have its
own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc,
Roger:
I'm happy to see everyone discussing this, and ways to future proof
the idea, though I suppose dpkg will need to continue supporting the
old Vcs-* style tags in any case, at least for some transitional
period, since they have become a bit of an ad-hoc standard. I'd like
to see them
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
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
On Wed, Jun 24 2009, Roger Leigh wrote:
This, or some similar scheme, would certainly be more future proof.
One additional thing I'd like to raise is the need for additional
metadata to make better use of the VCS repository:
- upstream branch
- debian branch
- possibly additional
Manoj Srivastava sriva...@debian.org writes:
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
On Wed, Jun 24, 2009 at 01:50:20PM +0100, Roger Leigh wrote:
One additional thing I'd like to raise is the need for additional
metadata to make better use of the VCS repository:
- upstream branch
- debian branch
- possibly additional branches e.g. upstream stable/development
branches,
On Wed, Jun 24, 2009 at 04:38:27PM -0400, Steve Langasek wrote:
On Wed, Jun 24, 2009 at 01:50:20PM +0100, Roger Leigh wrote:
One additional thing I'd like to raise is the need for additional
metadata to make better use of the VCS repository:
- upstream branch
- debian branch
-
Hi:
I'm curious if I missed something in the policy manual that mentioned
paragraphs which are unknown. I find no mention of the Vcs-* fields
but I don't know if they're supposed to just be copied as-is. I've
seen the stuff on X-Comments and all the rules for X[BS]*- stuff, but
not the Vcs- stuff
On Wed, Jun 24, 2009 at 12:02 AM, Russ Allberyr...@debian.org wrote:
Jonathan Yu jonathan.i...@gmail.com writes:
I'm curious if I missed something in the policy manual that mentioned
paragraphs which are unknown. I find no mention of the Vcs-* fields
but I don't know if they're supposed to
On Wed, 2009-06-24 at 00:17 -0400, Jonathan Yu wrote:
Should this be something in the policy itself?
I think so. But in general Policy doesn't document every possible
field, only the ones with Policy significance. dpkg from time to time
adds additional informational fields without
30 matches
Mail list logo
