On Thu, Jun 15, 2023 at 12:24:16PM -0700, Steve Langasek wrote:
> 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?
For Ubuntu packages derived from Debian, I'm only interested in lintian
errors introduced by the Ubuntu delta. It'd be nice to have tooling that
provides this. In the absence of that, I have always ignored lintian for
Ubuntu because it didn't necessarily start off clean in Debian, and I
don't expect to carry delta in Ubuntu to clean it.
But that's just my personal opinion on lintian and Ubuntu. There's
nothing to stop whatever lintian functionality we want to be output as
part of a local build step using "git ubuntu build", much like debuild
does.
I also didn't talk of PPAs, but for those who'd like to upload to a PPA
for testing, and also see autopkgtest running against a PPA, "git ubuntu
publish" could upload to one.
So the steps could be:
1. Make changes
2. git ubuntu build, which would include lintian output (for both source and
binaries).
3. Local testing and iteration, back to 1.
4. git ubuntu publish to a PPA, possibly implemented by ppa-dev-tools.
5. ppa-dev-tools workflow for autopkgtests there.
6. git ubuntu submit
7. After approval, git ubuntu publish.
> 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?
git-ubuntu build could build a source package first, and then warn you
about a mismatch against the tree it built from. That could also be
checked by the other subcommands as appropriate, and this information is
cacheable ("git tree with hash X round trips correctly"). Would that be
sufficient?
If you insist on getting the source package yourself, git-ubuntu build
-S would continue to be available, though we need to figure out how to
neatly integrate that with where you intend/promise to place rich
history.
> While git-ubuntu is still maturing, some developers might also want to
> review its output (debdiff? less foo.changes?) before committing.
Then we can arrange for "git ubuntu publish" to provide that as an
option with a configurable default.
>
> > 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...
I'm not so sure about this. Currently I do use debdiff manually to
double check that the output is the same as what I expect before I
upload. But what I expect is provided by "git diff", so every time I do
this, I think it can be straightforwardly automated and I wish I'd
implemented it already. I also go via a source package on the way to
sbuild for local testing, but that's also something that can be
automated with "git ubuntu build". This doesn't seem so difficult. What
other essential workflow elements am I missing?
> ...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.
I have no problem with that. But we lock in the CLI as we implement the
subcommands. So we can implement subcommand wrappers, but keeping in
mind that they won't the eventual ones, and avoid the name collision. I
don't expect to implement "git ubuntu publish" soon, for example.
