Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #10787 > unrolled thread

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

Back to article view | Back to linux.debian.project

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Adam Borowski <kilobyte@angband.pl> - 2019-07-24 00:10 +0200
    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Holger Levsen <holger@layer-acht.org> - 2019-07-24 00:30 +0200
    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Bastian Blank <waldi@debian.org> - 2019-07-24 19:20 +0200
      Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Florian Weimer <fw@deneb.enyo.de> - 2019-07-24 22:20 +0200
    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Bastian Blank <waldi@debian.org> - 2019-07-24 19:30 +0200

#10787 — Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.

Good.  Especially if we can then drop quilt.
 
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

Big fat enormous NO!  gbp is a workaround for the biggest evil in our
packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
impression that if we dropped the VCS-in-VCS approach, there'd be no need
for most of that complexity.

The vast majority of upstreams already use git, adding 1980's-style patches
on top of that is like pulling a non-broken car with a horse.

And, a flat tarball like .orig is no longer a preferred form for
modification.  Do you remember the brouchacha in 2011 when Red Hat released
their kernel sources that way?

I'd say we should drop .orig and _forbid_ gbp.

> 3- Mandating using Salsa as a Git repository.

Or perhaps we could have a service mirror official git repos for packages
hosted elsewhere?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal).

[toc] | [next] | [standalone]

#10788

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> > 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> > packaging.
> 
> Good.  Especially if we can then drop quilt.
>  
> > 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> > seems to be the most popular layout, and that we need some kind of
> > consistency.
> 
> Big fat enormous NO!  gbp is a workaround for the biggest evil in our
> packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
> impression that if we dropped the VCS-in-VCS approach, there'd be no need
> for most of that complexity.
> 
> The vast majority of upstreams already use git, adding 1980's-style patches
> on top of that is like pulling a non-broken car with a horse.
> 
> And, a flat tarball like .orig is no longer a preferred form for
> modification.  Do you remember the brouchacha in 2011 when Red Hat released
> their kernel sources that way?
> 
> I'd say we should drop .orig and _forbid_ gbp.
> 
> > 3- Mandating using Salsa as a Git repository.
> 
> Or perhaps we could have a service mirror official git repos for packages
> hosted elsewhere?

I second kilobyte's amendment. Except the part about dropping .orig,
somewhat sadly.

Put more seriously: #1 I'd agree with, #2 I think is impossible and for
#3 I really like the idea of mirroring them all, https://src.fedoraproject.org
is indeed really cool.


-- 
tschau,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[toc] | [prev] | [next] | [standalone]

#10822

On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
> On 7/23/19 11:59 PM, Adam Borowski wrote:
> > Big fat enormous NO!  gbp is a workaround for the biggest evil in our
> > packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
> > impression that if we dropped the VCS-in-VCS approach, there'd be no need
> > for most of that complexity.
> How do you track what you've applied in Debian, and the status of your
> patch upstream? With DEP3 patch headers in d/patches, we track this easily.

git cherry-pick to get new changes. git diff to get all changes, git log
to list changes.  You just need to know the branch point.

And nothing forces you not to use DEP3 or something similar in git.  Or
you add a file to that commit with information you need.

Bastian

-- 
	"... freedom ... is a worship word..."
	"It is our worship word too."
		-- Cloud William and Kirk, "The Omega Glory", stardate unknown

[toc] | [prev] | [next] | [standalone]

#10824 — Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

* Bastian Blank:

> On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
>> On 7/23/19 11:59 PM, Adam Borowski wrote:
>> > Big fat enormous NO!  gbp is a workaround for the biggest evil in our
>> > packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
>> > impression that if we dropped the VCS-in-VCS approach, there'd be no need
>> > for most of that complexity.
>> How do you track what you've applied in Debian, and the status of your
>> patch upstream? With DEP3 patch headers in d/patches, we track this easily.
>
> git cherry-pick to get new changes. git diff to get all changes, git log
> to list changes.  You just need to know the branch point.
 
I expect you'd need some more tool support to find backports that did
not properly converge after an upstream merge (that is, importing a
new .orig.tar.gz in the current model), so that you can be aware and
remove the lingering difference.  For partially diverging trees, “git
diff” might be a bit too much.  However, I do think that such tooling
will be far simpler and more deterministic than any two-way Git
importer (having written one of those for RPM spec files, complete
with LCS-based editing of Patch:/%patch directives).

But isn't a GR a bit premature?  I would have expected something to
build directly from salsa.debian.org first—like how Fedora builds from
Git repositories on src.fedoraproject.org.  I'd hope for something
without VCS-in-VCS, but even if you prefer that, but build-from-salsa
applies to any approach which mandates a centralized Git (in addition
to the already-centralized archive).

(I really hate VCS-in-VCS, although I know it primarily from a
non-Debian context these days.)

[toc] | [prev] | [next] | [standalone]

#10823

On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote:
> Big fat enormous NO!  gbp is a workaround for the biggest evil in our
> packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
> impression that if we dropped the VCS-in-VCS approach, there'd be no need
> for most of that complexity.

gbp is nasty stuff, yes.

Years ago I made plans to make good use of the "3.0 (custom)" source
format by writing one large patch into the finished source package.  It
would just work with non-linear history by simply diffing the branch
point and the head.

What is also missing: merge friendly changelog management.

> And, a flat tarball like .orig is no longer a preferred form for
> modification.  Do you remember the brouchacha in 2011 when Red Hat released
> their kernel sources that way?

It was never.  A tarball is a container of files.  The files inside are
the perferred form of modification.

Regards,
Bastian

-- 
It would be illogical to assume that all conditions remain stable.
		-- Spock, "The Enterprise Incident", stardate 5027.3

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web