Hello,
On Thu 09 May 2019 at 01:23PM +01, Ian Jackson wrote:
> For your workflow, I see broadly two possibilities, depending what
> representation you use for upstream source code:
>
> (i) You use upstream tarballs as your representation of the upstream
> source code, and do not use upstrea
Hello Ansgar,
On Tue 07 May 2019 at 06:30PM +02, Ansgar wrote:
> So in a way the problem is that the documentation needs to exist. git-
> debrebase or dgit (to a lesser extend) implement a Debian-specific
> version control system on top of Git. git-debrebase makes this most
> obvious: the Git h
Holger Levsen writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git [and 1 more messages]"):
> On Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote:
> > debcheckout *certainly* doesn't do this. It just gives you the
> > current
On Thu, 2019-05-09 at 12:51 +, Holger Levsen wrote:
> On Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote:
> > debcheckout *certainly* doesn't do this. It just gives you the
> > current master which may not have been uploaded anywhere.
>
> nope:
>
> $ debcheckout munin
> declared git
On Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote:
> debcheckout *certainly* doesn't do this. It just gives you the
> current master which may not have been uploaded anywhere.
nope:
$ debcheckout munin
declared git repository at https://salsa.debian.org/debian/munin.git -b debian
git c
Holger Levsen writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git [and 1 more messages]"):
> On Wed, May 08, 2019 at 04:14:00PM +0100, Ian Jackson wrote:
>
> * Debian should provide source code as git branches which:
> - can be buil
(adding #903392)
Ben Finney writes ("Re: Preferred git branch structure when upstream moves from
tarballs to git"):
> What I remain unconvinced of is the worth of abandoning the clean
> separation between an upstream source repository (whether Git repository
> or not) and a
Ansgar writes ("Re: Preferred git branch structure when upstream moves from
tarballs to git"):
> On Thu, 2019-05-09 at 10:33 +0100, Ian Campbell wrote:
> > I think there's a common misconception here which has cropped up
> > several times in this thread. (NB: I'
On Thu, 2019-05-09 at 10:33 +0100, Ian Campbell wrote:
> On Thu, 2019-05-09 at 11:19 +1000, Ben Finney wrote:
> > What I remain unconvinced of is the worth of abandoning the clean
> > separation between an upstream source repository (whether Git repository
> > or not) and a VCS repository for Debia
On Wed, May 08, 2019 at 03:26:32PM +, Holger Levsen wrote:
> thanks for the pointer, but I don't see the string debcheckout in that
> message and vcs-git only once, where you write:
>
> ---begin quote---
>
> >From these we can conclude:
>
> * Debian should provide source code as git branche
On Thu, 2019-05-09 at 11:19 +1000, Ben Finney wrote:
> What I remain unconvinced of is the worth of abandoning the clean
> separation between an upstream source repository (whether Git repository
> or not) and a VCS repository for Debian packaging (typically in Git).
I think there's a common misco
Ian Jackson writes:
> So far I have gained the impression that the kind of people who are
> using packaging-only git trees tend to be very conservative, and very
> comfortable with .dsc/tarball/patch/quilt based tools, and not really
> convinced of the usefulness of git.
Let me counter that impr
Simon McVittie writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Sat, 04 May 2019 at 21:10:34 +0100, Ian Jackson wrote:
> > So far I have gained the impression that
> > the kind of people who are using packaging-only git
Simon McVittie writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Tue, 07 May 2019 at 19:25:39 +0100, Ian Jackson wrote:
> > What I am primarily advocating for in this thread is that maintainers
> > should choose `dgit push-source
Simon McVittie writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Wed, 08 May 2019 at 12:18:41 +0100, Ian Jackson wrote:
> > Indeed, you yourself say you avoid gbp but for many packages, the
> > Vcs-Git header gives you a patch
On Wed, May 08, 2019 at 04:14:00PM +0100, Ian Jackson wrote:
> > > [Ian Jackson:]
> > > > You should use dgit for the benefit of users. See my other mail which
> > > > answers why Vcs-Git and debcheckout is not enough.
> > >
> > > could you be so kind and provide a pointer, this thread is rather
Holger Levsen writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> could you be so kind and provide a pointer, this thread is rather long
> already? (Maybe this is also worth an FAQ entry somewhere..)
Jonathan Carter writes ("Re:
On Wed, May 08, 2019 at 03:57:08PM +0100, Ian Jackson wrote:
> > both.
> For packaging-only, dgit does not properly support that. Do you have
> the upstream source in git form too, and if so how do you combine
> them ? Do you manipulate patches using quilt ? [1]
hm/i'm sorry, I cannot really thi
Holger Levsen writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Wed, May 08, 2019 at 12:18:41PM +0100, Ian Jackson wrote:
> > I'm not sure what git branch format you are using. (Maybe you said it
> > earlier in this thread.
Matthew Vernon writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> Scott Kitterman writes:
> > For what it's worth, when you start calling me names (unethical)
> > because I'm not using your shiny new toy, my immediate
On Sat, 04 May 2019 at 21:10:34 +0100, Ian Jackson wrote:
> So far I have gained the impression that
> the kind of people who are using packaging-only git trees tend to be
> very conservative, and very comfortable with .dsc/tarball/patch/quilt
> based tools, and not really convinced of the usefulne
On Tue, 07 May 2019 at 19:25:39 +0100, Ian Jackson wrote:
> What I am primarily advocating for in this thread is that maintainers
> should choose `dgit push-source' over `dput' (where this is possible).
> This is the only way for a maintainer to provide users with the git
> history in a sensible fo
Scott Kitterman writes:
> On May 7, 2019 8:50:57 PM UTC, Sam Hartman wrote:
>>> "Ian" == Ian Jackson writes:
>>Ian> The latter point is because using dgit push is an ethical
>>Ian> imperative, not because the two somehow have some deep
>> Ian> technical linkage. IMO almost *any*
On Wed, 08 May 2019 at 12:18:41 +0100, Ian Jackson wrote:
> Indeed, you yourself say you avoid gbp but for many packages, the
> Vcs-Git header gives you a patches-unapplied format which requires[1]
> gbp pq to switch to a patches-applied view before you build it.
This step is not required: for 3.0
On 2019/05/08 13:23, Holger Levsen wrote:
>> You should use dgit for the benefit of users. See my other mail which
>> answers why Vcs-Git and debcheckout is not enough.
>
> could you be so kind and provide a pointer, this thread is rather long
> already? (Maybe this is also worth an FAQ entry som
On Wed, May 08, 2019 at 12:18:41PM +0100, Ian Jackson wrote:
> I'm not sure what git branch format you are using. (Maybe you said it
> earlier in this thread.) Packaging-only ? git-merge ?
both.
> You should use dgit for the benefit of users. See my other mail which
> answers why Vcs-Git and
Holger Levsen writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> as a data point: I never really got my head around gbp, too many times
> it came in the way, did things I didnt expect to do (or couldnt easily
> figure out what it did), so
On Tue, May 07, 2019 at 07:25:39PM +0100, Ian Jackson wrote:
> A maintainer who is currently using gbp pq can (and IMO generally
> should) use `dgit push' to do their uploads, rather than dput/dupload.
as a data point: I never really got my head around gbp, too many times
it came in the way, did
Sam Hartman writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> Ian Jackson writes:
> > The latter point is because using dgit push is an ethical
> > imperative, not because the two somehow have some deep
> > technical link
On May 7, 2019 8:50:57 PM UTC, Sam Hartman wrote:
>> "Ian" == Ian Jackson writes:
>
>Ian> Sam Hartman writes ("Re: Preferred git branch structure when
>Ian> upstream moves from tarballs to git"):
>>> I'm aware I'm making a typing error, and speaking in
>>> generalities. I
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: Preferred git branch structure when
Ian> upstream moves from tarballs to git"):
>> I'm aware I'm making a typing error, and speaking in
>> generalities. I agree that my statement is true for debrebase,
>> but I
Sam Hartman writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> I'm aware I'm making a typing error, and speaking in generalities. I
> agree that my statement is true for debrebase, but I meant the dgit
> ecosystem.
I don
On 2019-05-07, Ansgar wrote:
> The concept behind 3.0 (quilt) is much easier to explain: extract
> tarballs, optionally apply some patches provided. With the bonus that
> users who have used other distributions before might already know about
> most of this which lowers barrier of entry. Impleme
Sam Hartman writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> I was going to argue that I thought teaching gbp pq was easier than
> dgit, and that's true up until you have to update a patch.
I'm sorry not to really deal with your
> "Ian" == Ian Campbell writes:
Ian> On Tue, 2019-05-07 at 11:01 -0400, Sam Hartman wrote:
>> That said, I think Ansgar has some really valid points. I think
>> that dgit (or git-dpm) are the hardest work flows to teach.
Ian> I think perhaps you meant `git-debrebase` rather
On Tue, 2019-05-07 at 12:51 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > Sam Hartman writes:
> > > OK, I didn't hear that as an answer but think I'm coming to the
On Tue, 2019-05-07 at 11:01 -0400, Sam Hartman wrote:
> That said, I think Ansgar has some really valid points. I think that
> dgit (or git-dpm) are the hardest work flows to teach.
I think perhaps you meant `git-debrebase` rather than `dgit` throughout
the remainder of your mail, since comparing
> "Ian" == Ian Jackson writes:
Ian> Ansgar Burchardt writes ("Re: Preferred git branch structure
Ian> when upstream moves from tarballs to git"):
>> Sam Hartman writes: > OK, I didn't hear
>> that as an answer but think I'm coming to the same > conclusion
>> that Ian did
Ansgar Burchardt writes ("Re: Preferred git branch structure when upstream
moves from tarballs to git"):
> Sam Hartman writes:
> > OK, I didn't hear that as an answer but think I'm coming to the same
> > conclusion that Ian did after reading your mail.
>
Sam Hartman writes:
>> "Ansgar" == Ansgar writes:
>
> Ansgar> Sam Hartman writes:
> >> I'm having a bit of trouble here and am hoping you can help us
> >> out. Ian asked what git workflow it is that you're talking about
> >> where people can deal with commit push and pull a
> "Ansgar" == Ansgar writes:
Ansgar> Sam Hartman writes:
>> I'm having a bit of trouble here and am hoping you can help us
>> out. Ian asked what git workflow it is that you're talking about
>> where people can deal with commit push and pull and don't need to
>> know mo
Sam Hartman writes:
> I'm having a bit of trouble here and am hoping you can help us out.
> Ian asked what git workflow it is that you're talking about where people
> can deal with commit push and pull and don't need to know more.
>
> I didn't see a clear answer to that.
> Which debian packaging w
>>>>> "Ansgar" == Ansgar writes:
Ansgar> On Fri, 2019-05-03 at 17:39 +0100, Ian Jackson wrote:
>> Ansgar writes ("Re: Preferred git branch structure when upstream
>> moves from tarballs to git"):
>> > On Fri, 2019-05-03
Ben Finney writes ("Re: Preferred git branch structure when upstream moves from
tarballs to git"):
> Ian Jackson writes:
> > [...] I have not taught dgit how to convert [separate Debian
> > packaging-only repository and upstream source repository] into a git
> > t
Ian Jackson writes:
> […] I have not taught dgit how to convert [separate Debian
> packaging-only repository and upstream source repository] into a git
> tree that contains the [combined] source code.
One interpretation of “convert [separate repositories] into [one Git
tree]” is that it's a flag
On Fri, 2019-05-03 at 17:39 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream
> moves from tarballs to git"):
> > On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> > > Ansgar writes ("Re: Preferred git branch stru
Ansgar writes ("Re: Preferred git branch structure when upstream moves from
tarballs to git"):
> On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> > Ansgar writes ("Re: Preferred git branch structure when upstream moves from
> > tarballs to git"):
>
On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream moves from
> tarballs to git"):
> > On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> > > Ansgar writes:
> > > > Having to
Ansgar writes ("Re: Preferred git branch structure when upstream moves from
tarballs to git"):
> On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> > Ansgar writes:
> > > Having to know about branches, merging, dealing with multiple remotes,
> > > ...
Ben Hutchings writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Thu, 2019-05-02 at 11:23 +0100, Ian Jackson wrote:
> > Sorry for shouting, but, really. It is kind of frustrating to have
> > designed and implemented and de
Ansgar writes:
> On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
>> I'm confused. I'm a happy user of dgit and don't have to think about
>> any of those things as part of using dgit. I choose to use branches,
>> but I certainly wouldn't have to, and merging, multiple remotes, and so
>> f
On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> Ansgar writes:
>
> > Having to know about branches, merging, dealing with multiple remotes,
> > ... *is* an entry barrier compared to not having to know about it. Now
> > you have to teach people that before you even get to how to write a
Ansgar writes:
> Having to know about branches, merging, dealing with multiple remotes,
> ... *is* an entry barrier compared to not having to know about it. Now
> you have to teach people that before you even get to how to write a
> build recipe.
I'm confused. I'm a happy user of dgit and don'
On Thu, 2019-05-02 at 11:23 +0100, Ian Jackson wrote:
[...]
> Sorry for shouting, but, really. It is kind of frustrating to have
> designed and implemented and deployed a complex piece of software
> which solves a lot of problems, and constantly hear people
> - proposing solutions which do not ad
On Thu, 2019-05-02 at 13:45 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
> > > As a package maintainer, if you don
Ansgar Burchardt writes ("Re: Preferred git branch structure when upstream
moves from tarballs to git"):
> On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
> > As a package maintainer, if you don't keep the whole source package in
> > git, you're giv
On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
>
> On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:
>
> > As an example: to update to a new upstream release, I ideally just have
> > to drop the new upstream tarball, update d/changelog and am done.
> > Compare with [1] which is much more c
My initial question resulted in a lot of useful advice and opinions, and
spurred quite an interesting discussion. Thanks to everyone who
contributed, and apologies for not contributing myself.
Philipp Kern writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On 5/2/2019 7:11 AM, Ben Finney wrote:
> > Conversely, I think it does a disservice to downstream users to mix in
> > Debian packaging changes with upstream changes.
On 5/2/2019 7:11 AM, Ben Finney wrote:
> Conversely, I think it does a disservice to downstream users to mix in
> Debian packaging changes with upstream changes. The separation is useful
> and much easier to maintain when the repositories are separate.
To be honest the greatest disservice is that
Sean Whitton writes:
> Hello,
>
> On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:
>
> > As an example: to update to a new upstream release, I ideally just
> > have to drop the new upstream tarball, update d/changelog and am
> > done.
>
> As a package maintainer, if you don't keep the whole sourc
Hello,
On Wed 01 May 2019 at 09:53PM +0200, Adam Borowski wrote:
> On Wed, May 01, 2019 at 08:14:24AM +0200, Thomas Goirand wrote:
>> It's basically useless, since upstream repository is just one command
>> away, with the upstream URL documented in debian/rules.
>
> This assumes the upstream URL
On Wed, May 01, 2019 at 08:14:24AM +0200, Thomas Goirand wrote:
> It's basically useless, since upstream repository is just one command
> away, with the upstream URL documented in debian/rules.
This assumes the upstream URL lives forever. But what if the upstream
repo's hoster (let's call it "ali
Oh, only now I noticed that this has become a long thread. Sorry for
the out-of-context reply. :)
On 01 May 2019, Gabriel F. T. Gomes wrote:
>On 29 Apr 2019, Gard Spreemann wrote:
>
>>For one of my packages, I maintain two public git branches: one is
>>upstream/latest, where I've been importing
On 29 Apr 2019, Gard Spreemann wrote:
>For one of my packages, I maintain two public git branches: one is
>upstream/latest, where I've been importing upstream's released tarballs,
>and the other is debian/sid that contains the packaging.
>
>Recently, upstream has finally started using git. What is
On 4/30/19 9:55 AM, Adam Borowski wrote:
> On Tue, Apr 30, 2019 at 09:04:09AM +0200, Thomas Goirand wrote:
>> What I found the most easy way is to just use whatever branching names
>> upstream is using, and *never* store them in Salsa. If you need upstream
>> repository, you can simply run a ./debi
Hello,
On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:
> As an example: to update to a new upstream release, I ideally just have
> to drop the new upstream tarball, update d/changelog and am done.
> Compare with [1] which is much more complicated, even ignoring the extra
> complexity using dgit
On Tue, 2019-04-30 at 12:05 +0100, Ian Jackson wrote:
> Sean Whitton writes ("Re: Preferred git branch structure when upstream moves
> from tarballs to git"):
> > On Mon 29 Apr 2019 at 02:12PM +01, Ian Campbell wrote:
> > >
> > > I think (but don'
Sean Whitton writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Mon 29 Apr 2019 at 02:12PM +01, Ian Campbell wrote:
> > Are there any docs/advice on switching back and forth between these (or
> > at least switching between dgit-m
On Mon, 2019-04-29 at 13:50 -0700, Sean Whitton wrote:
>
> dgit-maint-merge -> dgit-maint-debrebase would indeed be the
> convert-from-dgit-view subcommand. If I were dealing with this, for
> simplicity, I would start from the point of just having made an upload.
> That way you know your HEAD is
On Tue, Apr 30, 2019 at 09:04:09AM +0200, Thomas Goirand wrote:
> What I found the most easy way is to just use whatever branching names
> upstream is using, and *never* store them in Salsa. If you need upstream
> repository, you can simply run a ./debian/rules fetch-upstream-remote,
> and most of
On 4/29/19 11:18 AM, Gard Spreemann wrote:
> Hi,
>
> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has finally started
Russell Stuart writes:
> On Tue, 2019-04-30 at 09:25 +0800, Paul Wise wrote:
>> I like this option because it still works well if we ever decide to
>> fix a fundamental flaw in the Debian source package layout.
>
> I suspect whether that's a fundamentally is a matter or personal taste.
> On this p
On Tue, 2019-04-30 at 09:25 +0800, Paul Wise wrote:
> I like this option because it still works well if we ever decide to
> fix a fundamental flaw in the Debian source package layout.
I suspect whether that's a fundamentally is a matter or personal taste.
On this point my taste aligns with yours.
On Tue, Apr 30, 2019 at 9:03 AM Ben Finney wrote:
> My opinionated recommendation: Track the Debian packaging in a separate
> repository (which contains only the ‘debian/’ directory tree). When it's
> time to build the Debian source package for testing, export the upstream
> source to a temporary
Gard Spreemann writes:
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as
> the upstream branch to follow?
My opinionated recommendation: Track
Hello,
On Mon 29 Apr 2019 at 02:12PM +01, Ian Campbell wrote:
> Are there any docs/advice on switching back and forth between these (or
> at least switching between dgit-maint-merge and one of the patch
> queueish ones)?
>
> When trying to chose I seem to find myself thinking along the lines
> "m
Hello,
On Mon 29 Apr 2019 at 11:18AM +02, Gard Spreemann wrote:
> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has fin
Gard Spreemann writes:
> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
> Recently, upstream has finally started using git. What is the
> reco
On Mon, 2019-04-29 at 13:25 +0100, Ian Jackson wrote:
> Look at the intro to each of these and see which one you think might
> be best:
> https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html
>
> https://manpages.debian.org/stretch-backports/dgit/dgit-maint-debrebase.7.en
Gard Spreemann writes ("Preferred git branch structure when upstream moves from
tarballs to git"):
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to
On Mon, Apr 29, 2019 at 11:18:48AM +0200, Gard Spreemann wrote:
> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has fina
On Mon, Apr 29, 2019 at 11:18:48AM +0200, Gard Spreemann wrote:
> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has fina
On Mon, Apr 29, 2019 at 11:40:39AM +0200, Adam Borowski wrote:
> that's a monstrosity -- my personal preference is raw git, where updating to
> a new upstream is "git merge v3.14.15"
gbp allows this too, of course.
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi,
For one of my packages, I maintain two public git branches: one is
upstream/latest, where I've been importing upstream's released tarballs,
and the other is debian/sid that contains the packaging.
Recently, upstream has finally started using git. What is the
recommended way for me to maintain
85 matches
Mail list logo
