Re: Are Martin and Sam's platforms equivalent?
On Wed, Apr 03, 2019 at 12:40:45PM +0100, Ian Jackson wrote:
> I hesitate to bang this drum again, but this would be a great place to
> think about how we can use git more.
>
> Ideally, our default sponsorship workflow would *not involve source
> packages or orig tarballs at all*.
It's too easy to get orig tarballs wrong. Until all or most upstreams have
public git with tags, this might be problematic. For this reason, I tend to
ask for an upload to mentors.d.n even when provided with a
some-random-workflow-git-repo (I especially hate anything related to gbp).
> If sponsorship was as simple as
> git debsponsor clone <package>
> cd <package>
> git diff dgit/dgit/sid # or maybe git diff upstream/stable-4.12
> dgit push-source
Shouldn't this include actual build, etc? I have sponsored over 1000
uploads, yet not a single time I skipped the build step. Sponsorees don't
tend to package libreoffice-sized stuff, and even uploads I otherwise merely
rubber-stamp too often miss some obscure B-Dep or something. There's no way
I'd upload even an one-line change without a test build + bin-debdiff.
And, without a built package, you can't look at lintian. It automates a
good part of reviewing.
> then (i) I would want to do much more sponsorship (ii) my sponsees
> would get the kind of timely service I can provide for `oh this is a
> 5 min job' type of task, rather than what I can provide for `this
> might take half an hour or it might take two hours'.
While git does have many upsides, I fail to see how it'd be better for
estimating required effort. For comparison, my workflow is:
.--==[ .bashrc ]
alias lsdebs='grep ^Package: debian/control |cut -d" " -f2 >/tmp/deb-list'
alias diffdebs='for x in `cat /tmp/deb-list`;do c "$x" && apt download "$x" && debdiff --wt "$x"_*deb;done'
`--
dget <pasted URL, preferably from mentors>
cd <package>
lsdebs
dpkg-buildpackage -S -d # repack, gen changes
cd ..
sbuild <package.dsc>
diffdebs
apt source <package>
debdiff package_*.dsc|colordiff|less -R
This is the point where, having glanced at both diffs, I decide whether to rubber-stamp
or to do actual review. Of course folks like Gürkan can pass even complex
changes with only a cursory look, newbies and poor-quality contributors get
even trivial changes fully reviewed, usual folks are in the middle.
What I'd wish for, is some CI that takes sponsoree-provided package, builds
it, and provides ready bin-lintian, src-debdiff, bin-debdiff, and the .debs
to look over -- but such a tool can be fed a dgit repo just the same as
existing mentors .dsc packages. Unless you make dgit fully distributed like
"dget from some random URL" is, there's no gain.
And, monstrosities like gbp or patches-unapplied make quilt-in-git workflows
nastier to review than just comparing two unpacked dirs, the old way.
So, if you'd want to make _me_ happy, it would be nice if you could kill
quilt dead.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀
Reply to: