Thanks for laying out your vision for the git ubuntu workflow.
On Thu, Jun 15, 2023 at 01:57:58AM +0100, Robie Basak wrote:
> 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.
I bristle at this being called an "expert" workflow, because it includes
steps that I expect every Ubuntu dev to do before uploading to the archive
:) That implies additional checkpoints beyond what you've outlined.
I think every package (both source and binary) should be checked with
lintian before being uploaded, and the uploader should review its output and
make a conscious decision to ignore any errors. If building and uploading
of a source package is a single operation in git-ubuntu, where does this
check happen?
There are various ways one can have a git repository that builds binaries
successfully, but does not actually correspond to the source package that
would be uploaded. E.g., deletions in git of files from the upstream
source, which would be ignored by dpkg-source -b; source packages whose
debian/rules clean target modifies the source (debian/control being a common
one). At what point will the uploader have the opportunity to confirm that
the git tree and the source package correspond to one another, and that the
source package is what the uploader actually intends to upload?
While git-ubuntu is still maturing, some developers might also want to
review its output (debdiff? less foo.changes?) before committing.
> 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.
I think if we're being realistic, Ubuntu developers not dealing with source
packages is years away, and will only be farther if in the meantime we don't
provide a first-order git-ubuntu experience that we can confidently
recommend to developers for the current setup. Buy-in and adoption of
git-ubuntu as a tool is a necessary precondition for us getting away from
working with source packages, so in my view we have to approach this
incrementally.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
