* Ron [141119 07:21]:
> I believe Bernhard explained earlier that git-dpm allows the replacement
> character to be configurable (but also offers just a single character
> for all replacements).
git-dpm doesn't have a replacement-character configurable, but different
control sequences for the vari
On Wed, Nov 19, 2014 at 03:41:12PM +, Ian Jackson wrote:
> Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > As I explained in the earlier discussion with Henrique, there are more
> > things than just : and ~ which are perfe
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> As I explained in the earlier discussion with Henrique, there are more
> things than just : and ~ which are perfectly legal in debian version
> strings, but are illegal constructs in git refnam
On Tue, 18 Nov 2014 21:17:15 -0500, James McCoy wrote:
> > Guido Günther writes ("Re: RFC: DEP-14: Recommended layout for Git
> > packaging repositories"):
> > > This didn't work well so gbp switched to what Raphael documented years
> > > ag
Ian wrote:
> Guido Günther writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
> > > Current practice seem so be to replace both : and ~ with _. Unless
> > >
On Tue, Nov 18, 2014 at 04:24:30PM +, Ian Jackson wrote:
> Guido Günther writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
> > > Current practice seem so be to repla
Guido Günther writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
> > Current practice seem so be to replace both : and ~ with _. Unless
> > we
>
> This didn't work
On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
> Bernhard R. Link writes ("Re: RFC: DEP-14: Recommended layout for Git
> packaging repositories"):
> > Raphael Hertzog [14 22:26]:
> ...
> > > When a Git tag needs to refer to a specific vers
On Mon, Nov 17, 2014 at 11:39:10PM +, Simon McVittie wrote:
> On 17/11/14 16:24, Ian Jackson wrote:
> > I don't think this problem, of a mass of different branch structures,
> > is going to go away any time soon. Simply because people don't seem
> > able to agree.
I agree it's unlikely to go
On 18/11/14 07:20, Guido Günther wrote:
> Note that nothing withing gbp forces you to use gbp-pq.
I know; but the gbp-pq-like repository structure, as produced by git
import-dsc with no special options, is a popular one (pkg-perl and their
> 3000 packages, as well as smaller teams like -telepathy,
On Sat, Nov 15, 2014 at 06:35:07PM +, Simon McVittie wrote:
[..snip..]
> with upstream changes - and try packaging them with each of gbp-pq,
Note that nothing withing gbp forces you to use gbp-pq. You can use
e.g. use
--no-unapply-patches
--auto-commit
--single-debian-patch
in your debian/so
On Fri, Nov 14, 2014 at 11:35:45AM +0100, Marco d'Itri wrote:
> On Nov 14, Raphael Hertzog wrote:
>
> > This is just a proof that storing the patches as real commits is useful.
> > And that's the point of the patch-queue tag. Instead of having the patches
> > only as real commits in the local rep
Hi Raphael,
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote:
[..snip..]
> Problem 1: the derivatives
> --
>
> So I am a Kali Linux contributor. We use git repos to maintain all our
> packages and we use git-buildpackage. Most of the Kali contributors
> are n
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> As far as I can see from what you've said elsewhere, for source format
> 3.0 (quilt), you're aiming for the "patches applied and also serialized
> in debian/patches
On 17/11/14 16:24, Ian Jackson wrote:
> I don't think this problem, of a mass of different branch structures,
> is going to go away any time soon. Simply because people don't seem
> able to agree.
>
> My answer is to create a parallel universe in which the branch
> structure is known.
As far as
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> gbp-pq and git-dpm are the other way round: the tree can be built with
> dpkg-buildpackage, but the cost is that you have to commit in a way that
> isn't the normal git thing
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> I agree that the expected contents of the branches are far more
> important than their names. Unfortunately, while acting as "the Debian
> expert" for Debian derivative
On Mon, 17 Nov 2014, Ron wrote:
> > Anything that doesn't store the full debian version (be it a git tag or a
> > filename) will have a colision risk. Consider a package that has versions
> > 1:2.3.5-1 and 5:2.3.5-1.
>
> Right, that was one of the first cases I mentioned. When you upload
> 5:2.3
On Sun, Nov 16, 2014 at 07:33:32PM +1030, Ron wrote:
> On Sat, Nov 15, 2014 at 06:15:33PM +, Simon McVittie wrote:
> > On 12/11/14 22:07, Ron wrote:
> > > I am also interested to hear more
> > > about whatever the confusion was you had with this was when you
> > > started working with Tollef's
On Sun, Nov 16, 2014 at 02:03:23PM -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 16 Nov 2014, Ron wrote:
> > On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
> > > On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> > > > On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > > >
On Sun, 16 Nov 2014, Ron wrote:
> On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
> > On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> > > On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > > > What exactly is your use case you feel this is essential for?
> > > >
> > > > I thi
On Sat, Nov 15, 2014 at 06:35:07PM +, Simon McVittie wrote:
> On 13/11/14 14:04, Ron wrote:
> > I really do think that the names of the branches are actually going to
> > be the least of your worries here, unfortunately. Even with a naming
> > scheme that's widely adopted, things just aren't g
On Fri, 14 Nov 2014, Thorsten Glaser wrote:
> On Fri, 14 Nov 2014, Ian Jackson wrote:
>
> > expect to find version numbers matching ^\d+\~, then anything matching
>
> These are common enough for me to have not only seen,
> but also used (in native packages, of course) them.
Not only in native pa
On Sat, Nov 15, 2014 at 06:15:33PM +, Simon McVittie wrote:
> On 12/11/14 22:07, Ron wrote:
> > I am also interested to hear more
> > about whatever the confusion was you had with this was when you
> > started working with Tollef's systemd repo that you mentioned
> > in the previous thread.
>
On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> > On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > > What exactly is your use case you feel this is essential for?
> > >
> > > I think this discussion is in danger of going rou
Simon McVittie writes:
> Having played with gitpkg some more, I'm reminded that the answer to
> this is that unlike (AIUI) both gbp-pq and git-dpm, it did not meet my
> assumption that the contents of the git tree were in a suitable form to
> run dpkg-buildpackage and have a 3.0 (quilt) Debian pac
On 13/11/14 14:04, Ron wrote:
> I really do think that the names of the branches are actually going to
> be the least of your worries here, unfortunately. Even with a naming
> scheme that's widely adopted, things just aren't going to be that sort
> of uniform outside of (a fairly large number of)
On 12/11/14 22:07, Ron wrote:
> I am also interested to hear more
> about whatever the confusion was you had with this was when you
> started working with Tollef's systemd repo that you mentioned
> in the previous thread.
Having played with gitpkg some more, I'm reminded that the answer to
this is
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > What exactly is your use case you feel this is essential for?
> >
> > I think this discussion is in danger of going round in circles.
> > I'm going to leave it here and let Raphael get on with it.
>
> I un
On Sat, 15 Nov 2014 18:02:23 +0100, Raphael Hertzog wrote:
> Unless you want to suggest a specific standardized name for a NMU patch
> branch... but this does seem a bit premature given that nobody is
> currently doing stuff like that. The few persons that I saw commit their
> NMU to git just used
On Fri, 14 Nov 2014, Ian Jackson wrote:
> > What exactly is your use case you feel this is essential for?
>
> I think this discussion is in danger of going round in circles.
> I'm going to leave it here and let Raphael get on with it.
I understand Ron's logic and there's certainly value in questi
On Fri, 14 Nov 2014, Ian Jackson wrote:
> Richard Hartmann writes ("Re: RFC: DEP-14: Recommended layout for Git
> packaging repositories"):
> > Can you at least suggest, not require, that the NMUer should also send
> > a link to a publicly available branch with the p
Hi,
Bernhard R. Link:
> I think such a document would do well to not say much about upstream
> branches or imply how they should be managed.
>
It is helpful to base the Debian release on an Upstream release that is
actually tagged by Upstream, provided that the version thus tagged is the
basis fo
* Raphael Hertzog [141114 12:34]:
> On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> > * Raphael Hertzog [14 22:26]:
> > > Helper tools should usually rely on the output of `dpkg-vendor --query
> > > vendor`
> > > to find out the name of the current vendor. The retrieved string must be
> > > c
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Right, and like you already noted, there's potential for ambiguity
> in tag names anyway once the illegal characters have been mangled.
Raphael is proposing an unambiguous mangling which de
On Fri, 14 Nov 2014, Henrique de Moraes Holschuh wrote:
> The BTS needs it: it is the very base of version-aware bug state
> tracking. It builds the DAG by combining the DAGs extracted from the
> Debian changelogs of each branch of the package, AFAIK.
Speaking of which, one of the long standing id
On Fri, Nov 14, 2014 at 05:43:49PM +, Ian Jackson wrote:
> Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > Right, gitweb, cgit, gitk, etc. are all going to do exactly the same
> > thing, take them from the DAG of the repo
Hi,
Ian Jackson:
> Worse, unless I'm mistaken, there are some current workflows which
> involve subsequent uploads to the same suite not necessarily being
> fast forwards.
>
Meh. Anybody whose upload depends on being able to force-push a branch
deserves to lose. (I'm talking about the general cas
Hi,
Henrique de Moraes Holschuh:
> > That said I did consider that side of it too, but I'm having a hard
> > time thinking of an example where you would actually care about
> > ordering the tags for some task. Do you have one that comes to mind?
>
> The BTS needs it: it is the very base of versi
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Right, gitweb, cgit, gitk, etc. are all going to do exactly the same
> thing, take them from the DAG of the repo. They are unlikely to care
> about how the tag names would textually sort (and
Thorsten Glaser writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> On Fri, 14 Nov 2014, Ian Jackson wrote:
> > expect to find version numbers matching ^\d+\~, then anything matching
>
> These are common enough for me to have not only seen,
&
Richard Hartmann writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Can you at least suggest, not require, that the NMUer should also send
> a link to a publicly available branch with the patch(es) which are
> based on the packaging branch's
On Fri, Nov 14, 2014 at 03:13:30PM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 15 Nov 2014, Ron wrote:
> > On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
> > > Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> > > reposit
On Fri, 14 Nov 2014, Richard Hartmann wrote:
> On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog wrote:
> > On Thu, 13 Nov 2014, Tobias Frost wrote:
> >> One point came to my mind: NMUs
> >> Can we maybe add some words what would be best practice to handle NMUs?
> >
> > I think the current best pr
On Sat, 15 Nov 2014, Ron wrote:
> On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
> > Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> > repositories"):
> > > Why include the epoch in tags at all?
> >
> > Because we
On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog wrote:
> On Thu, 13 Nov 2014, Tobias Frost wrote:
>> One point came to my mind: NMUs
>> Can we maybe add some words what would be best practice to handle NMUs?
>
> I think the current best practices are fine: the NMUer should send a
> debdiff to th
On Fri, 14 Nov 2014, Ian Jackson wrote:
> expect to find version numbers matching ^\d+\~, then anything matching
These are common enough for me to have not only seen,
but also used (in native packages, of course) them.
(But: Yes, epochs should belong into filenames, except
for filesystem naming
On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
> Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > Why include the epoch in tags at all?
>
> Because we want to be able to tell not just which tag was which but
&
Bernhard R. Link writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Raphael Hertzog [14 22:26]:
...
> > When a Git tag needs to refer to a specific version of a Debian package,
> > the Debian version needs to be mangled to cope with Gi
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Why include the epoch in tags at all?
Because we want to be able to tell not just which tag was which but
also what order they are in.
The only reason I excluded epoch from filenames is that it mak
Raphael Hertzog wrote:
> On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> > * Raphael Hertzog [14 22:26]:
>
> > Is using the vendor you use git on a good default for the vendor code
> > you are currently working on? In my experience those two are quite
> > unrelated.
>
> Do you have a better d
On Fri, Nov 14, 2014 at 11:25:36AM +0100, Raphael Hertzog wrote:
> On Fri, 14 Nov 2014, Ron wrote:
> > > So I am a Kali Linux contributor. We use git repos to maintain all our
> > > packages and we use git-buildpackage.
> >
> > I guess the first question there is what were the arguments put forwar
On Nov 14, Raphael Hertzog wrote:
> This is just a proof that storing the patches as real commits is useful.
> And that's the point of the patch-queue tag. Instead of having the patches
> only as real commits in the local repository, they get pushed to the
> public repository too under that tag (
On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> * Raphael Hertzog [14 22:26]:
> > Helper tools should usually rely on the output of `dpkg-vendor --query
> > vendor`
> > to find out the name of the current vendor. The retrieved string must be
> > converted to lower case. This allows users to ov
On Thu, 13 Nov 2014, Tobias Frost wrote:
> One point came to my mind: NMUs
> Can we maybe add some words what would be best practice to handle NMUs?
I think the current best practices are fine: the NMUer should send a
debdiff to the BTS. Maybe the patch doesn't apply on top of the
supplementary ch
On Fri, 14 Nov 2014, Ron wrote:
> > So I am a Kali Linux contributor. We use git repos to maintain all our
> > packages and we use git-buildpackage.
>
> I guess the first question there is what were the arguments put forward
> for deciding to 'standardise' on gbp? If there wasn't one, maybe that'
On Wed, Nov 12, 2014 at 4:04 AM, Marco d'Itri wrote:
> Whatever the decision will be on debian/master, I think that master
> should be at the very least an option.
I.e. a debian-only repo? That's what pabs also seems to prefer so it
probably makes sense to support/allow both.
FWIW, I strongly di
On Tue, Nov 11, 2014 at 10:51 PM, Henrique de Moraes Holschuh
wrote:
> Please allow debian/master as an alternative. It fits with the general git
> usage of "master", it fits with the workflow of several packages, where you
> do experimental->unstable, and it is not going to surprise anyone that
* Raphael Hertzog [14 22:26]:
> Helper tools should usually rely on the output of `dpkg-vendor --query vendor`
> to find out the name of the current vendor. The retrieved string must be
> converted to lower case. This allows users to override the current vendor
> by setting `DEB_VENDOR` in the
On Nov 13, Raphael Hertzog wrote:
> I am part of the Python Modules team who wants to switch to git but not
> all contributors are using the same git helper tools and yet we would like
> to all work together on the same repositories without forcing everybody
> to use the same helper tool (habits
Hi,
>> I think the only workflow that newcomers and NMUers should be required
>> to learn is the one that involves quilt, they should not be expected to
>> learn (e.g.) dgit in addition. [...]
>
> I certainly don't think people should be expected to learn dgit in
> addition to other tools. I am
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote:
> [ I skip the more detailed discussions on naming conventions to
> concentrate on your higher level questions for now ]
Agreed, if we solve the tricky problems, that part is mostly just
yak shaving (and if we can't, it's probably
On Thursday, November 13, 2014 01:32:04 Sam Hartman wrote:
> Hi.
> I've read the original proposal and believe it is generally going in the
> right direction.
>
> things I liked:
>
> * didn't pick between dgit/git-dpm/git-pq; documented the common parts
>
> * Seemed to really focus on one clear
Hi,
Thibaut Paumard:
> We have a very nice source package format with "3.0 (quilt)".
IMHO this format is very nice if you have some opaque upstream,
and a debian/ directory that's under your control.
This restriction does not apply to a DVCS like git. Moreover, git already
has built-in mechanism
Tobias Frost writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> [Ian:]
> > And you should add:
> >The packaging branch should not contain a `.pc' directory.
>
> Maybe I got the above wrong: you mean "patch applied"
Thibaut Paumard writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> [patches applied vs unapplied]
>
> However, we should perhaps strongly recommend that this choice be
> documented in debian/README.sources.
I think it would be better to docum
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote:
[..snip..]
> Well git-buildpackage obviously needs quite some update:
> - it complains when you're trying to build as soon as you're not in a
> branch named master (that can be overridden with --git-ignore-branch
> or setting --gi
Le 12/11/2014 12:25, Raphael Hertzog a écrit :
> Hi,
>
> On Wed, 12 Nov 2014, Thibaut Paumard wrote:
>> I see nothing about whether the debian branch should contained the
>> unpacked or the unpacked *and* patched sources, and whether to ship the
>> .pc directory.
>
> That's a volunteer choice at
> 2014-11-12 10:28 GMT+01:00 Raphael Hertzog :
>> On Wed, 12 Nov 2014, Mathieu Parent wrote:
> OK. Makes sense. The unstripped upstream can then live in an
> non-namespaced branch if needed (this is not my usual workflow but should be
possible).
> On Wed, 12 Nov 2014, Mathieu Parent wrote:
>> May
> On Tue, 11 Nov 2014, Raphael Hertzog wrote:
First, I'm a fan of trying to ease the workflow for all by having some
standardisation / best-practice recommendation/documentation.
Kudos to the initiattors!
>> QUESTION: some people have argued to use debian/master as the latest
>> packaging tar
> I think you need to be more explicit about the implications for `3.0
> (quilt)' format packages. Something like:
>
>If the git tree contains debian/format specifying `3.0 (quilt)',
>the git tree must also contain debian/patches/series and all the
>patch files contained within it.
[ I skip the more detailed discussions on naming conventions to
concentrate on your higher level questions for now ]
On Thu, 13 Nov 2014, Ron wrote:
> Sure, I understood those were your goals.
>
> What I haven't seen, and what I'm asking for, is an actual detailed
> rationale describing the act
Hi,
Ian Jackson:
> > Thus, please don't try to shoehorn a divided workflow into this DEP.
> > Write your own.
>
> I disagree with half of this but agree with the other half.
> I think that the divided workflow should be documented in this DEP.
>
> But I agree that those who like the divided work
On Wednesday 12 November 2014 10:47:30 Raphael Hertzog wrote:
[snip]
> > I'd like to note that there are very good reasons for a debian-only,
> > overlay-style packaging repository too. This section should, in my
> > opinion, at least acknowledge that, and briefly mention it as an option.
> > I fi
Hi.
I've read the original proposal and believe it is generally going in the
right direction.
things I liked:
* didn't pick between dgit/git-dpm/git-pq; documented the common parts
* Seemed to really focus on one clear scope.
* Discouraged overlay packaging.
I've tried to read the arguments, an
On Wed, Nov 12, 2014 at 02:14:55PM +0100, Raphael Hertzog wrote:
> Hi Ron,
>
> On Wed, 12 Nov 2014, Ron wrote:
> > I think you probably need to be careful of overspecifying this.
>
> Definitely. That's precisely why I don't want to dwelve (too much)
> into details of the various workflows and why
Hi Simon,
(Please CC me on these, I'm not currently subscribed to -devel, and I'm
catching up from the list archives. At the very least it will make it
easier to avoid accidentally breaking the threading :)
> On 12/11/14 05:54, Mathieu Parent wrote:
> > Also, the vendor/* branches heads should
> "Raphael" == Raphael Hertzog writes:
Raphael> Hi Gergely,
Raphael> On Wed, 12 Nov 2014, Gergely Nagy wrote:
Raphael> When releasing a Debian package, the packager should create and
push
Raphael> a signed tag named `/`. For example, a Debian
maintainer
Raphael> releasin
On Wed, 12 Nov 2014, Raphael Hertzog wrote:
> On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote:
> > In fact, I was quite non-amused by the initial versions of this idea, but
> > reading this latest version, I must say I *like* it. Well done! I am
> > especially happy about the way it respec
On Wed, Nov 12, 2014 at 09:21:56AM +0100, Raphael Hertzog wrote:
> Hi,
>
> On Tue, 11 Nov 2014, Iustin Pop wrote:
> > > Packaging branches and tags
> > > ===
> > >
> > > Packaging branches should be named according to the codename of the
> > > target distribution. In the c
On Nov 12, 2014, at 09:27 AM, Matthias Urlichs wrote:
>Then we should either remove the paragraph entirely, or at least mention
>the danger of bit rot and that it's unwise to rely on being able to recover
>the tarfile (long term).
Because the vast majority of upstream Python packages are released
On 11/11/14 22:26, Raphael Hertzog wrote:
> Hello,
>
> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> It's now online at http://dep.debian.
On Wed, Nov 12, 2014 at 12:11:12PM +0100, Guillem Jover wrote:
> Hi!
>
> On Wed, 2014-11-12 at 15:38:59 +0800, Paul Wise wrote:
> > On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:
> > > I'd like to note that there are very good reasons for a debian-only,
> > > overlay-style packaging reposito
On Nov 12, 2014, at 10:02 AM, Raphael Hertzog wrote:
>I don't know. My long term hope is that in this process we will get to a
>situation where:
>- either the tools are sufficiently interoperable that we don't have to
> care about this
>- or one of tools emerges as standard supporting all the imp
Hi,
On Wed, 12 Nov 2014, Ian Jackson wrote:
> Simon, would you care to write up a concrete text documenting the
> conventional divided layouts ? Raphael, I guess you have the DEP in
> git. Where's the repo ? Wait, what, it's in the webtree in ...
> is that still CVS ?
It's in the "dep" SVN repo
On Wed, 12 Nov 2014, Ian Jackson wrote:
> > It doesn't make much sense to have an standard unless there's also a plan
> > to
> > implement using it.
>
> I thought Raphael was trying to document existing practice.
The problem is that existing practices are not uniform and vary between
helper too
Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Much like we have a "default desktop environment" we should have a default
> layout for a git packaging repository.
There's an argument for that.
Of course (donning m
2014-11-12 14:29 GMT+01:00 Raphael Hertzog :
> On Wed, 12 Nov 2014, Mathieu Parent wrote:
>> Maybe a short note would be good then? (but I don't know how to write it).
>
> I suggest this:
>
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> @@ -230,6 +230,17 @@ non-patchable data), you can d
Hi Ian,
On Wed, 12 Nov 2014, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git
> packaging repositories"):
> > +When you have good reasons to only store the `debian` packaging directory
> > +(for example when the uptream
On Wed, 12 Nov 2014, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git
> packaging repositories"):
> > The DEP will neither encourage and discourage its use. It only mentions
> > that if a maintainer is using it, it should store
On 12/11/14 14:12, Ian Jackson wrote:
> Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
>> In the gbp-pq world, after "git checkout debian/sid", hello.c would
>> contain "hello, world", but there wou
Ian Jackson writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> I think you need to be more explicit about the implications for `3.0
> (quilt)' format packages. Something like:
>
>If the git tree contains debian/format specifying `3.0
Matthias Urlichs writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> This DEP describes an integrated workflow.
That's true right now. But I think a document called `Recommended
layout for Git packaging repositories' ought to cover the reason
On November 12, 2014 8:15:02 AM CST, Scott Kitterman
wrote:
>On November 12, 2014 7:38:25 AM CST, Matthias Urlichs
> wrote:
>>Hi,
>>
>>Simon McVittie:
>>> Is it the intention of this DEP to mandate the gbp-pq-like repo
>>> structure, which basically forbids use of tools whose design does
>not
>>>
Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> For development releases
>
>
> Packages uploaded to the current development release should be prepared
> in a `/master` branch.
I preferred t
Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> +When you have good reasons to only store the `debian` packaging directory
> +(for example when the uptream sources are really huge and contains mostly
> +non-patchable data), yo
On November 12, 2014 7:38:25 AM CST, Matthias Urlichs
wrote:
>Hi,
>
>Simon McVittie:
>> Is it the intention of this DEP to mandate the gbp-pq-like repo
>> structure, which basically forbids use of tools whose design does not
>> match that? Or is the intention to set some conventions that can be
>
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> On 12/11/14 05:54, Mathieu Parent wrote:
> > Also, the vendor/* branches heads should be at a descendent commit of
> > the corresponding upstream branch, diffing only by the d
Hi,
Simon McVittie:
> > Keep Debian packaging completely separate (in a different branch,
> > or even in a diffferent archive) and use a quilt-ish workflow
> >
> > Let's call this one "divided".
>
> Three: same as Two, but the Debian packaging branch is branched from
> the upstream branch, so it
Scott Kitterman writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Who's going to do patches to existing tools (e.g. git-dpm is the one
> I use and care about) so they comply with this and similarly scripts
> to convert existing git repos to m
1 - 100 of 141 matches
Mail list logo
