Hello,
On Mon 08 Jul 2019 at 10:37AM +10, Ben Finney wrote:
> Russ Allbery writes:
>
>> Ben Finney writes:
>>
>> > It may be “bare debian” is meant to cover this; but I don't
>> > recognise the comment “requires use of quilt and similar tools”
>> > because I've never needed to use Quilt for thi
Sean Whitton writes:
> I don't think the comment about quilt is unreasonable, because it seems
> like you've just been lucky in not having to use quilt, or similar, yet.
> "Never having a Debian delta" would seem to be a property of packages,
> not workflows.
There's some conflation here between
Ian Jackson writes:
> What should another Debian contributor do, who wants to make a change
> to the upstream source, but wants to do so in your own git workflow
> and collaborate via your git branch, rather than by uploading a .dsc ?
I'm increasingly baffled here. Why does anyone need anything
Russ Allbery writes:
> Ben Finney writes:
>
> > It may be “bare debian” is meant to cover this; but I don't
> > recognise the comment “requires use of quilt and similar tools”
> > because I've never needed to use Quilt for this.
>
> How do you handle needed changes to the upstream source?
* Use
On Fri, Jul 05, 2019 at 10:13:01AM +1200, Daniel Reurich wrote:
> > There isn't enough information in the packaging and upstream branches
> > of a typical git workflow to reconstitute a precisely matching .orig
> > tarball: you have to either obtain .orig tarballs out-of-band, or use
> > pristine-t
Hello Enrico,
On Sun 30 Jun 2019 at 11:03PM +02, Enrico Zini wrote:
> On Sat, Jun 29, 2019 at 09:18:11AM -0400, Sam Hartman wrote:
>
>> I think it would be helpful for both of us to describe ways in which you
>> find that there are objectivity problems that would get in the way of
>> presenting t
On Fri, Jul 05, 2019 at 08:37:40AM +0800, Paul Wise wrote:
>
> I was simply talking about standard upstream contribution mechanisms;
> pull requests, requests to pull from repos, patches on mailing lists
> etc. I assume that almost all upstream projects have one of these.
The (de facto) dead upst
Hello,
On Fri 05 Jul 2019 at 08:37AM +08, Paul Wise wrote:
> On Thu, 2019-07-04 at 13:53 +0100, Ian Jackson wrote:
>
>> Does every DD have (i) access (ii) social authority, to make changes
>> to the upstream repo, the same way we do for the Debian package ?
>
> I was simply talking about standard
On Thu, 2019-07-04 at 13:53 +0100, Ian Jackson wrote:
> Does every DD have (i) access (ii) social authority, to make changes
> to the upstream repo, the same way we do for the Debian package ?
I was simply talking about standard upstream contribution mechanisms;
pull requests, requests to pull fr
On 05/07/19 09:02, Simon McVittie wrote:
> On Fri, 05 Jul 2019 at 01:07:59 +1200, Daniel Reurich wrote:
>> Our packaging approach is more or less "unapplied" for 3.0(quilt)
>> packages, and (I think) pretty much universally using quilt and gbp -
>> only for changelog and buildpackage (because it do
On Fri, 05 Jul 2019 at 01:07:59 +1200, Daniel Reurich wrote:
> Our packaging approach is more or less "unapplied" for 3.0(quilt)
> packages, and (I think) pretty much universally using quilt and gbp -
> only for changelog and buildpackage (because it does a nice pbuilder
> based build process with
> "Daniel" == Daniel Reurich writes:
Daniel> As a lurker and pervasive packager of the downstream Devuan,
Daniel> I thought I'd share some of my thoughts on this as git has
Daniel> been the core of our work flow and build system.
Thanks for joining the discussion!/
Daniel> F
On 30/06/19 00:16, Ian Jackson wrote:
> Enrico Zini writes ("Re: Survey results: git packaging practices / repository
> format"):
>> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
>>> I hope you all won't mind too much that Sean and I have priv
Paul Wise writes ("Re: Survey results: git packaging practices / repository
format"):
> On Thu, 2019-07-04 at 12:19 +0100, Ian Jackson wrote:
> > What should another Debian contributor do, who wants to make a change
> > to the upstream source, but wants to do so in your
On Thu, 2019-07-04 at 12:19 +0100, Ian Jackson wrote:
> What should another Debian contributor do, who wants to make a change
> to the upstream source, but wants to do so in your own git workflow
> and collaborate via your git branch, rather than by uploading a .dsc ?
Do upstream changes upstream
Paul Wise writes ("Re: Survey results: git packaging practices / repository
format"):
> On Thu, Jul 4, 2019 at 11:37 AM Russ Allbery wrote:
> > > I don't recognise the repository structure that was raised by myself and
> > > some others: A VCS repository tha
Hello,
On Thu 04 Jul 2019 at 01:21pm +1000, Ben Finney wrote:
> Ian Jackson writes:
>
>> Please let us know if we have missed one. It is probably better if
>> you ask us rather than just adding it, unless you're sure that what
>> you are adding isn't the same as one of the existing ones. In
>>
On Wed, Jul 03, 2019 at 10:52:46PM -0700, Russ Allbery wrote:
> I suspect Ian is assuming that some amount of that is always necessary
> when saying that "tools like Quilt" are required. I have to admit that
> I'm quite impressed that you *never* have any reason to need to do this
> when packaging
Paul Wise writes:
> On Thu, Jul 4, 2019 at 11:37 AM Russ Allbery wrote:
>> Ben Finney writes:
>>> I don't recognise the repository structure that was raised by myself
>>> and some others: A VCS repository that contains only the Debian
>>> packaging files, which at build time is then exported to a
On Thu, Jul 4, 2019 at 11:37 AM Russ Allbery wrote:
> Ben Finney writes:
>
> > I don't recognise the repository structure that was raised by myself and
> > some others: A VCS repository that contains only the Debian packaging
> > files, which at build time is then exported to a non-VCS working tree
Ian Jackson writes:
> I have said before that I think using "dgit push" (where possible) is
> an ethical imperative. (I should clarify that I *don't* mean that
> people who aren't using "dgit push" yet are bad people. Life is so
> full of ethical imperatives that no real human could meet them a
Ben Finney writes:
> I don't recognise the repository structure that was raised by myself and
> some others: A VCS repository that contains only the Debian packaging
> files, which at build time is then exported to a non-VCS working tree
> and moerged with the upstream source.
> It may be “bare
Ian Jackson writes:
> Please let us know if we have missed one. It is probably better if
> you ask us rather than just adding it, unless you're sure that what
> you are adding isn't the same as one of the existing ones. In
> particular it seems that "unapplied" is used by a large number of
> pe
Hello,
On Wed 03 Jul 2019 at 05:58pm +0100, Nikolaus Rath wrote:
> At least for me, I was able to simply run 'dgit --gbp build-source &&
> dgit --gpm push' instead of 'sbuild && dput '. Mission
> accomplished.
Or `dgit --gbp push-source`! (just wanted to note this in case you
hadn't come acros
On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote:
> The main difficulty now with getting dgit push adopted is that
> maintainers don't see the benefit *to themselves* and it is always
> harder to get someone to see a benefit *to someone else*.
Ok, that describe me. I see benefits in an
On Jul 03 2019, Andreas Tille wrote:
>> > That's the case for me. I need to admit that I did not used dgit. The
>> > reason is that I'm working in teams who all have Git repositories on
>> > Salsa that more or less are following what was described in the Perl
>> > team policy. I live under the
Andreas Tille writes ("Re: dgit advocacy again (Re: Survey results: git
packaging practices / repository format)"):
> On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote:
> > Anyway, I'm very happy to talk to you (or anyone) about your own
> > situation i
Hi Ian,
On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote:
> ...
> dgit push-source is slightly more convenient than the dput based
> system and it catches slightly more errors and does slightly more
> automatically. But, it is a fairly minor benefit *to the maintainer*.
>
> As I say,
Andreas Tille writes ("Re: dgit advocacy again (Re: Survey results: git
packaging practices / repository format)"):
> On Wed, Jul 03, 2019 at 11:41:34AM +0100, Ian Jackson wrote:
> > People like you are precisely the intended users of "dgit push --gbp".
> >
&
es are clearly
in my focus.
> Andreas Tille writes ("Re: Survey results: git packaging practices /
> repository format"):
> > On Mon, Jul 01, 2019 at 12:49:05PM +0100, Ian Jackson wrote:
> > > My table is supposed to be useable without knowing anything about
> &g
On Wed, Jul 03, 2019 at 11:30:46AM +0100, Ian Jackson wrote:
> > I admit under the circumstances you describe DEP-14 has advantages over
> > default gbp. I'm not sure how productive it would be for teams with
> > about 1000 packages to change the repository layout (posssibly its
> > scriptable) ju
Sorry about this, but I really wanted to reply to this because I think
it is a common misconception. I hope people who are tired of this
subject can tell their program to delete messages with `dgit advocacy'
in the subject...
Andreas Tille writes ("Re: Survey results: git packaging
Andreas Tille writes ("Re: Survey results: git packaging practices / repository
format"):
> On Mon, Jul 01, 2019 at 11:09:27AM +0100, Simon McVittie wrote:
> > From https://perl-team.pages.debian.net/git.html#Patches it appears
> > the Perl team is using what the su
Hi Ian,
On Mon, Jul 01, 2019 at 12:53:06PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Survey results: git packaging practices / repository
> format"):
> > What it doesn't say is how changes to the upstream files are
> > represented. Can you explain
Hi Simon,
On Mon, Jul 01, 2019 at 11:09:27AM +0100, Simon McVittie wrote:
> On Mon, 01 Jul 2019 at 07:30:39 +0200, Andreas Tille wrote:
> > I admit I did not joined the dgit discussion - may be that's the reason
> > I can not really match the branches that are used in Perl team policy
> >
> >
Hi Ian,
On Mon, Jul 01, 2019 at 12:49:05PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: Survey results: git packaging practices /
> repository format"):
> > I admit I did not joined the dgit discussion - may be that's the reason
> > I can not really ma
On 28.06.19 23:42, Ian Jackson wrote:
>https://wiki.debian.org/GitPackagingSurvey
>
> Unfortunately due to bugs in the Debian and Wiki CSS styles, it is
> displayed very suboptimally unless you log into the wiki and set your
> style to "Classic". (I have filed bug reports.)
Very nice work.
Simon McVittie writes ("Re: Survey results: git packaging practices /
repository format"):
> The precise names of the branches are not immediately relevant to
> GitPackagingSurvey: it's the content of those branches that matters.
Thanks for this mail which I think will be
Ian Jackson writes ("Re: Survey results: git packaging practices / repository
format"):
> What it doesn't say is how changes to the upstream files are
> represented. Can you explain ?
Also: I had hoped that the table's focus on particularly these
questions:
- re
Andreas Tille writes ("Re: Survey results: git packaging practices / repository
format"):
> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> > Thanks to everyone who responded. I (with some help from Sean and
> > some review from Sam) have worked the
On Mon, 01 Jul 2019 at 07:30:39 +0200, Andreas Tille wrote:
> I admit I did not joined the dgit discussion - may be that's the reason
> I can not really match the branches that are used in Perl team policy
>
> https://perl-team.pages.debian.net/git.html#repository_layout
>
> (which is used b
Hi Ian,
thanks for your work on this.
On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Survey: git packaging practices / repository format"):
> > While trying to write the dgit FAQ, and some of the relevant docs, it
> > has become even more painfully obvious tha
On Sat, Jun 29, 2019 at 09:18:11AM -0400, Sam Hartman wrote:
> I think it would be helpful for both of us to describe ways in which you
> find that there are objectivity problems that would get in the way of
> presenting the data in that context.
>
> I think especially at that bof we'd like to av
On Sat, Jun 29, 2019 at 01:16:28PM +0100, Ian Jackson wrote:
> The current presentation lists *branch formats* not *workflows*.
>
> Everything in the current page other than the comments and best
> practices columns is objective, but I see it as lower level than what
> I think you are looking for
> "Enrico" == Enrico Zini writes:
Enrico> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
>> I hope you all won't mind too much that Sean and I have
>> privileged our own point of view, in the columns which contain
>> value judgements, and that we hope to retain t
Enrico Zini writes ("Re: Survey results: git packaging practices / repository
format"):
> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> > I hope you all won't mind too much that Sean and I have privileged our
> > own point of view, in the columns
On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> I hope you all won't mind too much that Sean and I have privileged our
> own point of view, in the columns which contain value judgements, and
> that we hope to retain that property of the page.
I have no problem with you making a col
Andrej Shadura writes ("Re: Survey results: git packaging practices /
repository format"):
> On Fri, 28 Jun 2019 at 16:42, Ian Jackson
> wrote:
> > [1] This does *not* include the one response from a Debian downstream.
> > The task of being a Debian downstrea
On Fri, 28 Jun 2019 at 16:42, Ian Jackson
wrote:
> [1] This does *not* include the one response from a Debian downstream.
> The task of being a Debian downstream is rather different and it
> doesn't make sense to try to represent that in the same table.
Well, it’s a bit disappointing it doesn’t s
Ian Jackson writes ("Survey: git packaging practices / repository format"):
> While trying to write the dgit FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git to do their Debian
> packa
50 matches
Mail list logo
