Re: Feedback on 3.0 source format problems

[Thomas Goirand]

On 01/04/2017 06:30 AM, Nikolaus Rath wrote:
> But I am not sure if a package structure like
> 
> mypkg/upstream/*
> mypkg/debian/*
> mypkg/patches/* (?)
> 
> would have any *practical* benefits over the current situation

It would have the huge benefit that upstream .git* files would stay in
the upstream folder, and wouldn't conflict. I had for example issues
with conflicting .gitreview files when using Gerrit for the Debian
packaging.

I don't see however any advantage of moving the patches folder outside
of the debian folder.

> because
> this transformation could be trivially automated in either direction.

Would you mind explaining who and how it would be automated?

Cheers,

Thomas Goirand (zigo)

Re: Feedback on 3.0 source format problems

[Raphael Hertzog]

Hi,

On Sun, 01 Jan 2017, Guillem Jover wrote:
> On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote:
> > On Jan 01 2017, Guillem Jover  wrote:
> > > (I'm not using  because
> > > TBH it read more like a sales brochure than a more neutral page…)
> > 
> > TBH this feels like you're sniping at Raphael here, which I think is
> > pretty sad and inappropriate.
> 
> Hmm, I brought it up because it does read like that to me (please have
> a look if you haven't), and it does not feel right for me to change the
> tone of that page on my own.

I agree with your choice of using a separate page and I even agree with
your reasons.

I don't agree that you had to write the above sentence at the start of the
discussion. It did not bring anything to the discussion and I confirm what
Nikolaus said, I felt attacked for having promoted the new source format.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Feedback on 3.0 source format problems

[Guido Günther]

On Tue, Jan 10, 2017 at 10:14:09AM -0800, Nikolaus Rath wrote:
> On Jan 10 2017, Guido Günther  wrote:
> > On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote:
> >> On Jan 05 2017, Brian May  wrote:
> >> > Vincent Bernat  writes:
> >> >
> >> >> There have been a lot of complaints about it. For me, it is a pain to
> >> >> use. Its integration with gbp is poor, it produces a messy history when
> >> >> you are working on your patches and I often run into problems with
> >> >> .debian/.git-dpm file it maintains (import a new upstream, make some
> >> >> changes, notice that somebody else also pushed a change, pull --rebase,
> >> >> everything is broken). Since we started using it, we opened a lot of bug
> >> >> reports and not a single one of them has been fixed. I think that nobody
> >> >> wants to work on it because it is an extremely fragile tool and the
> >> >> first one to try to fix it will inherit of all the problems to solve.
> >> >
> >> > It also has a number of bugs that are not getting fixed.
> >> 
> >> Yeah, I think we heard before that git-dpm is not being maintained. I
> >> said it, Vincent said it in his reply, and now you are saying it
> >> again. No one is disputing the point.
> >> 
> >> > Plus if conflicts occur because multiple people unexpectedly make
> >> > changes at the same time it (i.e. you can't push because somebody else
> >> > already pushed changes) can be a world of confusion trying to sort out
> >> > the mess.
> >> 
> >> Yes, it is a mess. But I don't think it's any worse than having to
> >> resolve conflicts in debian/patches/, which is the equivalent problem
> >> when multiple people use gbp at the same time.
> >
> > When this happens you do a "gbp pq import" and have the full power of
> > git rebas at your hands.
> 
> Are you sure? The problem we're talking about is when two conflicting
> changes to debian/patches have been committed. I think in that case you
> first have to solve the git conflict before you can call gbp pq - or can
> gbp pq import really deal with conflict markers *inside the patch*?

You abort the merge instead of resolving the conflict then do a gbp pq
on your packaging branch and on the (know known to be) conflicting one
(say master and origin/master). Then you can use rebase and
whatnot. Not ideal but much batter than wading through merge conflicts
in diffs.

Cheers,
 -- Guido

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 10 2017, Guido Günther  wrote:
> On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote:
>> On Jan 05 2017, Brian May  wrote:
>> > Vincent Bernat  writes:
>> >
>> >> There have been a lot of complaints about it. For me, it is a pain to
>> >> use. Its integration with gbp is poor, it produces a messy history when
>> >> you are working on your patches and I often run into problems with
>> >> .debian/.git-dpm file it maintains (import a new upstream, make some
>> >> changes, notice that somebody else also pushed a change, pull --rebase,
>> >> everything is broken). Since we started using it, we opened a lot of bug
>> >> reports and not a single one of them has been fixed. I think that nobody
>> >> wants to work on it because it is an extremely fragile tool and the
>> >> first one to try to fix it will inherit of all the problems to solve.
>> >
>> > It also has a number of bugs that are not getting fixed.
>> 
>> Yeah, I think we heard before that git-dpm is not being maintained. I
>> said it, Vincent said it in his reply, and now you are saying it
>> again. No one is disputing the point.
>> 
>> > Plus if conflicts occur because multiple people unexpectedly make
>> > changes at the same time it (i.e. you can't push because somebody else
>> > already pushed changes) can be a world of confusion trying to sort out
>> > the mess.
>> 
>> Yes, it is a mess. But I don't think it's any worse than having to
>> resolve conflicts in debian/patches/, which is the equivalent problem
>> when multiple people use gbp at the same time.
>
> When this happens you do a "gbp pq import" and have the full power of
> git rebas at your hands.

Are you sure? The problem we're talking about is when two conflicting
changes to debian/patches have been committed. I think in that case you
first have to solve the git conflict before you can call gbp pq - or can
gbp pq import really deal with conflict markers *inside the patch*?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Guido Günther]

On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote:
> On Jan 05 2017, Brian May  wrote:
> > Vincent Bernat  writes:
> >
> >> There have been a lot of complaints about it. For me, it is a pain to
> >> use. Its integration with gbp is poor, it produces a messy history when
> >> you are working on your patches and I often run into problems with
> >> .debian/.git-dpm file it maintains (import a new upstream, make some
> >> changes, notice that somebody else also pushed a change, pull --rebase,
> >> everything is broken). Since we started using it, we opened a lot of bug
> >> reports and not a single one of them has been fixed. I think that nobody
> >> wants to work on it because it is an extremely fragile tool and the
> >> first one to try to fix it will inherit of all the problems to solve.
> >
> > It also has a number of bugs that are not getting fixed.
> 
> Yeah, I think we heard before that git-dpm is not being maintained. I
> said it, Vincent said it in his reply, and now you are saying it
> again. No one is disputing the point.
> 
> > Plus if conflicts occur because multiple people unexpectedly make
> > changes at the same time it (i.e. you can't push because somebody else
> > already pushed changes) can be a world of confusion trying to sort out
> > the mess.
> 
> Yes, it is a mess. But I don't think it's any worse than having to
> resolve conflicts in debian/patches/, which is the equivalent problem
> when multiple people use gbp at the same time.

When this happens you do a "gbp pq import" and have the full power of
git rebas at your hands.
Cheers,
 -- Guido

Re: Feedback on 3.0 source format problems

[Guido Günther]

On Tue, Jan 03, 2017 at 07:24:18PM -0800, Russ Allbery wrote:
> Nikolaus Rath  writes:
> 
> > Are there really upstreams that do that? I'd expect that the primary
> > consumer of Debian patches are other distributions, downstreams, and
> > users.
> 
> > I'd think that anything that's relevant for upstream development is
> > forwarded to upstream by the maintainer in whatever format upstream
> > prefers. This requires extra time, but I would be surprised to hear if
> > there are maintainers that have sufficient time to create patches that
> > are suitable for upstream, but don't have the little extra time to send
> > them upstream.
> 
> There are definitely upstreams who like to look at what patches Debian is
> shipping at their convenience, rather than having to ask the maintainer.
> The maintainer may have already sent along the patches, but it's easy to
> lose track of what patches are still being applied.

> The other case where being able to point upstream at a directory of
> patches is very nice is when upstream has been dormant for a long time and
> then comes back to life.  It's an easy way for them to pull a bunch of
> changes at once for a new development cycle.
> 
> I've also found it significantly smooth over relations with upstreams who
> are otherwise quite prickly about modifications to their distributed
> releases.  Having all the patches be published and clearly documented
> somewhere without anyone having to ask wins points for transparency and
> makes them feel like the whole process is less out of control and more
> congenial and collaborative, even if you were also in the habit of sending
> changes upstream.  It eliminates the fear that you're also applying other
> ugly hacks you're not telling them about that might be maintenance burdens
> for them.

Thanks for the nice summary. I now wonder:

If we want a way to present this as a git view for a 3.0 (quilt)
packages one could make gbp pq create a branch that contains the patched
tree (like "gbp pq import" but on top of upstream branch and not on top
of the debian branch). This branch would be directly mergeable by
upstream.  If we tag after the import these histories would be stable
and if one wants these to be fast-forwardable then the topmost commits
can be joined by pseudo merges and one could track the history of each
commit. I did not yet see the point to add this since:

a) these branches usually have debian specific upstream modifications,
cherry-picks _from_ upstream and new fixes _for_ upstream intermixed so
upstream would cherry-pick at best but never merge

b) upstream usually wants specific patches on top of its current version
not of the version we're currently working in Debian. This can be done
with gbp pq import and git cherry-pick or rebase already.

so I usually:

* use tarballs (since uscan is so convenient)
* add upstreams history as a detached history
* cherry pick between the debian branch and upstreams master (or any
  other of upstream's branches)
* point upstream to debian/patches on alioth (or much more often
  git-send-email directly)

so would adding such a view make any sense nevertheless?
Cheers
 -- Guido

Re: Feedback on 3.0 source format problems

[Andrey Rahmatullin]

On Tue, Jan 10, 2017 at 08:36:13AM +1000, Russell Stuart wrote:
> To state the bleeding obvious, it arises because on day 1 Debian
> decided to do the builds in the original source tree, then tries to
> recover the original source at the end by running "debian/rules clean".
>  When I moved from rpm's to deb over a decade ago, I was surprised by
> this.  Rpm's create temp build directory, so the "debian/rules clean"
> step can be handled reliably 100% of the time by the rpm build tool.
Indeed.

> Later when I started to work on other peoples packages it became
> apparent that many of the Romans didn't bother with it.  So the
> debian/rules binary; dpkg --install; test; debian/rules clean; fix;
> rinse and repeat cycle doesn't work at all for maybe 1/3 of packages,
> and another 1/3 occasionally fail when something goes wrong during the
> patch / build process.
This is a policy violation and people are filing bug reports about such
problems. Still, I've always seen that as "more work for nothing" because
of the same reasons as you. The feature of exporting the build tree in 
{svn,git}-buildpackage is a blessing and I always use it for packages that
use those tools, including all of mine.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Johannes Schauer]

Hi Mattia,

Quoting Mattia Rizzolo (2017-01-09 11:27:30)
> On Sun, Jan 08, 2017 at 01:05:37PM +0100, Johannes Schauer wrote:
> > Mattia, please see below for a pbuilder-specific question.
> 
> Thanks for CCing me; I'm not following this thread anymore (as it
> surpassed the threshold above which I stop to dedicate my time to it),
> so please CC me if you need my input on anything.

then you should probably instruct your mailer to not exclude you from the
Mail-Followup-To header. :)

> > I'm not very familiar with pbuilder. Looking at the man page it seems that
> > pbuilder itself exclusively accepts a source package .dsc and for building
> > a source directory one needs the pdebuild wrapper?
> 
> Exactly.
> 
> just calling plain `pdebuild` without any option will (roughly) call
>   1. dpkg-buildpackage -S -d -us -uc -rfakeroot $other_user_options
>   2. sudo pbuilder build $some_options $user_options ../$pkg_$ver.dsc
> 
> > If that is the case, then it seems sensible for sbuild to do the same as
> > pdebuild if given a source directory only. Both tools should behave the same
> > way when executed in the same context, I think.
> 
> I don't understand what you're planning to do to sbuild.
> 
> > Are there any reasons against this plan? (targeting Buster)
> 
> And I haven't understood what "this plan" is, either.
> FYI, James asked me whether I was fine to move from that
> `dpkg-buildpackage` invocation to call `dpkg-source` instead (with the
> --before-build and --after-build things too), and my only concerns is
> people who are relying on finding a _source.changes in '..'.
> My current workflow is basically calling `pdebuild` in a source tree
> and if the build works `debsign ../$pkg_$ver_source.changes` and then
> dput it (not that my BUILDRESULT is a directory elsewhere that I clean
> often).  I don't think what I'm doing is exotic enough to be fine disrupting
> it.

hrm... this is even more confusing now. Okay, let me give some context.

Thibaut pointed out that it would be cool if sbuild would revert the patches
after building with sbuild to which James replied that this is something that
pdebuild by default. So I wanted to get more details about what pdebuild is
doing with respect to how it leaves the unpacked source directory after
building the source package so that we can have sbuild do the same thing.

Now reading the pdebuild source code it indeed seems that pdebuild is using
'dpkg-buildpackage -S -d' instead of using 'dpkg-source -b' as sbuild does.
From reading the dpkg-buildpackage code, it seems that that one is doing:

$ dpkg-source --before-build .
$ dpkg-source -b .
$ dpkg-source --after-build .

which is what takes care of the patches independent in which state they were.
On the other hand, using dpkg-buildpackage also creates a changes file, a
buildinfo file and tries to sign the whole kaboodle. So maybe both tools are
wrong and pbuilder should replace 'dpkg-buildpackage -S -d' with above three
dpkg-source invocations while sbuild should add the --before-build and
--after-build invocations?

What do the dpkg developers think?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Feedback on 3.0 source format problems

[Adam D. Barratt]

On Mon, 2017-01-09 at 21:01 +0100, Johannes Schauer wrote:
> Hi,
> 
> Quoting Ian Jackson (2017-01-09 18:33:51)
> > Johannes Schauer writes ("Re: Feedback on 3.0 source format problems"):
> > > Sbuild could do this cleanup itself if there was a way to
> > > automatically determine whether the user would like their tree to be
> > > patches applied or unapplied.
> > 
> > This would have to be some kind of (perhaps package-specific) personal
> > configuration, I think.
> 
> is that what debian/source/local-options is about?
> 
> The only docs I find about it are:
> 
> https://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcel

dkpg-source(1), as referenced from the URL above.

Regards,

Adam

Re: Feedback on 3.0 source format problems

[Russell Stuart]

On Mon, 2017-01-09 at 17:33 +, Ian Jackson wrote:
> All of this applying and unapplying of patches around build
> operations is complete madness if you ask me - but I don't see a
> better approach given the constraints.  dgit sometimes ends up doing
> this (and moans about it), which is even madder given that dgit has
> git to help it out.

To state the bleeding obvious, it arises because on day 1 Debian
decided to do the builds in the original source tree, then tries to
recover the original source at the end by running "debian/rules clean".
 When I moved from rpm's to deb over a decade ago, I was surprised by
this.  Rpm's create temp build directory, so the "debian/rules clean"
step can be handled reliably 100% of the time by the rpm build tool.
Debian insisting you write it creates extra work.  But when in Rome do
as the Romans do and all that.

Later when I started to work on other peoples packages it became
apparent that many of the Romans didn't bother with it.  So the
debian/rules binary; dpkg --install; test; debian/rules clean; fix;
rinse and repeat cycle doesn't work at all for maybe 1/3 of packages,
and another 1/3 occasionally fail when something goes wrong during the
patch / build process.

When it goes wrong your only option is "rm -r; dpkg-source -x; manually
reapply your changes" which is tedious, error prone, and for me least
conducive to losing a days work.  It is indeed utter madness that over
a decade later we still allow this work flow. 

signature.asc
Description: This is a digitally signed message part

Re: Feedback on 3.0 source format problems

[Johannes Schauer]

Hi,

Quoting Ian Jackson (2017-01-09 18:33:51)
> Johannes Schauer writes ("Re: Feedback on 3.0 source format problems"):
> > Sbuild could do this cleanup itself if there was a way to
> > automatically determine whether the user would like their tree to be
> > patches applied or unapplied.
> 
> This would have to be some kind of (perhaps package-specific) personal
> configuration, I think.

is that what debian/source/local-options is about?

The only docs I find about it are:

https://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcel

> > I do not even know of a way to determine upfront whether a source
> > tree is patches applied or unapplied (that check has to be
> > independent of the source format).
> 
> This is, in the general case, clearly impossible.  As a simple
> example, consider the result of the following:
> 
>   # .oO{ somepackage is broken }
>   dgit clone somepackage && cd somepackage
>   # .oO{ hrm I wonder why it is broken - oh there is only one patch }
>   # .oO{ oh the breakage is in the busted patch "add zorkmids" }
>   git revert -n :/'add zorkmids'
>   git commit
> 
> Now the tree is exactly identical to a patches-unapplied tree.  But
> the user wanted it to drop the patch.  Tools should not reapply it.

Then maybe I don't understand or there is at least some confusion about what
pdebuild is doing. At least from James' email I understand that it is trying to
somehow restore the original state (whether it was patches applied or patches
unapplied) by calling:

 $ dpkg-source --before-build .
 $ dpkg-source -b .
 $ dpkg-source --after-build .

It would be great if somebody could clarify all this and maybe help get us to a
state where we can have the involved tools all do the same sensible thing
independent of the source package format and packaging workflow.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Feedback on 3.0 source format problems

[Sean Whitton]

On Mon, Jan 09, 2017 at 01:25:44PM +, Ian Jackson wrote:
> Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
> >  My first worry is that pseudomerges are weird.  In fact, I've never
> > seen them outside of weird Debian git workflows :) Someone might
> > look at the interchange view, see all these pseudomerges, and have
> > no idea how to interpret what the Debian maintainer is doing.  Do
> > you have any thoughts on mitigating the potential confusion?
> 
> I think it might be useful to have an option to git-rev-list to
> disregard non-contributing edges of pseudomerges.  That would mean you
> could see the results in `gitk'.

That would be really cool.

> > The advantage of thinking of the Debian packaging as just another
> > branch of development is that the branching structure itself is easy
> > to interpret for anyone who uses git.  "Ah, I see they merged my
> > release tag into their branch, they must have been bringing Debian
> > up-to-date with the latest release" -- this is very natural for git
> > users.  We call it "packaging a new upstream release" but it's
> > easier for an outsider to think of it as bringing a feature branch
> > up-to-date with the latest mainline developments.
> 
> I can see why you might think this.  But this really does depend on
> how big the delta is from upstream.

Agreed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Johannes Schauer writes ("Re: Feedback on 3.0 source format problems"):
> Sbuild could do this cleanup itself if there was a way to
> automatically determine whether the user would like their tree to be
> patches applied or unapplied.

This would have to be some kind of (perhaps package-specific) personal
configuration, I think.

> I do not even know of a way to determine upfront whether a source
> tree is patches applied or unapplied (that check has to be
> independent of the source format).

This is, in the general case, clearly impossible.  As a simple
example, consider the result of the following:

  # .oO{ somepackage is broken }
  dgit clone somepackage && cd somepackage
  # .oO{ hrm I wonder why it is broken - oh there is only one patch }
  # .oO{ oh the breakage is in the busted patch "add zorkmids" }
  git revert -n :/'add zorkmids'
  git commit

Now the tree is exactly identical to a patches-unapplied tree.  But
the user wanted it to drop the patch.  Tools should not reapply it.

> This also brings me to a question about the --unapply-patches option. The man
> page says:

All of this applying and unapplying of patches around build operations
is complete madness if you ask me - but I don't see a better approach
given the constraints.  dgit sometimes ends up doing this (and moans
about it), which is even madder given that dgit has git to help it
out.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
> I take it that only the maintainer is meant to look at the
> merging-baseline, and everyone else looks at the interchange view.

Anyone wanting to look at the patch stack can look at the interchange
view.  git blame, and git log, for example, will show:
  * For unchanged upstream files, the upstream history
  * For debian/ files (except patches), the Debian merging history
  * For changed upstream files, the upstream history followed
by a commit representing the most recent version of each patch

>  My first worry is that pseudomerges are weird.  In fact, I've never
> seen them outside of weird Debian git workflows :) Someone might
> look at the interchange view, see all these pseudomerges, and have
> no idea how to interpret what the Debian maintainer is doing.  Do
> you have any thoughts on mitigating the potential confusion?

I think it might be useful to have an option to git-rev-list to
disregard non-contributing edges of pseudomerges.  That would mean you
could see the results in `gitk'.

> The advantage of thinking of the Debian packaging as just another branch
> of development is that the branching structure itself is easy to
> interpret for anyone who uses git.  "Ah, I see they merged my release
> tag into their branch, they must have been bringing Debian up-to-date
> with the latest release" -- this is very natural for git users.  We call
> it "packaging a new upstream release" but it's easier for an outsider to
> think of it as bringing a feature branch up-to-date with the latest
> mainline developments.

I can see why you might think this.  But this really does depend on
how big the delta is from upstream.  People who are used to doing
significant upstream development in projects managed in a
`traditional' way, rather than `just press the big "merge" button'
style, will want to see a patch stack.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Mattia Rizzolo]

On Sun, Jan 08, 2017 at 01:05:37PM +0100, Johannes Schauer wrote:
> Mattia, please see below for a pbuilder-specific question.

Thanks for CCing me; I'm not following this thread anymore (as it
surpassed the threshold above which I stop to dedicate my time to it),
so please CC me if you need my input on anything.

> I'm not very familiar with pbuilder. Looking at the man page it seems that
> pbuilder itself exclusively accepts a source package .dsc and for building a
> source directory one needs the pdebuild wrapper?

Exactly.

just calling plain `pdebuild` without any option will (roughly) call
  1. dpkg-buildpackage -S -d -us -uc -rfakeroot $other_user_options
  2. sudo pbuilder build $some_options $user_options ../$pkg_$ver.dsc

> If that is the case, then it seems sensible for sbuild to do the same as
> pdebuild if given a source directory only. Both tools should behave the same
> way when executed in the same context, I think.

I don't understand what you're planning to do to sbuild.

> Are there any reasons against this plan? (targeting Buster)

And I haven't understood what "this plan" is, either.
FYI, James asked me whether I was fine to move from that
`dpkg-buildpackage` invocation to call `dpkg-source` instead (with the
--before-build and --after-build things too), and my only concerns is
people who are relying on finding a _source.changes in '..'.
My current workflow is basically calling `pdebuild` in a source tree
and if the build works `debsign ../$pkg_$ver_source.changes` and then
dput it (not that my BUILDRESULT is a directory elsewhere that I clean
often).  I don't think what I'm doing is exotic enough to be fine
disrupting it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello Ian,

On Fri, Jan 06, 2017 at 03:29:38PM +, Ian Jackson wrote:
> Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
> > Could you explain in general terms the difference between the
> > interchange and packaging-only branches
> 
> See modified diagram below.  Are the annotations I have added (and the
> name change) any help ?

Yes, thanks, I think I see most of what's going on now.  Thank you for
taking the time to draw the diagrams.  It's certainly an ingenious use
of git.

I take it that only the maintainer is meant to look at the
merging-baseline, and everyone else looks at the interchange view.  My
first worry is that pseudomerges are weird.  In fact, I've never seen
them outside of weird Debian git workflows :)  Someone might look at the
interchange view, see all these pseudomerges, and have no idea how to
interpret what the Debian maintainer is doing.  Do you have any thoughts
on mitigating the potential confusion?

The advantage of thinking of the Debian packaging as just another branch
of development is that the branching structure itself is easy to
interpret for anyone who uses git.  "Ah, I see they merged my release
tag into their branch, they must have been bringing Debian up-to-date
with the latest release" -- this is very natural for git users.  We call
it "packaging a new upstream release" but it's easier for an outsider to
think of it as bringing a feature branch up-to-date with the latest
mainline developments.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Sun, Jan 8, 2017 at 8:05 PM, Johannes Schauer wrote:

> I'm not very familiar with pbuilder. Looking at the man page it seems that
> pbuilder itself exclusively accepts a source package .dsc and for building a
> source directory one needs the pdebuild wrapper?

Right.

> If that is the case, then it seems sensible for sbuild to do the same as
> pdebuild if given a source directory only. Both tools should behave the same
> way when executed in the same context, I think.

An sdebuild script sounds good to me.

> Are there any reasons against this plan? (targeting Buster)

Longer-term, I think we want debuild and possibly pdebuild to become
just `exec dpkg-buildpackage` so we should probably think about where
the code for this should live.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Johannes Schauer]

Hi all,

Mattia, please see below for a pbuilder-specific question.

Quoting James Clarke (2017-01-08 12:14:07)
> This turns out to be true. Working in a patches-applied tree:
> 
> $ dpkg-source --before-build .
> $ dpkg-source -b .
> $ dpkg-source --after-build .
> 
> leaves the patches applied. Working in a patches-unapplied tree, the
> patches are unapplied during the --after-build. This seems to do exactly
> what you want, with the caveat that, if patches are only *part*-applied,
> they will be completely unapplied by the --after-build, but this seems
> like a very strange edge-case.
> 
> This behaviour is exactly what pdebuild has been doing forever (and
> therefore git-buildpackage --git-pbuilder and others).

I'm not very familiar with pbuilder. Looking at the man page it seems that
pbuilder itself exclusively accepts a source package .dsc and for building a
source directory one needs the pdebuild wrapper?

If that is the case, then it seems sensible for sbuild to do the same as
pdebuild if given a source directory only. Both tools should behave the same
way when executed in the same context, I think.

Are there any reasons against this plan? (targeting Buster)

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Feedback on 3.0 source format problems

[James Clarke]

On Sun, Jan 08, 2017 at 01:53:51AM +0100, Johannes Schauer wrote:
> Quoting Thibaut Paumard (2017-01-07 07:12:59)
> > I manage my patches using quilt. I would really prefer if sbuild et al.
> > would revert the patches after building by default, but that's life. I
> > respect that other people have other views.
>
> you could always file a wishlist bug against sbuild with your feature request.
> ;)
>
> I guess you are using sbuild from within an unpacked source package?
>
> The input for sbuild is always a source package. If all you give to sbuild is 
> a
> directory, then it first needs to create that source package. It uses
> "dpkg-source -b ." for this purpose. It is dpkg-source which applies the
> patches.
>
> What you could already do today with sbuild is to say:
>
> sbuild --pre-build-commands="dpkg-source --after-build $(pwd)" ...
>
> You can also put this into your ~/.sbuildrc but that would then prevent you
> from using sbuild outside of unpacked source package directories.
>
> Sbuild could do this cleanup itself if there was a way to automatically
> determine whether the user would like their tree to be patches applied or
> unapplied. I do not even know of a way to determine upfront whether a source
> tree is patches applied or unapplied (that check has to be independent of the
> source format). Heck, with quilt, the source tree could even have patches half
> applied. I'm not so sure how fragile it will be to let sbuild try to put your
> source directory back into the state that it found it.

dpkg-source can almost do this for you; see later :)

> This also brings me to a question about the --unapply-patches option. The man
> page says:
>
>--no-unapply-patches, --unapply-patches
>   By  default,  dpkg-source will automatically unapply the patches
>   in  the  --after-build  hook  if  it  did  apply   them   during
>   --before-build(--unapply-patchessincedpkg1.15.8,
>   --no-unapply-patches since dpkg 1.16.5).   Those  options  allow
>   you  to  forcefully  disable  or  enable the patch unapplication
>   process.Thoseoptions are only allowed in
>   debian/source/local-options   so   that   all  generated  source
>   packages have the same behavior by default.
>
> Is --before-build not also run when using --build? That patches are applied
> when using --build indicates to me that it is.

No, it's not, but per dpkg-source(1) you can see that for 3.0 (quilt),
both --before-build and --build apply patches.

> But the --unapply-patches option
> seems to have no effect when used with --build. So is there a way to apply and
> unapply patches with a single dpkg-source call?

No, there isn't. The standard invocation by dpkg-buildpackage -S is:

dpkg-source --before-build .
fakeroot debian/rules clean
dpkg-source -b .
dpkg-source --after-build .
(also dpkg-gencontrol and dpkg-genbuildinfo)

> And if --unapply-patches does
> not have any effect together with --build, why do I not get a warning on the
> command line about this?

Wishlist bug against dpkg? :)

> And then there is the mysterious hint about
> debian/source/local-options which doesn't increase my understanding of the
> matter

Indeed, but they seem to work when given on the command-line for
--after-build.

Now, if you look at the --(no-)unapply-patches description, you will see

> By default, dpkg-source will automatically unapply the patches in the
> --after-build hook if it did apply them during --before-build

This turns out to be true. Working in a patches-applied tree:

$ dpkg-source --before-build .
$ dpkg-source -b .
$ dpkg-source --after-build .

leaves the patches applied. Working in a patches-unapplied tree, the
patches are unapplied during the --after-build. This seems to do exactly
what you want, with the caveat that, if patches are only *part*-applied,
they will be completely unapplied by the --after-build, but this seems
like a very strange edge-case.

This behaviour is exactly what pdebuild has been doing forever (and
therefore git-buildpackage --git-pbuilder and others).

Regards,
James

Re: Feedback on 3.0 source format problems

[Ritesh Raj Sarraf]

On Mon, 2017-01-02 at 12:36 +, Sean Whitton wrote:
> Dear Josh,
> 
> On Mon, Jan 02, 2017 at 03:25:29AM -0800, Josh Triplett wrote:
> > Currently working on some improvements in that direction, to separate
> > repository format from workflow.
> 
> I'd like to encourage you to read my dgit-maint-merge(7) workflow
> tutorial.  Perhaps the work to which you refer could result in some
> improvements to what I wrote there.  Thanks in advance.

Thank you very much for creating and mentioning about such tutorials. I wasn't
aware of them. I'm going to try some of the exampled workflows.


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part

Re: Feedback on 3.0 source format problems

[Johannes Schauer]

Hi,

Quoting Thibaut Paumard (2017-01-07 07:12:59)
> I manage my patches using quilt. I would really prefer if sbuild et al.
> would revert the patches after building by default, but that's life. I
> respect that other people have other views.

you could always file a wishlist bug against sbuild with your feature request.
;)

I guess you are using sbuild from within an unpacked source package?

The input for sbuild is always a source package. If all you give to sbuild is a
directory, then it first needs to create that source package. It uses
"dpkg-source -b ." for this purpose. It is dpkg-source which applies the
patches.

What you could already do today with sbuild is to say:

sbuild --pre-build-commands="dpkg-source --after-build $(pwd)" ...

You can also put this into your ~/.sbuildrc but that would then prevent you
from using sbuild outside of unpacked source package directories.

Sbuild could do this cleanup itself if there was a way to automatically
determine whether the user would like their tree to be patches applied or
unapplied. I do not even know of a way to determine upfront whether a source
tree is patches applied or unapplied (that check has to be independent of the
source format). Heck, with quilt, the source tree could even have patches half
applied. I'm not so sure how fragile it will be to let sbuild try to put your
source directory back into the state that it found it.

This also brings me to a question about the --unapply-patches option. The man
page says:

   --no-unapply-patches, --unapply-patches
  By  default,  dpkg-source will automatically unapply the patches
  in  the  --after-build  hook  if  it  did  apply   them   during
  --before-build(--unapply-patchessincedpkg1.15.8,
  --no-unapply-patches since dpkg 1.16.5).   Those  options  allow
  you  to  forcefully  disable  or  enable the patch unapplication
  process.Thoseoptions are only allowed in
  debian/source/local-options   so   that   all  generated  source
  packages have the same behavior by default.

Is --before-build not also run when using --build? That patches are applied
when using --build indicates to me that it is. But the --unapply-patches option
seems to have no effect when used with --build. So is there a way to apply and
unapply patches with a single dpkg-source call? And if --unapply-patches does
not have any effect together with --build, why do I not get a warning on the
command line about this? And then there is the mysterious hint about
debian/source/local-options which doesn't increase my understanding of the
matter

Thoughts?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Feedback on 3.0 source format problems

[Thibaut Paumard]

Le 07/01/2017 à 22:10, Nikolaus Rath a écrit :
> On Jan 07 2017, Thibaut Paumard <thibaut.paum...@obspm.fr> wrote:
>> Well, just to say, I'm personally quite happy with '3.0 (quilt)'. I try
>> to maintain all my packages in git in unapplied state, because in my
>> opinion this is the sensible thing to do. When I do a
>>   git diff upstream master
>> I want to see only debian/ in there.
> 
> What's the point of that? If the only difference is the addition of the
> debian/ directory, you can simply look at the debian directory. There's
> no need to use git.

The point is to make sure I don't make changes to upstream by mistake.

>> I much prefer to check a diff of diff over a simple diff,
> 
> Wow, ok. That is astonishing to hear, but I'll take your word for it.

The goal is to check that all my changes to the packaging are
intentional, again. I find it easier this way, I appreciate other people
find it easier the other way round.

>> For me the patch is the final product, I like the clear separation
>> between upstream and debian/, so it's for me a very appealing design to
>> have individual patches in debian/patches. I use git to keep the history
>> of the patch, not to manage it.
> 
> And so is this. Well, I definitely learned something new in this thread.

Me too. My point is that this thread encourages criticism of the 3.0
source format. Most participants in this thread are not quite happy (or
quite unhappy?) with this format, but like often presumably people who
*are* happy with the format will not speak up.

I would not like the readers of the thread to come to the conclusion
that the majority is unhappy with the format, because it's not a poll.

My "Feedback on 3.0 source format problems" is that I have nothing to
declare. I take note of the various tools that have been mentioned and
will look at whether they can enhance my packaging experience when time
permits...

Kind regards, Thibaut.

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 07 2017, Thibaut Paumard  wrote:
> Well, just to say, I'm personally quite happy with '3.0 (quilt)'. I try
> to maintain all my packages in git in unapplied state, because in my
> opinion this is the sensible thing to do. When I do a
>   git diff upstream master
> I want to see only debian/ in there.

What's the point of that? If the only difference is the addition of the
debian/ directory, you can simply look at the debian directory. There's
no need to use git.

> I much prefer to check a diff of diff over a simple diff,

Wow, ok. That is astonishing to hear, but I'll take your word for it.

> For me the patch is the final product, I like the clear separation
> between upstream and debian/, so it's for me a very appealing design to
> have individual patches in debian/patches. I use git to keep the history
> of the patch, not to manage it.

And so is this. Well, I definitely learned something new in this thread.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Thibaut Paumard writes ("Re: Feedback on 3.0 source format problems"):
> I'm not interested at the moment in dgit or other wrappers because
>  1- they seem to me to add complexity to the process;
>  2- I prefer to understand what I'm doing.

Those are good reasons.  (And I'm trying to make them a bit less
true.)  But:

dgit users (including downstreams) who use `dgit clone' to get your
packages will appreciate it if you used `dgit push', because they will
get (a slightly modified version of) your history, rather than just
imports of .dsc's.

Of course that's not of very much direct benefit to you.

> Well, just to say, I'm personally quite happy with '3.0 (quilt)'. I try
> to maintain all my packages in git in unapplied state,

This is supported by dgit.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Thibaut Paumard]

Le 06/01/2017 à 16:37, Ian Jackson a écrit :
> Sebastian Andrzej Siewior writes ("Re: Feedback on 3.0 source format 
> problems"):
>> On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
>>> Looked at another way, it is trying to be a version control system,
>>> layered on top of the Debian archive.  But it is only about a quarter
>>> of a VCS.  There are no formal interfaces to do proper VCS operations.
>>> If there is a formal interface, it is quilt(1) (which is itself very
>>> poor.  NB that is not quilt's fault: quilt inevitably has a hard job
>>> because can't make enough assumptions).
>>
>> there quilt push, pop and header which seems enough.
> 
> Well, it seems you don't really think so :-), because:
> 
>> I usually have git-dpm which creates the quilt series and I try to
>> keep patches documented.
> 
> So you are using git operations to manipulate your patch stack.
> git-dpm is one of the tools we have which lets you do that.

Well, just to say, I'm personally quite happy with '3.0 (quilt)'. I try
to maintain all my packages in git in unapplied state, because in my
opinion this is the sensible thing to do. When I do a
  git diff upstream master
I want to see only debian/ in there. I much prefer to check a diff of
diff over a simple diff, because most of the time I want to see what
changed in the packaging, not in the final state. When I want to do the
later, I use debdiff.

For me the patch is the final product, I like the clear separation
between upstream and debian/, so it's for me a very appealing design to
have individual patches in debian/patches. I use git to keep the history
of the patch, not to manage it.

I manage my patches using quilt. I would really prefer if sbuild et al.
would revert the patches after building by default, but that's life. I
respect that other people have other views.

I'm not interested at the moment in dgit or other wrappers because
 1- they seem to me to add complexity to the process;
 2- I prefer to understand what I'm doing.

Kind regards, Thibaut.

-- 
* Dr Thibaut Paumard   | LESIA/CNRS - Table équatoriale (bât. 5)   *
* Tel: +33 1 45 07 78 60   | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17   | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France)   *



smime.p7s
Description: Signature cryptographique S/MIME

Re: Feedback on 3.0 source format problems

[gregor herrmann]

On Fri, 06 Jan 2017 15:37:48 +, Ian Jackson wrote:

> I think only a minority of people are actually using quilt on
> debian/patches.

I have a different impression (but no proof either of course).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Die Quote: Tonight


signature.asc
Description: Digital Signature

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Ian Jackson writes ("Re: Feedback on 3.0 source format problems"):
>   !   NMUer's HEAD was here when they said `dgit push'.
>   Rebase branch launderer turns each ! into an
>   equivalent *.

I mean it turns each % into an equivalent *, but it work on !s too.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Sebastian Andrzej Siewior writes ("Re: Feedback on 3.0 source format problems"):
> On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
> > Looked at another way, it is trying to be a version control system,
> > layered on top of the Debian archive.  But it is only about a quarter
> > of a VCS.  There are no formal interfaces to do proper VCS operations.
> > If there is a formal interface, it is quilt(1) (which is itself very
> > poor.  NB that is not quilt's fault: quilt inevitably has a hard job
> > because can't make enough assumptions).
> 
> there quilt push, pop and header which seems enough.

Well, it seems you don't really think so :-), because:

> I usually have git-dpm which creates the quilt series and I try to
> keep patches documented.

So you are using git operations to manipulate your patch stack.
git-dpm is one of the tools we have which lets you do that.

> > I think if we want to be storing patch queues we should be doing so in
> > a real version control system.  Indeed, most people are doing that.
> > For now many people are using `3.0 (quilt)' as an interchange format,
> > but ideally we would switch to a useable git workflow that did a
> > similar thing, and then we could use git as our history interchange
> > format.
> 
> I read this a few times in this thread that people want the patches in a
> VCS. I never saw this a missing feature or requirement on my side.
...
> I can't think of an example where having a patch history somewhere else
> than within the patch itself is useful. My thinking is probably limited
> by my workflow :) Would you have an example where and how this could be
> usefull?

You have misunderstood, I think.  I don't mean (and I think most
other people don't mean) that they want the history _of_ a patch.
That is, we aren't saying we want to look at the output of
`git blame debian/patches/01-sponge.patch'.

Rather, we think manipulating a stack of patches is much easier if one
converts the patches to a git branch, with each patch becoming a
commit (using a tool morally equivalent to git-am, such as gbp pq
import).

Naturally that doesn't end up recording a history _of_ the patches,
because the patches _become_ `the history'.  Then one manipulates the
patches with git-rebase (or similar tools), git-commit,
git-cherry-pick, etc.

Finally, when doing an upload, one converts the git branch back into
patches (with a tool morally equivalent to git-format-patch).

I think only a minority of people are actually using quilt on
debian/patches.

Regards,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
> Could you explain in general terms the difference between the
> interchange and packaging-only branches

See modified diagram below.  Are the annotations I have added (and the
name change) any help ?

>  Does the packaging-only branch contain debian/ alone?

No, it also contains a complete unmodified copy of the upstream code.
(Except that if upstream had a debian/ directory, it is completely
replaced.)  Perhaps this is the wrong name.  Let's try
`merging-baseline'

For `3.0 (quilt)' the merging-baseline branch contains roughly what
you would get if you untarred the origs and the debian.tar.gz, and
then deleted all the patches without applying them.

Not shown on the diagram is the commit `add patch queue to
debian/patches', which would be needed for `3.0 (quilt)'.  This is
because the diagram is in terms of a sane source format, not `3.0
(quilt)'.  For use with quilty sources, there would be such a commit
(probably dgit-generated) on top of the actual upstream change
commits:

   --/--A!/--B3!--%--/--> interchange view
//  /  with debian/ directory
   %%  %   all upstream changes applied
  //  /3.0 (quilt) has debian/patches
 /2* 2*
//  /
   2*   2  2
  //  /
 11  1`merging-baseline' branch
//  / unmodified upstream code
---p-p--Ap--B--C-->   plus debian/ (but no debian/patches)
  / /   /
   --#-#---#-> upstream

Key:

  1,2,3   commits touching upstream files only
  A,B,C   commits touching debian/ only
  B3  mixed commit (eg made by an NMUer)
  #   upstream releases

 -p-  special merge, takes contents of debian/ from the
 / previous `merging-baseline' commit and rest from upstream

 -/-  pseudomerge; contents are identical to
 / parent lower on diagram.

  %   dgit-generated commit of debian/patches.
  `3.0 (quilt)' only; dropped by rebase tool.

  *   Maintainer's HEAD was here while they were editing,
  before they said they were done, at which point their
  tools generated [% and] -/- commit[s] to convert to
  the fast-forwarding interchange branch.  (Maybe the
  tooling is simply `dgit push'.)

  !   NMUer's HEAD was here when they said `dgit push'.
  Rebase branch launderer turns each ! into an
  equivalent *.

Ian.

--
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Matthieu Caneill]

Hi Sean,

On Thu, Jan 05, 2017 at 01:05:54PM -0700, Sean Whitton wrote:
> On Wed, Jan 04, 2017 at 03:10:16AM +0100, gregor herrmann wrote:
> > https://sources.debian.net/patches/ goes in that direction. AFAIK it
> > might not be complete and TTBOMK it hasn't been announced widely but
> > it exists and (I think) works for "3.0 (quilt)" packages.
> > 
> > For an example of a package using git-debcherry cf.
> > https://sources.debian.net/patches/libmodule-build-perl/0.422000-1/
> 
> Just to confirm, are you saying that sources.debian.net/patches would
> execute git-debcherry on a 3.0 (quilt) package using
> single-debian-patch, presumably by cloning Vcs-Git?  Does this have to
> be explicitly requested for that package?

No, sources.debian.net/patches is not aware of any VCS. It parses on
the fly the series and the patches of a package (and only for
3.0 (quilt) presently). Still, this allows having URLs to point
upstream to, for released packages.

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello Ian,

On Wed, Jan 04, 2017 at 12:08:57PM +, Ian Jackson wrote:
> git-dpm sort of does this.  I have been experimenting with and
> blundering towards another approach, which is closer to raw git.
> 
> Something like this:
> 
>--/--A-/---B3---/--> interchange view
> ///
>//3
>   ///
>  222
> ///
>111
>   ///
> ---p-p--Ap---B---> `packaging-only' branch
>   / / /
>--#-#---#-> upstream

Could you explain in general terms the difference between the
interchange and packaging-only branches?  Does the packaging-only branch
contain debian/ alone?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello,

On Tue, Jan 03, 2017 at 06:48:10PM -0800, Nikolaus Rath wrote:
> I'd think that anything that's relevant for upstream development is
> forwarded to upstream by the maintainer in whatever format upstream
> prefers. This requires extra time, but I would be surprised to hear if
> there are maintainers that have sufficient time to create patches that
> are suitable for upstream, but don't have the little extra time to send
> them upstream.

On Wed, Jan 04, 2017 at 02:47:36PM +1000, Russell Stuart wrote:
> This is not a novel requirement.  Most projects I've worked with insist
> you rebase your patches.  This is not new.  Before git they insisted
> your patches applied cleanly - which amounts to the same thing. 
> Breaking up large patches into a series of smaller independent patches
> each with a simple and documented purpose isn't an unusual requirement
> either.

Indeed.  When forwarding a patch upstream, you'll need to ensure it
applies cleanly.  The easiest way is to start a new branch based on the
current upstream HEAD, and cherry-pick your commit onto it.  git
minimises the amount of manual resolution required.

On Wed, Jan 04, 2017 at 10:28:10PM +0100, Sebastian Andrzej Siewior wrote:
> I can't think of an example where having a patch history somewhere else
> than within the patch itself is useful. My thinking is probably limited
> by my workflow :) Would you have an example where and how this could be
> usefull?

In most cases, when you merge a new upstream release, git transparently
handles dropping and refreshing patches, which saves a lot of time.  For
example, after forwarding a patch upstream as I just described, merging
a new upstream release will not usually result in any conflicts, even if
the cherry-pick required manual resolution.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello gregor,

On Wed, Jan 04, 2017 at 03:10:16AM +0100, gregor herrmann wrote:
> On Tue, 03 Jan 2017 20:15:10 +, Sean Whitton wrote:
> 
> > On Tue, Jan 03, 2017 at 10:54:07AM -0800, Russ Allbery wrote:
> > > Well, if we had one more thing: a patches.debian.org service that would
> > > show the git-debcherry-extracted patches against upstream.  I really like
> > > being able to just point upstream at all the patches relevant to them that
> > > Debian has applied.
> > That would be great.  Then the git-debcherry series would be available
> > for those that want it, without requiring package maintainers to do any
> > curation at all.
> 
> https://sources.debian.net/patches/ goes in that direction. AFAIK it
> might not be complete and TTBOMK it hasn't been announced widely but
> it exists and (I think) works for "3.0 (quilt)" packages.
> 
> For an example of a package using git-debcherry cf.
> https://sources.debian.net/patches/libmodule-build-perl/0.422000-1/

Just to confirm, are you saying that sources.debian.net/patches would
execute git-debcherry on a 3.0 (quilt) package using
single-debian-patch, presumably by cloning Vcs-Git?  Does this have to
be explicitly requested for that package?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Jonathan Dowland]

On Wed, Jan 04, 2017 at 10:28:10PM +0100, Sebastian Andrzej Siewior wrote:
> On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
> > Looked at another way, it is trying to be a version control system,
> > layered on top of the Debian archive.  But it is only about a quarter
> > of a VCS.  There are no formal interfaces to do proper VCS operations.
> > If there is a formal interface, it is quilt(1) (which is itself very
> > poor.  NB that is not quilt's fault: quilt inevitably has a hard job
> > because can't make enough assumptions).
> 
> there quilt push, pop and header which seems enough.

quilt is not a hard dependency of dpkg-dev, but the abstraction is quite leaky
without it: if you try to build a 3.0 (quilt) package without having quilt,
dpkg-buildpackage will apply the patches fine, but if something breaks and
you have a half-built tree, things are pretty messy and I often rely on rm -rf
.pc and git reset (when I have the advantage of working in a git repository)
to get back to a buildable source.

I'd much prefer if it the state of a build tree after 'dpkg-buildpackage'
could be wound back without relying on external (or non-depended) tools, it
would help me feel that the tool was well rounded and internally consistent.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: Feedback on 3.0 source format problems

[Brian May]

Nikolaus Rath  writes:

>> I have had to sort out the mess when the Debian package upload
>> did not match my git tree because another maintainer didn't correctly
>> merge in my changes.
>
> I don't understand... how does a Debian package upload affect any of the
> work on your git-dpm tree?

I can't remember the exact details now. However I suspect that some
people get so frustrated with git dpm problems and end up using "git
push -f" to fix them up. I think a maintainer may have missed the fact
that I had made changes, and did a "git push -f" without noticing he was
creating a new fork without my changes. Which caused no end of confusion
- I can see my changes in my git tree, but they didn't appear in Debian
upload.

I think the problems git-dpm can create can result in bad habbits - with
people rushing to fix problems without understanding what the underlying
cause was, that can lead to this sort of thing.
-- 
Brian May 

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 05 2017, Brian May  wrote:
> Vincent Bernat  writes:
>
>> There have been a lot of complaints about it. For me, it is a pain to
>> use. Its integration with gbp is poor, it produces a messy history when
>> you are working on your patches and I often run into problems with
>> .debian/.git-dpm file it maintains (import a new upstream, make some
>> changes, notice that somebody else also pushed a change, pull --rebase,
>> everything is broken). Since we started using it, we opened a lot of bug
>> reports and not a single one of them has been fixed. I think that nobody
>> wants to work on it because it is an extremely fragile tool and the
>> first one to try to fix it will inherit of all the problems to solve.
>
> It also has a number of bugs that are not getting fixed.

Yeah, I think we heard before that git-dpm is not being maintained. I
said it, Vincent said it in his reply, and now you are saying it
again. No one is disputing the point.

> Plus if conflicts occur because multiple people unexpectedly make
> changes at the same time it (i.e. you can't push because somebody else
> already pushed changes) can be a world of confusion trying to sort out
> the mess.

Yes, it is a mess. But I don't think it's any worse than having to
resolve conflicts in debian/patches/, which is the equivalent problem
when multiple people use gbp at the same time.

> I have had to sort out the mess when the Debian package upload
> did not match my git tree because another maintainer didn't correctly
> merge in my changes.

I don't understand... how does a Debian package upload affect any of the
work on your git-dpm tree?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Russ Allbery]

Brian May  writes:

> No, my understanding that is git pq is something quite different, and
> does not maintain the history of changes in git - except by commiting
> the debian/patches/* files. It is a while since I looked at this in
> depth however.

That's correct.  gbp pq is equivalent to maintaining the upstream patches
as a Git branch that you rebase against each new upstream version.  You
retain some history of changes to those commits (unlike a pure git rebase
branch) in commit messages of the exported patches, but only as the commit
messages on commits of diffs (so not hugely human-readable).

> "gbp pq" is probably way better then using quilt however.

I like it because quilt is a fairly primitive revision control system, so
while it has tools for rebasing patches, they're not very good compared to
git rebase.

-- 
Russ Allbery (r...@debian.org)   

Re: Feedback on 3.0 source format problems

[Brian May]

Vincent Bernat  writes:

> There have been a lot of complaints about it. For me, it is a pain to
> use. Its integration with gbp is poor, it produces a messy history when
> you are working on your patches and I often run into problems with
> .debian/.git-dpm file it maintains (import a new upstream, make some
> changes, notice that somebody else also pushed a change, pull --rebase,
> everything is broken). Since we started using it, we opened a lot of bug
> reports and not a single one of them has been fixed. I think that nobody
> wants to work on it because it is an extremely fragile tool and the
> first one to try to fix it will inherit of all the problems to solve.

It also has a number of bugs that are not getting fixed.

Plus if conflicts occur because multiple people unexpectedly make
changes at the same time it (i.e. you can't push because somebody else
already pushed changes) can be a world of confusion trying to sort out
the mess. I have had to sort out the mess when the Debian package upload
did not match my git tree because another maintainer didn't correctly
merge in my changes.

I believe there is increasing feeling that DPMT should switch away from
git dpm. I think at least one project has already done so. Just nobody
has raised the issue on the mailing list, or come up with an proposal to
change yet.

> Isn't "gbp pq" a correct execution of the same principles?

No, my understanding that is git pq is something quite different, and
does not maintain the history of changes in git - except by commiting
the debian/patches/* files. It is a while since I looked at this in
depth however.

"gbp pq" is probably way better then using quilt however.
-- 
Brian May 

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 04 2017, Vincent Bernat  wrote:
>  ❦  4 janvier 2017 09:47 -0800, Nikolaus Rath  :
>
>> It's surprisingly awkward, and, at least for me, it turns out that
>> externalizing my rebased branch as a patch series solves many of
>> problems surprisingly well.  All the other solutions I can think of
>> require one or more things I don't really want to do: rebase the
>> debian/master branch, not be able to run dpkg-buildpackage from the
>> debian/master branch easily, or require that dpkg-buildpackage do
>> more mucking about with source control than I want it to.
>
>I believe the git-dpm approach would give you everything you want.  The
>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>
>I personally think that technically git-dpm's approach is the best -
>but
>unfortunately the program itself is effectively unmaintained and
>apparently/consequently not used by many people.

 The Debian Python Modules Team (DPMT) has about 1,000 packages with
 git-dpm repositories.  While it took a bit of getting used to and
 there have been a few problems, overall I think it's worked very well.
 It's biggest problem is the lack of a maintainer.
>>>
>>> There have been a lot of complaints about it. For me, it is a pain to
>>> use. Its integration with gbp is poor,
>>
>> Well, I think that is because it is mostly an *alternative* to
>> gbp. Other than gbp dch (which I think should work fine), what features
>> of gbp would you like to use with git-dpm?
>
> gbp import-orig --uscan (the whole import with git-dpm is flawed, there
> are too many ways to fail, like a patch that cannot be rebased and the
> pristine-tar branch is not updated, like the previous upstream was not
> tagged because not released [and git-dpm only tags upstream when master
> is tagged] and it fails in the middle of the process, gbp rollbacks when
> there is a problem).

I agree that's a mess. But I would much rather see the git-dpm import
fixed than interoperability with gbp increased.

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Sebastian Andrzej Siewior]

On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
> Looked at another way, it is trying to be a version control system,
> layered on top of the Debian archive.  But it is only about a quarter
> of a VCS.  There are no formal interfaces to do proper VCS operations.
> If there is a formal interface, it is quilt(1) (which is itself very
> poor.  NB that is not quilt's fault: quilt inevitably has a hard job
> because can't make enough assumptions).

there quilt push, pop and header which seems enough.

> I think if we want to be storing patch queues we should be doing so in
> a real version control system.  Indeed, most people are doing that.
> For now many people are using `3.0 (quilt)' as an interchange format,
> but ideally we would switch to a useable git workflow that did a
> similar thing, and then we could use git as our history interchange
> format.

I read this a few times in this thread that people want the patches in a
VCS. I never saw this a missing feature or requirement on my side. I
usually have git-dpm which creates the quilt series and I try to keep
patches documented. 
Once upstream releases a new version I need to rebase all patches and
this might involve manual handling if the patch(es) don't apply cleanly.
Once that is resolved I have one patch again which I take as-is and can
submit upstream.
I can't think of an example where having a patch history somewhere else
than within the patch itself is useful. My thinking is probably limited
by my workflow :) Would you have an example where and how this could be
usefull?

> 
> Regards,
> Ian.
> 

Sebastian

Re: Feedback on 3.0 source format problems

[Vincent Bernat]

 ❦  4 janvier 2017 09:47 -0800, Nikolaus Rath  :

> It's surprisingly awkward, and, at least for me, it turns out that
> externalizing my rebased branch as a patch series solves many of
> problems surprisingly well.  All the other solutions I can think of
> require one or more things I don't really want to do: rebase the
> debian/master branch, not be able to run dpkg-buildpackage from the
> debian/master branch easily, or require that dpkg-buildpackage do
> more mucking about with source control than I want it to.

I believe the git-dpm approach would give you everything you want.  The
explanation on http://git-dpm.alioth.debian.org/ is pretty good.

I personally think that technically git-dpm's approach is the best -
but
unfortunately the program itself is effectively unmaintained and
apparently/consequently not used by many people.
>>>
>>> The Debian Python Modules Team (DPMT) has about 1,000 packages with
>>> git-dpm repositories.  While it took a bit of getting used to and
>>> there have been a few problems, overall I think it's worked very well.
>>> It's biggest problem is the lack of a maintainer.
>>
>> There have been a lot of complaints about it. For me, it is a pain to
>> use. Its integration with gbp is poor,
>
> Well, I think that is because it is mostly an *alternative* to
> gbp. Other than gbp dch (which I think should work fine), what features
> of gbp would you like to use with git-dpm?

gbp import-orig --uscan (the whole import with git-dpm is flawed, there
are too many ways to fail, like a patch that cannot be rebased and the
pristine-tar branch is not updated, like the previous upstream was not
tagged because not released [and git-dpm only tags upstream when master
is tagged] and it fails in the middle of the process, gbp rollbacks when
there is a problem).
-- 
Few things are harder to put up with than the annoyance of a good example.
-- "Mark Twain, Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 04 2017, Vincent Bernat  wrote:
>  ❦  4 janvier 2017 04:52 GMT, Scott Kitterman  :
>
 It's surprisingly awkward, and, at least for me, it turns out that
 externalizing my rebased branch as a patch series solves many of
 problems surprisingly well.  All the other solutions I can think of
 require one or more things I don't really want to do: rebase the
 debian/master branch, not be able to run dpkg-buildpackage from the
 debian/master branch easily, or require that dpkg-buildpackage do
 more mucking about with source control than I want it to.
>>>
>>>I believe the git-dpm approach would give you everything you want.  The
>>>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>>>
>>>I personally think that technically git-dpm's approach is the best -
>>>but
>>>unfortunately the program itself is effectively unmaintained and
>>>apparently/consequently not used by many people.
>>
>> The Debian Python Modules Team (DPMT) has about 1,000 packages with
>> git-dpm repositories.  While it took a bit of getting used to and
>> there have been a few problems, overall I think it's worked very well.
>> It's biggest problem is the lack of a maintainer.
>
> There have been a lot of complaints about it. For me, it is a pain to
> use. Its integration with gbp is poor,

Well, I think that is because it is mostly an *alternative* to
gbp. Other than gbp dch (which I think should work fine), what features
of gbp would you like to use with git-dpm?

> Since we started using it, we opened a lot of bug reports and not a
> single one of them has been fixed. I think that nobody wants to work
> on it because it is an extremely fragile tool and the first one to try
> to fix it will inherit of all the problems to solve.

Yes, I think that falls under "lack of a maintainer".
>
> Isn't "gbp pq" a correct execution of the same principles?

No, absolutely not.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Tzafrir Cohen]

On Wed, Jan 04, 2017 at 12:53:12PM +, Simon McVittie wrote:

> Joking aside, the attempts I've seen at managing SRPMs in a version
> control system have either not tracked upstream source at all (Fedora), or
> invented a layout that is actually a lot like Debian's but with packaging/
> instead of debian/ (Tizen).

>From what I see, at least some people in Fedora to start putting the
files in version control: tito[1] indeed maintains data in .tito in
addition to the toplevel $PACKAGE.spec file.

[1] https://github.com/dgoodwin/tito

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Re: Feedback on 3.0 source format problems

[Simon McVittie]

On Wed, 04 Jan 2017 at 13:59:26 +0800, Paul Wise wrote:
> On Wed, Jan 4, 2017 at 1:30 PM, Nikolaus Rath wrote:
> > But I am not sure if a package structure like
> >
> > mypkg/upstream/*
> > mypkg/debian/*
> > mypkg/patches/* (?)
> >
> > would have any *practical* benefits over the current situation
> 
> TBH, I haven't thought much about what an alternative should look like.

We could have a directory containing a tarball, some patches, and some
sort of spec for how to build it? I hear some people with brightly-coloured
headgear might have tried this particular design :-P

Joking aside, the attempts I've seen at managing SRPMs in a version
control system have either not tracked upstream source at all (Fedora), or
invented a layout that is actually a lot like Debian's but with packaging/
instead of debian/ (Tizen).

S

Re: Feedback on 3.0 source format problems

[Scott Kitterman]

On January 4, 2017 6:23:23 AM EST, Jonas Smedegaard  wrote:
>Quoting Vincent Bernat (2017-01-04 08:12:08)
>>  ❦  4 janvier 2017 04:52 GMT, Scott Kitterman
> :
>> 
>> >>> It's surprisingly awkward, and, at least for me, it turns out
>that
>> >>> externalizing my rebased branch as a patch series solves many of
>> >>> problems surprisingly well.  All the other solutions I can think
>of
>> >>> require one or more things I don't really want to do: rebase the
>> >>> debian/master branch, not be able to run dpkg-buildpackage from
>the
>> >>> debian/master branch easily, or require that dpkg-buildpackage do
>> >>> more mucking about with source control than I want it to.
>> >>
>> >>I believe the git-dpm approach would give you everything you want. 
>The
>> >>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>> >>
>> >>I personally think that technically git-dpm's approach is the best
>-
>> >>but
>> >>unfortunately the program itself is effectively unmaintained and
>> >>apparently/consequently not used by many people.
>> >
>> > The Debian Python Modules Team (DPMT) has about 1,000 packages with
>> > git-dpm repositories.  While it took a bit of getting used to and
>> > there have been a few problems, overall I think it's worked very
>well.
>> > It's biggest problem is the lack of a maintainer.
>> 
>> There have been a lot of complaints about it. For me, it is a pain to
>> use. Its integration with gbp is poor, it produces a messy history
>when
>> you are working on your patches and I often run into problems with
>> .debian/.git-dpm file it maintains (import a new upstream, make some
>> changes, notice that somebody else also pushed a change, pull
>--rebase,
>> everything is broken). Since we started using it, we opened a lot of
>bug
>> reports and not a single one of them has been fixed. I think that
>nobody
>> wants to work on it because it is an extremely fragile tool and the
>> first one to try to fix it will inherit of all the problems to solve.
>> 
>> Isn't "gbp pq" a correct execution of the same principles?
>> -- 
>> Make your program read from top to bottom.
>> - The Elements of Programming Style (Kernighan & Plauger)
>
>Do _any_ of the systems reliably handle a "git rebase" involving a
>merge 
>of new upstream release?  In my experience gbp also fails that.

My experience with git-dpm, including with packages that have stacked 
patches/commits, is that it's pretty reliable, although not perfect. In the 
end, most, if not all the problems I've had turned out to be pilot error.

Scott K

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Russ Allbery writes ("Re: Feedback on 3.0 source format problems"):
> Even if we never used tarballs, and instead our unit of operation was the
> upstream Git repository plus Debian branches, I would maintain a rebased
> branch of Debian changes to upstream

I think this is definitely the right thing for many packages.

I don't think this depends on the interchange format representing the
changes as patches rather than commits.  At a technical level, they
represent roughly the same information and it is possible to
interconvert.  However:

  * There are many changes that patches cannot represent.

  * git (working with a rebasing branch) is a much more powerful tool
for editing a patch series than quilt or diff/patch or emacs
(working with a series of patches as files).  Ie, patches are a
poor editing format.  Consequently most people actually gateway to
git at the first opportunity, and out again for export.

  * Few people outside Debian work with quilt stacks any more.

All of these things mean that patches are a really poor interchange
format.

The only difficulty is this one:

> This is actually, in a way, *harder* if we were using pure Git, since if I
> have a rebased branch of Debian changes on top of upstream, and I need a
> place to integrate that with Debian packaging, what does that
> debian/master branch look like?  I don't really want it to be a constantly
> rebased branch; I want it to be a conventional branch.  But I want to keep
> merging the changes against upstream into it (but not maintain them on
> that branch, only maintain the Debian packaging files on that branch).

My preferred answer is that it is a constantly rebasing branch topped
with a series of pseudomerges to make it fast-forwarding.

git-dpm sort of does this.  I have been experimenting with and
blundering towards another approach, which is closer to raw git.

Something like this:

 --/--A-/---B3---/--> interchange view
  ///
 //3
///
   222
  ///
 111
///
---p-p--Ap---B---> `packaging-only' branch
  / /   /
   --#-#---#-> upstream

Key:   1,2,3   commits touching upstream files
   A,B commits touching debian/ only
   B3  mixed commit (eg made by an NMUer)
   #   upstream releases

  -p-  special merge, takes contents of debian/
  /  from the previous `packaging only'
 commit and rest from upstream

  -/-  pseudomerge; contents are identical to
  / parent lower on diagram.

Looking from the tip of the interchange view, it is I think always
possible to classify these commits appropriately: pseudomerges are
fairly obvious (if all three trees are identical, we descend to the
parent with the most recent commit date), and the `p' special merge is
the only non-psuedo merge and has a special form.

So it would be possible to write a `git-debian-rebase' tool which
would take (for example) B3, above, and be able to perform functions
like:

 * Strip pseudomerges: Rewrite the current branch so it contains no
   pseudomerges, turning ...B3 into ...p-A-1-2-B3.  (This should make
   a note, in your .git/ somewhere, of the latest pseudomerge to be
   deleted.)

 * Cleanup branch: Reorganise the current branch so that the debian/
   changes come first, turning -p-A-1-2-B3 into ...p-A-B-1-2.

 * New upstream rebase: Start rebasing onto a new upstream version,
   turning ...#...p-A-B-1-2 into ...#'...p'-1-2.  This would be a
   wrapper around git-rebase, which prepares p' and then tries to
   rebase 1 2 onto p'.  So if you ask for an interactive rebase p'
   doesn't appear in your commit list.

   Note that the rebasing of p into p' cannot fail because p' simply
   copies debian/ from B and and everything else from #'.  (Rebasing A
   and B is undesirable.  We want the debian/ files to be non-rebasing
   so we can `git log' and get the packaging history.)

 * Record pseudomerge.  This is like "committing" your patch queue.
   The LH parent is taken from the previous strip pseudomerge.  (We
   should probably check that this is consistent with what we see in
   debian/changelog, but that is not a sufficient check.)

Maybe some of these operations should automatically edit
debian/changelog.

The only thing that this can't easily do is permit nonlinear (ie,
merging) history on the `packaging-only' branch, because upstream
might contain debian/ files too, so it is not possible to distinguish
a merge of two `packaging-only' branches from the special merge `p'.
(Indeed I since upstream might copy debian/ from us, I think it is not
easy to reliably distinguish the two parents of a `p'.  In the mos

Re: Feedback on 3.0 source format problems

[Jonas Smedegaard]

Quoting Vincent Bernat (2017-01-04 08:12:08)
>  ❦  4 janvier 2017 04:52 GMT, Scott Kitterman  :
> 
> >>> It's surprisingly awkward, and, at least for me, it turns out that
> >>> externalizing my rebased branch as a patch series solves many of
> >>> problems surprisingly well.  All the other solutions I can think of
> >>> require one or more things I don't really want to do: rebase the
> >>> debian/master branch, not be able to run dpkg-buildpackage from the
> >>> debian/master branch easily, or require that dpkg-buildpackage do
> >>> more mucking about with source control than I want it to.
> >>
> >>I believe the git-dpm approach would give you everything you want.  The
> >>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
> >>
> >>I personally think that technically git-dpm's approach is the best -
> >>but
> >>unfortunately the program itself is effectively unmaintained and
> >>apparently/consequently not used by many people.
> >
> > The Debian Python Modules Team (DPMT) has about 1,000 packages with
> > git-dpm repositories.  While it took a bit of getting used to and
> > there have been a few problems, overall I think it's worked very well.
> > It's biggest problem is the lack of a maintainer.
> 
> There have been a lot of complaints about it. For me, it is a pain to
> use. Its integration with gbp is poor, it produces a messy history when
> you are working on your patches and I often run into problems with
> .debian/.git-dpm file it maintains (import a new upstream, make some
> changes, notice that somebody else also pushed a change, pull --rebase,
> everything is broken). Since we started using it, we opened a lot of bug
> reports and not a single one of them has been fixed. I think that nobody
> wants to work on it because it is an extremely fragile tool and the
> first one to try to fix it will inherit of all the problems to solve.
> 
> Isn't "gbp pq" a correct execution of the same principles?
> -- 
> Make your program read from top to bottom.
> - The Elements of Programming Style (Kernighan & Plauger)

Do _any_ of the systems reliably handle a "git rebase" involving a merge 
of new upstream release?  In my experience gbp also fails that.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Feedback on 3.0 source format problems

[Vincent Bernat]

 ❦  4 janvier 2017 04:52 GMT, Scott Kitterman  :

>>> It's surprisingly awkward, and, at least for me, it turns out that
>>> externalizing my rebased branch as a patch series solves many of
>>> problems surprisingly well.  All the other solutions I can think of
>>> require one or more things I don't really want to do: rebase the
>>> debian/master branch, not be able to run dpkg-buildpackage from the
>>> debian/master branch easily, or require that dpkg-buildpackage do
>>> more mucking about with source control than I want it to.
>>
>>I believe the git-dpm approach would give you everything you want.  The
>>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>>
>>I personally think that technically git-dpm's approach is the best -
>>but
>>unfortunately the program itself is effectively unmaintained and
>>apparently/consequently not used by many people.
>
> The Debian Python Modules Team (DPMT) has about 1,000 packages with
> git-dpm repositories.  While it took a bit of getting used to and
> there have been a few problems, overall I think it's worked very well.
> It's biggest problem is the lack of a maintainer.

There have been a lot of complaints about it. For me, it is a pain to
use. Its integration with gbp is poor, it produces a messy history when
you are working on your patches and I often run into problems with
.debian/.git-dpm file it maintains (import a new upstream, make some
changes, notice that somebody else also pushed a change, pull --rebase,
everything is broken). Since we started using it, we opened a lot of bug
reports and not a single one of them has been fixed. I think that nobody
wants to work on it because it is an extremely fragile tool and the
first one to try to fix it will inherit of all the problems to solve.

Isn't "gbp pq" a correct execution of the same principles?
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Wed, Jan 4, 2017 at 1:30 PM, Nikolaus Rath wrote:

> But I am not sure if a package structure like
>
> mypkg/upstream/*
> mypkg/debian/*
> mypkg/patches/* (?)
>
> would have any *practical* benefits over the current situation, because
> this transformation could be trivially automated in either direction.
>
> Or did you have something else in mind?

TBH, I haven't thought much about what an alternative should look like.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 04 2017, Paul Wise  wrote:
> On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote:
>
>> I'm interested in what things people still find so off-putting to the
>> point of not wanting to use the new 3.0 source formats.
>
> I've been reading this thread and keep being reminded of our
> discussion on #debian-dpkg a while ago.
>
> I think most of the complaints about Debian source package formats are
> rooted in a design mistake made early on. The debian/ directory. The
> debian/ dir controls the upstream source but is in a subdirectory of
> the upstream source. The directory hierarchy is an inverse of the
> relationship between its parts. The debian/patches/ dir is another
> layering violation on top of that.

That is a point I very much agree with in principle.

But I am not sure if a package structure like

mypkg/upstream/*
mypkg/debian/*
mypkg/patches/* (?)

would have any *practical* benefits over the current situation, because
this transformation could be trivially automated in either direction.


Or did you have something else in mind?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Scott Kitterman]

On January 3, 2017 10:22:22 PM EST, Nikolaus Rath  wrote:
>On Jan 03 2017, Russ Allbery  wrote:
>> It's surprisingly awkward, and, at least for me, it turns out that
>> externalizing my rebased branch as a patch series solves many of
>these
>> problems surprisingly well.  All the other solutions I can think of
>> require one or more things I don't really want to do: rebase the
>> debian/master branch, not be able to run dpkg-buildpackage from the
>> debian/master branch easily, or require that dpkg-buildpackage do
>much
>> more mucking about with source control than I want it to.
>
>I believe the git-dpm approach would give you everything you want.  The
>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>
>I personally think that technically git-dpm's approach is the best -
>but
>unfortunately the program itself is effectively unmaintained and
>apparently/consequently not used by many people.

The Debian Python Modules Team (DPMT) has about 1,000 packages with git-dpm 
repositories.  While it took a bit of getting used to and there have been a few 
problems, overall I think it's worked very well.  It's biggest problem is the 
lack of a maintainer.

Scott K

Re: Feedback on 3.0 source format problems

[Russell Stuart]

On Tue, 2017-01-03 at 18:37 -0800, Russ Allbery wrote:
> Even if we never used tarballs, and instead our unit of operation was
> the upstream Git repository plus Debian branches, I would maintain a
> rebased branch of Debian changes to upstream

This is not a novel requirement.  Most projects I've worked with insist
you rebase your patches.  This is not new.  Before git they insisted
your patches applied cleanly - which amounts to the same thing. 
Breaking up large patches into a series of smaller independent patches
each with a simple and documented purpose isn't an unusual requirement
either.

To me this is just the software engineering 101 rule "break just large
software projects into smaller, easily understood and documented
modules" applied to change control.  The reason is identical - it's so
someone coming along behind you can easily understand what you have
done and why.   For those of us at a certain age, that someone else
coming along behind might be ourselves a few months later.

Whether it's mandatory seems to depend on how big the team is.  A large
DD team packaging who submits patches upstream to large project will
find it unavoidable.  (The Debian kernel currently carries 400 patches,
totalling 50K lines.  Managing that as a single lump would be
impossible.)  On the other hand a one person team who doesn't
contribute upstream could reasonably say it's pointless.  I know most
Debian packages are a one horse affair, but I am still surprised by the
number of DD's here claiming this software 101 process is _always_
pointless.

Source format "3.0 (quilt)" is a straightforward way of storing a
series of small documented patches.  This is in contrast to quilt(1)
the program, which is a way maintaining those patches.  I'm not fond of
quilt(1) as I regularly manage to get myself into states I can only get
out of using "rm -r; dpkg-source -x ...; reapply work done so far".

The kernel uses git as a better quilt (both are spin-offs from  the
kernel).  Gits adds some new tricks.  It doesn't get into impossible to
recover from states (yeh!).   The history it keeps allows it compare
and merge change sets - something that has to be done manually with
quilt.  That history also provides some extra features like git bisect,
and the ability to trace copyright - but they aren't so important.

What is important is git as it is used by the kernel devs still
produces small, rebased, documented patches.  If it didn't I doubt the
kernel would be using it.  The central issue here appears to be that
none of the proposed ways of using git within Debian help with that
task.  Debian packages that do use git and have patches don't use git
to generate the patches.  Eg, the kernel team appears[0] to use
quilt(!) to maintain its patch series, even though they use git too. 
If you are using quilt anyway because you like small documented
patches, but you are a one horse team and so aren't concerned about
parallel work flows a reasonable question is: why use git at all?


[0] I'm not on the kernel team, so I can't be sure about them using
quilt.  I guess they do because their debian/bin/test-patches tool
does use quilt.


signature.asc
Description: This is a digitally signed message part

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote:

> I'm interested in what things people still find so off-putting to the
> point of not wanting to use the new 3.0 source formats.

I've been reading this thread and keep being reminded of our
discussion on #debian-dpkg a while ago.

I think most of the complaints about Debian source package formats are
rooted in a design mistake made early on. The debian/ directory. The
debian/ dir controls the upstream source but is in a subdirectory of
the upstream source. The directory hierarchy is an inverse of the
relationship between its parts. The debian/patches/ dir is another
layering violation on top of that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Russ Allbery]

Nikolaus Rath  writes:

> Are there really upstreams that do that? I'd expect that the primary
> consumer of Debian patches are other distributions, downstreams, and
> users.

> I'd think that anything that's relevant for upstream development is
> forwarded to upstream by the maintainer in whatever format upstream
> prefers. This requires extra time, but I would be surprised to hear if
> there are maintainers that have sufficient time to create patches that
> are suitable for upstream, but don't have the little extra time to send
> them upstream.

There are definitely upstreams who like to look at what patches Debian is
shipping at their convenience, rather than having to ask the maintainer.
The maintainer may have already sent along the patches, but it's easy to
lose track of what patches are still being applied.

The other case where being able to point upstream at a directory of
patches is very nice is when upstream has been dormant for a long time and
then comes back to life.  It's an easy way for them to pull a bunch of
changes at once for a new development cycle.

I've also found it significantly smooth over relations with upstreams who
are otherwise quite prickly about modifications to their distributed
releases.  Having all the patches be published and clearly documented
somewhere without anyone having to ask wins points for transparency and
makes them feel like the whole process is less out of control and more
congenial and collaborative, even if you were also in the habit of sending
changes upstream.  It eliminates the fear that you're also applying other
ugly hacks you're not telling them about that might be maintenance burdens
for them.

-- 
Russ Allbery (r...@debian.org)   

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 03 2017, Russ Allbery  wrote:
> It's surprisingly awkward, and, at least for me, it turns out that
> externalizing my rebased branch as a patch series solves many of these
> problems surprisingly well.  All the other solutions I can think of
> require one or more things I don't really want to do: rebase the
> debian/master branch, not be able to run dpkg-buildpackage from the
> debian/master branch easily, or require that dpkg-buildpackage do much
> more mucking about with source control than I want it to.

I believe the git-dpm approach would give you everything you want.  The
explanation on http://git-dpm.alioth.debian.org/ is pretty good.

I personally think that technically git-dpm's approach is the best - but
unfortunately the program itself is effectively unmaintained and
apparently/consequently not used by many people.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Wed, Jan 4, 2017 at 2:54 AM, Russ Allbery wrote:

> Well, if we had one more thing: a patches.debian.org service that would
> show the git-debcherry-extracted patches against upstream.  I really like
> being able to just point upstream at all the patches relevant to them that
> Debian has applied.

I doesn't yet support non-quilt source formats, but:

https://sources.debian.net/patches/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 03 2017, Sean Whitton  wrote:
> Hello,
>
> On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote:
>> >
>> > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
>> 
>> Yes, but that's not as useful as what git-debcherry produces.
>> 
>> For example, if you get a merge conflict when rebasing, the above
>> incantation will list two commits: the original debian commit and the
>> merge commit. git-debcherry, on the other hand, will synthesize one
>> patch, consisting of the original Debian commit, but modified to include
>> the *relevant parts* of the merge commit.
>
> That's a good point.  In this context, `git debcherry` is a tool to
> filter and neaten a git history.  However, it inserts another step
> between upstream, and powerful tools like git-cherry-pick and
> git-bisect.  Upstream now has to know that Debian has orig.tars and
> various ways of representing changes to them.
>
> If I were a busy upstream, I would much rather `git fetch` my Debian
> maintainer's branches, and then immediately set to work cherry-picking
> and bisecting.  I don't need any Debian-specific knowledge, except that
> which is relevant to the bug I'm trying to fix -- I don't need to know
> what an orig.tar is.  This is worth having to look at a few merge
> commits.

Are there really upstreams that do that? I'd expect that the primary
consumer of Debian patches are other distributions, downstreams, and
users.

I'd think that anything that's relevant for upstream development is
forwarded to upstream by the maintainer in whatever format upstream
prefers. This requires extra time, but I would be surprised to hear if
there are maintainers that have sufficient time to create patches that
are suitable for upstream, but don't have the little extra time to send
them upstream.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Russ Allbery]

gregor herrmann  writes:

> Personally I have the feeling that lots of these discussions and also
> the creation of new tools (git-dpm, git-pq, git-debcherry, dgit) are
> just workarounds for the actual problem: Many of us would like to work
> in and with git but the whole infrastructure still revolves around
> tarballs and additions/patches to them; and therefore we're creating
> even more sophisticated tools to translate between those two worlds
> which try hard to first get the "old" world into a git-centric workflow
> and then try hard to get the work out again, in a way that can later be
> used again from "within". -- I know we won't get this in 2017, but
> still: I'd like to be a source package a git repo on
> $whatever.debian.org, and an upload to be a git push of a signed tag to
> the ftp-master remote. 

I think this is partly true, but I think there's still a part of this that
is still an issue even if we had a pure Git world, namely how to represent
the changes Debian is making to the upstream package in a clean way.

Even if we never used tarballs, and instead our unit of operation was the
upstream Git repository plus Debian branches, I would maintain a rebased
branch of Debian changes to upstream because I think this is dramatically
more useful than a merged branch with interleaved changes (including later
revisions to earlier diffs and resolutions of merge conflicts).  This
isn't a theoretical position -- I've tried about five or six different
ways of handling this, with very complex packages and lots of local
changes and with simple packages with just a few changes and have had bad
experiences with many of the solutions people propose.

This is actually, in a way, *harder* if we were using pure Git, since if I
have a rebased branch of Debian changes on top of upstream, and I need a
place to integrate that with Debian packaging, what does that
debian/master branch look like?  I don't really want it to be a constantly
rebased branch; I want it to be a conventional branch.  But I want to keep
merging the changes against upstream into it (but not maintain them on
that branch, only maintain the Debian packaging files on that branch).

It's surprisingly awkward, and, at least for me, it turns out that
externalizing my rebased branch as a patch series solves many of these
problems surprisingly well.  All the other solutions I can think of
require one or more things I don't really want to do: rebase the
debian/master branch, not be able to run dpkg-buildpackage from the
debian/master branch easily, or require that dpkg-buildpackage do much
more mucking about with source control than I want it to.  The cost of
this is storing diffs of patches in the debian branch as (rather useless)
commits, which I don't like and would rather not do, but all the
alternatives feel even less satisfactory.

(This is entirely apart from the problems with shipping a Git repository
with all of its history to our archive network, which have already been
discussed at length.)

-- 
Russ Allbery (r...@debian.org)   

Re: Feedback on 3.0 source format problems

[gregor herrmann]

On Tue, 03 Jan 2017 20:15:10 +, Sean Whitton wrote:

> On Tue, Jan 03, 2017 at 10:54:07AM -0800, Russ Allbery wrote:
> > Well, if we had one more thing: a patches.debian.org service that would
> > show the git-debcherry-extracted patches against upstream.  I really like
> > being able to just point upstream at all the patches relevant to them that
> > Debian has applied.
> That would be great.  Then the git-debcherry series would be available
> for those that want it, without requiring package maintainers to do any
> curation at all.

https://sources.debian.net/patches/ goes in that direction. AFAIK it
might not be complete and TTBOMK it hasn't been announced widely but
it exists and (I think) works for "3.0 (quilt)" packages.

For an example of a package using git-debcherry cf.
https://sources.debian.net/patches/libmodule-build-perl/0.422000-1/


Re git-debcherry in general: In the pkg-perl team we discussed and
experimented with it a few times. The final and not really solved
stumbling block in my experience is handling (as in: updating)
meta-information of a patch (DEP-3), e.g. for adding an upstream bug
reference. We played a bit with git-notes for that purpose but this
is quite clumsy, and although some very early tooling attempts exist
[0], the usage is still restricted to the 3 initial test packages
from August 2015, and there hasn't been any discussion in the team
since then.

Maybe for single maintainers and a couple of packages this
bookkeeping is less crucial; but for large teams and large groups of
packages having up to date information about e.g. the forwarded
status of a patch is quite essential.


Personally I have the feeling that lots of these discussions and also
the creation of new tools (git-dpm, git-pq, git-debcherry, dgit) are
just workarounds for the actual problem: Many of us would like to
work in and with git but the whole infrastructure still revolves
around tarballs and additions/patches to them; and therefore we're
creating even more sophisticated tools to translate between those two
worlds which try hard to first get the "old" world into a git-centric
workflow and then try hard to get the work out again, in a way that
can later be used again from "within". -- I know we won't get this in
2017, but still: I'd like to be a source package a git repo on
$whatever.debian.org, and an upload to be a git push of a signed tag
to the ftp-master remote. 


Cheers,
gregor

[0] https://anonscm.debian.org/cgit/pkg-perl/scripts.git/tree/debcherry

also the parts about git-notes in
https://anonscm.debian.org/cgit/pkg-perl/meta.git/tree/.mrconfig
and
https://anonscm.debian.org/cgit/pkg-perl/packages/pkg-perl-tools.git/tree/scripts/push

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Steppenwolf: Renegade


signature.asc
Description: Digital Signature

Re: Feedback on 3.0 source format problems

[James McCoy]

On Mon, Jan 02, 2017 at 01:09:35PM -0800, Nikolaus Rath wrote:
> On Jan 02 2017, Russ Allbery  wrote:
> > Furthermore, it forces a rebased, clean representation of the patches,
> > which I for one hugely prefer to the mess that you get if someone was
> > packaging in Git and just randomly commits things directly to the
> > packaging branch intermixed with merges from upstream.  A few releases
> > done that way will leave you almost completely unable to extract a rebased
> > patch set against the current upstream source.  (I have made this mistake
> > so many times with my own packages.)
> 
> Have you tried to use git-debcherry in those situations? I have tried it
> in some simpler cases and worked very well, but I'd be curious if anyone
> has tried it on larger and more complex repositories.

I've found git-debcherry to work well when cherry-picking patches _from_
upstream or upstream is receptive to merging patches.  If patches live
in the Debian package for quite some time (either intentionally as
Debian-specific changes or because it takes time to get upstream) then
you lose IMO relevant metadata in the debcherry-exported patches.

I ended up switching to gbp pq for the one package where I have
long-lived patches.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello,

On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote:
> >
> > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
> 
> Yes, but that's not as useful as what git-debcherry produces.
> 
> For example, if you get a merge conflict when rebasing, the above
> incantation will list two commits: the original debian commit and the
> merge commit. git-debcherry, on the other hand, will synthesize one
> patch, consisting of the original Debian commit, but modified to include
> the *relevant parts* of the merge commit.

That's a good point.  In this context, `git debcherry` is a tool to
filter and neaten a git history.  However, it inserts another step
between upstream, and powerful tools like git-cherry-pick and
git-bisect.  Upstream now has to know that Debian has orig.tars and
various ways of representing changes to them.

If I were a busy upstream, I would much rather `git fetch` my Debian
maintainer's branches, and then immediately set to work cherry-picking
and bisecting.  I don't need any Debian-specific knowledge, except that
which is relevant to the bug I'm trying to fix -- I don't need to know
what an orig.tar is.  This is worth having to look at a few merge
commits.

On Tue, Jan 03, 2017 at 10:54:07AM -0800, Russ Allbery wrote:
> Well, if we had one more thing: a patches.debian.org service that would
> show the git-debcherry-extracted patches against upstream.  I really like
> being able to just point upstream at all the patches relevant to them that
> Debian has applied.

That would be great.  Then the git-debcherry series would be available
for those that want it, without requiring package maintainers to do any
curation at all.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 03 2017, Nikolaus Rath  wrote:
> On Jan 03 2017, Sean Whitton  wrote:
>> Hello Russ,
>>
>> On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote:
>>> Furthermore, it forces a rebased, clean representation of the patches,
>>> which I for one hugely prefer to the mess that you get if someone was
>>> packaging in Git and just randomly commits things directly to the
>>> packaging branch intermixed with merges from upstream.  A few releases
>>> done that way will leave you almost completely unable to extract a rebased
>>> patch set against the current upstream source.  (I have made this mistake
>>> so many times with my own packages.)
>>
>> Aside from `git debcherry`, which was already mentioned, git itself can
>> get you this information.  For example:
>>
>> git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
>>
>> This will get you all commits which touched the upstream source that
>> have not been merged upstream.  There can be as many merge commits as
>> you like in between.
>
> Yes, but that's not as useful as what git-debcherry produces.
>
> For example, if you get a merge conflict when rebasing, the above
[...]

This should of course have been "...merge conflict when merging in a new
upstream version".

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 03 2017, Russ Allbery  wrote:
> Nikolaus Rath  writes:
>
>> For example, if you get a merge conflict when rebasing, the above
>> incantation will list two commits: the original debian commit and the
>> merge commit. git-debcherry, on the other hand, will synthesize one
>> patch, consisting of the original Debian commit, but modified to include
>> the *relevant parts* of the merge commit.
>
> Okay, yes, that sounds pretty awesome.  That may entirely remove my
> concerns about keeping the patches always rebased.

Well, as I said in my other mail: the big drawback is that even with a
small test tree running git-debcherry is already slow enough for the
user to ponder the implications of it being a 300 line bash script...

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Russ Allbery]

Nikolaus Rath  writes:

> For example, if you get a merge conflict when rebasing, the above
> incantation will list two commits: the original debian commit and the
> merge commit. git-debcherry, on the other hand, will synthesize one
> patch, consisting of the original Debian commit, but modified to include
> the *relevant parts* of the merge commit.

Okay, yes, that sounds pretty awesome.  That may entirely remove my
concerns about keeping the patches always rebased.

Well, if we had one more thing: a patches.debian.org service that would
show the git-debcherry-extracted patches against upstream.  I really like
being able to just point upstream at all the patches relevant to them that
Debian has applied.

-- 
Russ Allbery (r...@debian.org)   

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 03 2017, Sean Whitton  wrote:
> Hello Russ,
>
> On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote:
>> Furthermore, it forces a rebased, clean representation of the patches,
>> which I for one hugely prefer to the mess that you get if someone was
>> packaging in Git and just randomly commits things directly to the
>> packaging branch intermixed with merges from upstream.  A few releases
>> done that way will leave you almost completely unable to extract a rebased
>> patch set against the current upstream source.  (I have made this mistake
>> so many times with my own packages.)
>
> Aside from `git debcherry`, which was already mentioned, git itself can
> get you this information.  For example:
>
> git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
>
> This will get you all commits which touched the upstream source that
> have not been merged upstream.  There can be as many merge commits as
> you like in between.

Yes, but that's not as useful as what git-debcherry produces.

For example, if you get a merge conflict when rebasing, the above
incantation will list two commits: the original debian commit and the
merge commit. git-debcherry, on the other hand, will synthesize one
patch, consisting of the original Debian commit, but modified to include
the *relevant parts* of the merge commit.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Vincent Bernat writes ("Re: Feedback on 3.0 source format problems"):
> 2 janvier 2017 01:45 -0800, Josh Triplett <j...@joshtriplett.org> :
> > Personally, when I want to patch a random package, I run "debcheckout
> > package-name", make changes, commit them, format-patch, [...]

Really, I can't let this pass without plugging dgit :-).

For working on packages that aren't your own, you should use dgit
instead of debcheckout.  If you do then:

> Your debcheckout assumes that the VCS is git.

With dgit, the VCS you get is always git.

>  Moreover, it assumes that the patch management system is in an
> "applied" state for the Debian branch.

With dgit, the tree you get is always patches-applied.

>   And if you want to test your change, you may be in additional
> pain.

With dgit, you can use `dpkg-buildpackage -uc -b' directly in the
working tree.  (You can use git clean and git reset if
debian/rules dirties the tree.)

>  Is the package using plain quilt? Is it using some esoteric patch
> management system like "git-dpm"?

With dgit, you can ignore all of that.

>  Does the source from debcheckout includes the upstream branch

With dgit, you always get the upstream branch.

> My point is just that we have too many ways to represent a source
> package and its modifications. 3.0 (quilt) is definitely an
> improvement. Making everybody uses the same git workflow (like gbp pq)
> would be better IMO, but I understand many will object.

With dgit, you can even NMU with linear git commits on top of the
existing package, whilch will be turned into nice patches which the
gbp pq (or git-dpm or quilt) user will be happy with.

The only downside is that if the maintainer didn't use dgit, you don't
get the maintainer's history.  But if debcheckout would have given you
a git tree, dgit will set up a `vcs-git' remote which you can `git
fetch', if you want to go history-diving.

See dgit-user(7) and dgit-nmu-simple(7):

 
https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user=0=0=Debian+unstable+sid=html=en
 
https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-nmu-simple=0=0=Debian+unstable+sid=html=en

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Guillem Jover writes ("Feedback on 3.0 source format problems"):
> I'm interested in what things people still find so off-putting to the
> point of not wanting to use the new 3.0 source formats, or what makes
> people use them in anger and similar (if people would state which one
> of these apply that would be helpful). All these including objective
> and subjective issue. And even existing bug references would be fine.

Thanks for explicitly inviting critical opinions!


AIUI the only significant 3.0 format supported in Debian right now is
`3.0 (quilt)'.

I think it is very poor.  Its only virtue is that it is better than
in-tree ad-hoc patch systems implemented in debian/rules, which it has
(thankfully!) almost entirely replaced.

IMO it's not a `source package format'.  This is because a `source
package format' would be a way to represent and transport a package's
source code tree.  But `3.0 (quilt)' puts extraneous data in the
source tree (in debian/patches/), and requires those files to be kept
in step.  Or to look at it another way, it insists on execution of
special commands after editing files.

Looked at another way, it is trying to be a version control system,
layered on top of the Debian archive.  But it is only about a quarter
of a VCS.  There are no formal interfaces to do proper VCS operations.
If there is a formal interface, it is quilt(1) (which is itself very
poor.  NB that is not quilt's fault: quilt inevitably has a hard job
because can't make enough assumptions).

I think if we want to be storing patch queues we should be doing so in
a real version control system.  Indeed, most people are doing that.
For now many people are using `3.0 (quilt)' as an interchange format,
but ideally we would switch to a useable git workflow that did a
similar thing, and then we could use git as our history interchange
format.


Additionally, `3.0 (quilt)' unfairly privileges the Debian Project: it
provides facilities (which apparently some people find helpful) for
maintaining a delta from an upstream tarball.  But because it excludes
patches to debian/* from its patch series, it cannot be used the same
way by a Debian derivative to maintain their packaging patch stack, on
top of their own upstream (which might be Debian or might be an
intermediate derivative).


There are other 3.0 formats, which are all quite different.  The only
interesting one of these which is a serious contender is `3.0 (git)'.
IMO `3.0 (git)' is a very silly way of transporting git branches
about.  It doesn't solve any underlying technical problems; it just
tries to wedge git into the ftp.debian.org-shaped hole.

`3.0 (native)' exists too but I don't quite understand the point of
that.  1.0 could be extended to support other compression formats, and
it does not make any logical sense that ignore rules depend on the
source format.


I have already said that I would like a source format which can
faithfully represent every possible reasonable tree (let us say, every
git tree).

We need such a format to retain the space and bandwidth advantages of
.orig tarballs.  It needs to be very stable and not to accidentally
grow new incompatible features (as `3.0 (quilt)' has done due to its
reliance on patch).

If we manage to store our the revision control history elsewhere, in a
proper revision control server, we do not need the archive to contain
the revision control history.

I think my proposal for `3.0 (rsync)' would meet these requirements
and I'm still sad it won't make stretch.  It means we can't use that
for developing buster.


Regards,
Ian.


-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello Russ,

On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote:
> Furthermore, it forces a rebased, clean representation of the patches,
> which I for one hugely prefer to the mess that you get if someone was
> packaging in Git and just randomly commits things directly to the
> packaging branch intermixed with merges from upstream.  A few releases
> done that way will leave you almost completely unable to extract a rebased
> patch set against the current upstream source.  (I have made this mistake
> so many times with my own packages.)

Aside from `git debcherry`, which was already mentioned, git itself can
get you this information.  For example:

git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'

This will get you all commits which touched the upstream source that
have not been merged upstream.  There can be as many merge commits as
you like in between.

> I think the forced rebasing is huge, and is a significant feature for me.
> But then, I'm a rebase-not-merge person in the perennial Git flamewar.

This is probably why we disagree :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Christoph Biedl]

Vincent Bernat wrote...

> For me, this is a great improvement over the previous format with
> several different patching systems (quilt, dpatch, nothing,
> custom). Now, most packages are using quilt, one less thing to
> understand.

That's for sure, and I doubt there are many people who consider 3.0
(quilt) a regression compared to other methods. Now while the thread
went a bit "What's not so good in 3.0 (quilt)", the initial intention
was a bit different: Are there technical reasons why a certain package
cannot be converted to source format 3.0 (not necessarily quilt)?
Personal preference or lack of acquaintance with the workflow is not
an excuse.

For me, besides some minor annoyances, there is just one thing with
3.0 (quilt), and I already forgot about the details: Baseline was, a
patch modified some auto* file (configure.ac, Makefile.am), and in
certain situations the patch was not applied yet or already unapplied
where it should have been. Probably I worked around it by adding some
extra statements in debian/rules.

Christoph


signature.asc
Description: Digital signature

Re: Feedback on 3.0 source format problems

[Russ Allbery]

Nikolaus Rath  writes:
> On Jan 02 2017, Russ Allbery  wrote:

>> Furthermore, it forces a rebased, clean representation of the patches,
>> which I for one hugely prefer to the mess that you get if someone was
>> packaging in Git and just randomly commits things directly to the
>> packaging branch intermixed with merges from upstream.  A few releases
>> done that way will leave you almost completely unable to extract a
>> rebased patch set against the current upstream source.  (I have made
>> this mistake so many times with my own packages.)

> Have you tried to use git-debcherry in those situations? I have tried it
> in some simpler cases and worked very well, but I'd be curious if anyone
> has tried it on larger and more complex repositories.

I haven't (in fact, hadn't heard of it).  I've at this point redone all of
my packages to export quilt series as the archive source format, so I no
longer have a great test case for this.

-- 
Russ Allbery (r...@debian.org)   

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 02 2017, Russ Allbery  wrote:
> Furthermore, it forces a rebased, clean representation of the patches,
> which I for one hugely prefer to the mess that you get if someone was
> packaging in Git and just randomly commits things directly to the
> packaging branch intermixed with merges from upstream.  A few releases
> done that way will leave you almost completely unable to extract a rebased
> patch set against the current upstream source.  (I have made this mistake
> so many times with my own packages.)

Have you tried to use git-debcherry in those situations? I have tried it
in some simpler cases and worked very well, but I'd be curious if anyone
has tried it on larger and more complex repositories.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Feedback on 3.0 source format problems

[Russ Allbery]

Josh Triplett  writes:

> That page already captures my primary issue with "3.0 (quilt)": it acts
> like a version control system, and interacts poorly with other version
> control systems.

I think it's better to think of it as a portable interchange format for
version control systems than a version control system itself, although I
admit that's a fine distinction.

The huge advantage that I see with 3.0 (quilt) is that it offers (although
doesn't require) the ability to represent the *separate, individual*
changes you have made to upstream sources as separate commits that could
be rendered as such in any version control system of your choice.  You can
just not do that and produce a single patch, of course, but if you take
the time to do so, you have something that can easily be moved from one
version control system to another without losing the most significant
information (the separation of changes into conceptual changesets).

Furthermore, it forces a rebased, clean representation of the patches,
which I for one hugely prefer to the mess that you get if someone was
packaging in Git and just randomly commits things directly to the
packaging branch intermixed with merges from upstream.  A few releases
done that way will leave you almost completely unable to extract a rebased
patch set against the current upstream source.  (I have made this mistake
so many times with my own packages.)

I certainly don't want to work with quilt directly when maintaining the
package, since as you say it's a bad version control system.  But with
tools to import and export the patches into a rebased version control
branch (which is basically what gbp pq does), it works pretty well.

I think the forced rebasing is huge, and is a significant feature for me.
But then, I'm a rebase-not-merge person in the perennial Git flamewar.

-- 
Russ Allbery (r...@debian.org)   

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Dear Josh,

On Mon, Jan 02, 2017 at 03:25:29AM -0800, Josh Triplett wrote:
> Currently working on some improvements in that direction, to separate
> repository format from workflow.

I'd like to encourage you to read my dgit-maint-merge(7) workflow
tutorial.  Perhaps the work to which you refer could result in some
improvements to what I wrote there.  Thanks in advance.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Josh Triplett]

Vincent Bernat wrote:
> > Personally, when I want to patch a random package, I run "debcheckout
> > package-name", make changes, commit them, format-patch, and mail that
> > to
> > the BTS.  If the package doesn't have an appropriate Vcs field for
> > debcheckout to read, I instead run "apt source package-name",
> > "cp package-name-version{,.orig}", edit,
> > "diff -Naur package-name-version{.orig,}", and then submit the
> > result.  Either way, if someone wants to manage their patches in quilt
> > or similar, they can take the resulting patch and insert it into
> > debian/patches/ easily enough.
>
> Your debcheckout assumes that the VCS is git.

No, it doesn't; I can cope with other things, or fall back to the
alternate "apt source package-name" workflow.  A substantial majority of
packages use git, though.

> Moreover, it assumes that
> the patch management system is in an "applied" state for the Debian
> branch.

Yes, it assumes that the output of "debcheckout" supports an immediate
"debuild -b".  That seems like a safe assumption for the vast majority
of packages I've run into.  For others, it often still works as long as
your patch doesn't conflict with some other patch (which would cause
significant pain even if known in advance).  And not having patches
already applied makes editing painful.

> And if you want to test your change, you may be in additional
> pain. Is the package using plain quilt? Is it using some esoteric patch
> management system like "git-dpm"?

Again, I expect "debuild -b" to work on the result of "debcheckout",
which tends to work.

> Does the source from debcheckout
> includes the upstream branch or do you have to grab the tarball from
> somewhere else? In this case, how do you make your patch?

Grumble and fall back to "apt source".

> Your second method assumes that existing patches are already applied
> (which is the case with 3.0 (quilt)).

Or that the unapplied patches don't conflict, but yes.

> My point is just that we have too many ways to represent a source
> package and its modifications. 3.0 (quilt) is definitely an
> improvement.

In some ways (and again, I do use it), but it seems like an improvement
built around a non-VCS patches-and-tarballs world, not a VCS world.

> Making everybody uses the same git workflow (like gbp pq)
> would be better IMO, but I understand many will object.

Not necessarily the same workflow, but the same repository layout.  And
yes, until a single repository layout exists that satisfies all
requirements, people will object vehemently.

Currently working on some improvements in that direction, to separate
repository format from workflow.

- Josh Triplett

Re: Feedback on 3.0 source format problems

[Vincent Bernat]

 ❦  2 janvier 2017 01:45 -0800, Josh Triplett  :

>> > I don't want the source format to care about details like those.
>> > If people want to use quilt to manage a patch series within their
>> > packages, they can do so, but the source format shouldn't care
>> > about that.  The source format should not attempt to specify or
>> > interact in any way with patching or version control.
>>
>> For me, this is a great improvement over the previous format with
>> several different patching systems (quilt, dpatch, nothing,
>> custom). Now, most packages are using quilt, one less thing to
>> understand.
>>
>> IMO, we still have too much diversity in how we handle version control
>> for packages.
>
> "Using" quilt by stuffing the former contents of .diff.gz into
> debian/patches/debian-changes doesn't seem like an improvement; it just
> adds complexity, and opens the possibility of someone adding other
> changes via quilt, rather than as a patch suitable for direct "git
> am".

This is still far less possibilities than what what was previously
allowed by the previous format. Since this new format, many packages now
have distinct patches. There is also DEP-3 that should help.

> Personally, when I want to patch a random package, I run "debcheckout
> package-name", make changes, commit them, format-patch, and mail that to
> the BTS.  If the package doesn't have an appropriate Vcs field for
> debcheckout to read, I instead run "apt source package-name",
> "cp package-name-version{,.orig}", edit,
> "diff -Naur package-name-version{.orig,}", and then submit the
> result.  Either way, if someone wants to manage their patches in quilt
> or similar, they can take the resulting patch and insert it into
> debian/patches/ easily enough.

Your debcheckout assumes that the VCS is git. Moreover, it assumes that
the patch management system is in an "applied" state for the Debian
branch. And if you want to test your change, you may be in additional
pain. Is the package using plain quilt? Is it using some esoteric patch
management system like "git-dpm"?  Does the source from debcheckout
includes the upstream branch or do you have to grab the tarball from
somewhere else? In this case, how do you make your patch?

Your second method assumes that existing patches are already applied
(which is the case with 3.0 (quilt)).

My point is just that we have too many ways to represent a source
package and its modifications. 3.0 (quilt) is definitely an
improvement. Making everybody uses the same git workflow (like gbp pq)
would be better IMO, but I understand many will object.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Josh Triplett]

Vincent Bernat wrote:
> ❦  2 janvier 2017 00:57 -0800, Josh Triplett  :
>
> > I don't want the source format to care about details like those.  If
> > people want to use quilt to manage a patch series within their
> > packages,
> > they can do so, but the source format shouldn't care about that.  The
> > source format should not attempt to specify or interact in any way
> > with
> > patching or version control.
>
> For me, this is a great improvement over the previous format with
> several different patching systems (quilt, dpatch, nothing,
> custom). Now, most packages are using quilt, one less thing to
> understand.
>
> IMO, we still have too much diversity in how we handle version control
> for packages.

"Using" quilt by stuffing the former contents of .diff.gz into
debian/patches/debian-changes doesn't seem like an improvement; it just
adds complexity, and opens the possibility of someone adding other
changes via quilt, rather than as a patch suitable for direct "git am".

Personally, when I want to patch a random package, I run "debcheckout
package-name", make changes, commit them, format-patch, and mail that to
the BTS.  If the package doesn't have an appropriate Vcs field for
debcheckout to read, I instead run "apt source package-name",
"cp package-name-version{,.orig}", edit,
"diff -Naur package-name-version{.orig,}", and then submit the
result.  Either way, if someone wants to manage their patches in quilt
or similar, they can take the resulting patch and insert it into
debian/patches/ easily enough.

Re: Feedback on 3.0 source format problems

[Vincent Bernat]

 ❦  2 janvier 2017 00:57 -0800, Josh Triplett  :

> I don't want the source format to care about details like those.  If
> people want to use quilt to manage a patch series within their packages,
> they can do so, but the source format shouldn't care about that.  The
> source format should not attempt to specify or interact in any way with
> patching or version control.

For me, this is a great improvement over the previous format with
several different patching systems (quilt, dpatch, nothing,
custom). Now, most packages are using quilt, one less thing to
understand.

IMO, we still have too much diversity in how we handle version control
for packages.
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Josh Triplett]

Guillem Jover wrote:
> I'm interested in what things people still find so off-putting to the
> point of not wanting to use the new 3.0 source formats, or what makes
> people use them in anger and similar (if people would state which one
> of these apply that would be helpful). All these including objective
> and subjective issue. And even existing bug references would be fine.
>
> I've created an initial draft wiki page with few things I had noted
> down, where I'll try to summarize things mentioned on the thread:
>
>   

I use the "3.0 (native)" and "3.0 (quilt)" formats, mostly because they
have better defaults in dpkg-source.  I also like that these formats
support source tarball compressions other than gzip.

That page already captures my primary issue with "3.0 (quilt)": it acts
like a version control system, and interacts poorly with other version
control systems.

Related to that, the 3.0 formats also require listing binary files
explicitly in debian/source/include-binaries, rather than handling them
transparently like all modern version control systems do.

I don't want the source format to care about details like those.  If
people want to use quilt to manage a patch series within their packages,
they can do so, but the source format shouldn't care about that.  The
source format should not attempt to specify or interact in any way with
patching or version control.

Re: Feedback on 3.0 source format problems

[Bastien ROUCARIES]

On Sun, Jan 1, 2017 at 6:21 PM, Guillem Jover  wrote:
> Hi!
>
> I'm interested in what things people still find so off-putting to the
> point of not wanting to use the new 3.0 source formats, or what makes
> people use them in anger and similar (if people would state which one
> of these apply that would be helpful). All these including objective
> and subjective issue. And even existing bug references would be fine.
>
> I've created an initial draft wiki page with few things I had noted
> down, where I'll try to summarize things mentioned on the thread:
>
>   
>

Ok I love 3.0 format except that I could not specify wildcard in ls
debian/source/include-binaries and
#668588 if it still apply

Bastien


> (I'm not using  because
> TBH it read more like a sales brochure than a more neutral page…)
>
> Thanks,
> Guillem
>

Re: Feedback on 3.0 source format problems

[Christoph Biedl]

Guillem Jover wrote...

> On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote:

> > TBH this feels like you're sniping at Raphael here, which I think is
> > pretty sad and inappropriate.

Well, bringing up more old stories, even if 'The secret plan behind
the "3.0 (quilt)" Debian source' was meant to be a joke, it wasn't
quite helpful to convince the people who were not sure about the
concept. So Guillem's wording might be inappropriate but Raphael will
have to stand that.

> But then, I know that part of the resistance to the new formats was
> in part due to that very aggressive advertising campaign, that for
> whatever reason annoyed some quarters of the project. So, when trying
> in a way to start a dialogue with the people that got annoyed at the
> time, I think it would be a bad idea to cloud that with a page like
> that.

This is a good plan, go for it. Overall (and starting advocacy), I'm
not a huge fan of 3.0 (quilt) but - especially when used with DEP-3
headers - it is the best thing Debian has, way better than 1.0 and all
the other hand-crafted patch handling I happen to see in some
packages. Also, this format has been around for several years now, it
is understood, well-tested and widely accepted.

So I might suggest "Deprecate source format 1.0" as a buster release goal.

Christoph


signature.asc
Description: Digital signature

Re: Feedback on 3.0 source format problems

[Guillem Jover]

On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote:
> On Jan 01 2017, Guillem Jover  wrote:
> > (I'm not using  because
> > TBH it read more like a sales brochure than a more neutral page…)
> 
> TBH this feels like you're sniping at Raphael here, which I think is
> pretty sad and inappropriate.

Hmm, I brought it up because it does read like that to me (please have
a look if you haven't), and it does not feel right for me to change the
tone of that page on my own.

I don't have an inherent problem with people advertising features and
trying to "sell" them to users, more so if you have invested time and
energy in them and truly think they are superior. And just to be clear
I switched all packages I maintain to 3.0 formats long time ago and
never looked back, and I'm pretty happy about it.

But then, I know that part of the resistance to the new formats was
in part due to that very aggressive advertising campaign, that for
whatever reason annoyed some quarters of the project. So, when trying
in a way to start a dialogue with the people that got annoyed at the
time, I think it would be a bad idea to cloud that with a page like
that. I see taking a neutral position as a way to try to "heal" that
divide in the project. Hope that explains.

Thanks,
Guillem

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 01 2017, Guillem Jover  wrote:
> (I'm not using  because
> TBH it read more like a sales brochure than a more neutral page…)

TBH this feels like you're sniping at Raphael here, which I think is
pretty sad and inappropriate.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Feedback on 3.0 source format problems

[Guillem Jover]

Hi!

I'm interested in what things people still find so off-putting to the
point of not wanting to use the new 3.0 source formats, or what makes
people use them in anger and similar (if people would state which one
of these apply that would be helpful). All these including objective
and subjective issue. And even existing bug references would be fine.

I've created an initial draft wiki page with few things I had noted
down, where I'll try to summarize things mentioned on the thread:

  


(I'm not using  because
TBH it read more like a sales brochure than a more neutral page…)

Thanks,
Guillem