[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Documenting packaging workflows (was: finally end single-person maintainership)



Quoting Luca Boccassi (2024-05-22 01:45:54)
> On Wed, 22 May 2024 at 00:40, Russ Allbery <rra@debian.org> wrote:
> > For what it's worth, what I do for the packages for which I'm also
> > upstream is that I just add Salsa as another remote and, after I upload
> > a new version of the Debian package, I push to Salsa as well (yes,
> > including all the upstream branches; why not, the Debian branches are
> > based on that anyway, so it's not much more space).  One of these days
> > I'll get CI set up properly, and then it will be worthwhile to push to
> > Salsa *before* I upload the package and let it do some additional
> > checking.
> >
> > It's still an additional step, and I still sometimes forget to do it, but
> > after some one-time setup, it's a fairly trivial amount of work.
> >
> > It's more work to accept a merge request on Salsa and update the
> > repositories appropriately, since there are two repositories in play, but
> > in that case I'm getting a contribution out of it that I might not have
> > gotten otherwise, so to me that seems worth it.
> >
> > I used to try to keep the debian directory in a separate repository or try
> > to keep the Debian Git branches in a separate repository, and all of that
> > was just annoying and tedious and didn't feel like it accomplished much.
> > Just pushing the same branches everywhere is easy and seems to accomplish
> > the same thing.
> 
> Yeah I am doing the same, and gradually switching all my packages that
> used to have a separate upstream/downstream history to a single merged
> tree. This can be done post-facto with some one-time git rocket
> surgery, doesn't have to be the case from day one. It's a huge
> improvement, and with gpp patch-queue I can just cherry-pick upstream
> commits directly, with no hassle whatsoever. It works really nicely,
> and gbp supports it just fine as a workflow, even while still checking
> in upstream release tarballs in pristine-tar.

I would be *very* interested in more in-depth write-ups of the workflows other
DDs prefer to use, how they use them and what they think makes them better than
the alternatives.

Personally, I start packaging something without git, once I'm satisfied I use
"gbp import-dsc" to create a packaging git with pristine-tar (and that will
*not* have DEP14 branches and it will use "master" instead of "main") and then
I push that to salsa and do more fixes until the pipeline succeeds and lintian
is happy. My patches are managed using quilt in d/patches and upstream git is
not part of my packaging git. I upload using "dgit --quilt=gbp push-source".

Would another workflow make me more happy? Probably! But how would I get to
know them or get convinced that they are better? Maybe I'm missing out on
existing write-ups or video recordings which explain how others do their
packaging and why it is superior?

Any hints or future debconf workshop invitations welcome. :)

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: