git-ubuntu build

Robie Basak robie.basak at ubuntu.com
Thu Jun 15 00:57:58 UTC 2023


On Tue, Jun 13, 2023 at 02:35:38PM -0700, Steve Langasek wrote:
> On Mon, Jun 12, 2023 at 09:37:56PM +0200, Adrien Nader wrote:
> I feel this aligns with Bryce's comments about this being more of a
> 'submission' workflow.  It is an important distinction that none of the
> other 'build' tools I mentioned involve pushing to a public repo.  That's
> otherwise only done by 'bzr push', 'git push', 'dgit push', 'dput'.
> 
> Would 'git ubuntu push' or 'git ubuntu submit' be a better name for this
> than 'git ubuntu build'?

Let's talk about where we want to go with subcommands.

I'm working on bringing "git ubuntu build" back. I'd like "git ubuntu
clone foo; cd foo; git ubuntu build" to work for any package, giving you
binary debs in the parent directory, without any additional setup. I'd
also like it to magically work in the case that the user has done things
like cherry-picked changes from upstream. It should use a sensible
version and autogenerate a changelog entry if required. Then users don't
have to know about quilt or debian/changelog. I think this would make
for a much smoother onboarding process and experience for drive-by
contributors.

"git ubuntu build" did all this previously, but failed in too many edge
cases. So I need to figure out how to better do all of the above, cover
all the existing known edge case failures, and have decent test coverage
to stop them regressing again. My current effort is in a wip branch[1].

"git ubuntu submit" already exists, and would be the next step for a
contributor. It creates an MP. I don't remember if it pushes first or
not. There are presumably improvements that can be made to it, but it
works and is in active use today, so it's a lower priority right now I
think.

After MP approval, the next obvious logical step is to upload it -
either yourself if you have permission, or by a sponsor. Currently
git-ubuntu doesn't implement this, so you have to generate a source
package yourself. "prepare-upload" is intentionally low-level to
automate the rich history preservation bit, and to allow for wrappers
like Steve's gu-build and any other custom workflows that established
developers have. As a high level interface I imagine that git-ubuntu
should implement something like "git ubuntu publish"[2] that just does
the right things from a git branch that is ready.

Steve mentioned that he wanted to do things with intermediate steps. I
definitely want this to be possible, but I don't think that the design
of the headline git-ubuntu subcommands should take these use cases into
account except as command line options where those make sense. For
example, "build-source" got replaced with "build -S" and we can keep
this. Where behaviour changes with flags don't make sense, I think we
should instead implement "expert level" subcommands as necessary
instead.

For example, we could have wrappers around dpkg-buildpackage and sbuild.
Perhaps unified into a "make a temporary directory, build a source
package there, and then run command X" type wrapper. But this would
generally only be for use by experts who want to do workflow surgery.
Normally, "git ubuntu build", "git ubuntu submit" and "git ubuntu
publish" should suffice.

Where, in expert mode, you also want rich history changes file headers,
combining it with prepare-upload should be possible - perhaps with a
"push only" mode, and a second invocation after the source package is
built with a flag to say that you guarantee it is already pushed.

Then it'd be possible to construct higher level wrappers for specific
"expert" use cases from these components. Steve's current gu-build would
be one of those.

I'm open to all of these becoming subcommands in the "official" tool.
But I'd like the "headline" subcommands to be focused on what git-based
Ubuntu development _should_ be like, hiding away complexity that can be
automated (eg. not making the user handle source packages when we can
use git instead) rather than still exposing the current arcanity of it
all.

That's my vision, anyway. This is all open to feedback and subject to
change, as always :-)

Robie

[1] https://code.launchpad.net/~racb/git-ubuntu/+git/usd-importer/+ref/resurrect-build
[2] Because I think the term "upload" is overloaded.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20230615/4e15452f/attachment-0001.sig>


More information about the ubuntu-devel mailing list