I'm late to the party, but here we go anyway.

Pierre-Yves Chibon <pin...@pingoured.fr> writes:

> [snip]
> Here is what the vision we came to and that we would like to discuss:
> ○ Every changes to dist-git is done via pull-requests

As long as this is not mandatory, sure.

> ○ Pull-requests are automatically tested
> ○ Every commit to dist-git (ie: PR merged) is automatically built in koji

Make that every tag and we are sold.

> ○ Every build in koji results automatically in an update in bodhi
> ○ Every update in bodhi is automatically tested
> ○ If the tests pass, the update is automatically pushed to the repository

So no more user's testing being able to test updates manually? I have
packages where I'd actually prefer them to be tested manually (i3,
i3status, i3lock, sway et al), because I haven't had the time to setup
openQA for these yet.

> For this workflow to work nicely we need to fix a few things first:
> - We need to work on the change logs in the spec files, as otherwise
>   pull-requests are going to conflict more often than not

Let's please just get rid of them and the same for the Release tag (that
should be automatically bumped by the build system on each rebuild, as
we want automatic rebuilds, don't we?).

> - We need to fine a place to insert the end-user information about an update 
> (in
>   the PR description?)

The git tag as Randy & Jeremy suggested.

> [snip]
> Do you like this vision? Would you change some pieces of it? Would you change 
> it
> entirely?
> In an ideal world, what would packaging software look like to you?

Like a combination of our current way of doing things combined with
openSUSE's Open Build Service (not only the automatic rebuild part,
although that is nice too).

What imho OBS did right is that it provides a single entry point for
packaging: a unified web UI with all the information & build states and
a unified CLI client for doing literally everything.
You want to update package `foo`? `osc branch devel:FooProj:foo && osc
checkout home:MyUserName:branches:devel:FooProj:foo`, make your changes
there, commit them and send a submitrequest (something like a pull
request). You want to become maintainer of a package? `osc
reqmaintainership`. Who maintains `bar`? `osc maintainer bar`. And so

So what I'd love to see would be the single entry point to packaging
that Christopher described, not only as a web application, but also as a
CLI client.

To be more specific:
- My package's spec file is tracked in dist-git or git + git-lsf,
  depending on a setting I'll either have one branch for all the Fedora
  & EPEL versions or one branch for each version.

- Commits to the repository result in CI run (a default one, like
  rpmlint + additional custom tests). I can push -f all commits since
  the last tag, but nothing before that. Once I tag a commit, it is
  build "for real" (and tested) and automatically submitted as an update
  to bodhi. The changelog gets generated from the tag message and
  included into bodhi.
  On the other hand it must be possible to submit multiple packages as
  an update. I could imagine something like a `fedpkg update-multiple
  package1:$commit1 package2:$commit2 -m $message` that would tag the
  specified commits and push all builds into a single update to bodhi.

- the-new-hotness will send pull requests once a package is updated
  upstream. The pull request gets built & tested as an ordinary commit
  would. As a packager I have the option to "merge + tag" (also being
  able to modify the tag), which automatically submits this as an
  This would tremendously simplify the update process for most of my

- If I would have a package that requires a lot of patches, then I can
  be granted the option to use source-git and keep my patches as commits
  on top of an upstream branch. This should imho require some form of
  approval though, as this can easily escalate into hundreds of patches.

- Package updates cause a rebuild of all dependencies (+ a test run of
  each of these). Only a successful rebuild is allowed to be submitted
  to bodhi.

- Allow the creation of package "namespaces" or "projects" (stolen from
  OBS' development projects): a packager or a group can create a
  namespace on the git forge, into which they can fork/link arbitrary
  packages from the distribution. The forked packages become a part of
  the buildroot of this namespace, all others are inherited from the
  distribution itself and are unaffected by changes in this namespace.

  This should allow packagers to run experiments which do not affect the
  distributions build root, but still be able to test the impact of
  their changes on a larger set of packages. Packagers should then be
  able to send their changes back via a mass-pull-request/mass-commit.

- Extend the fedpkg CLI to support more actions on pagure, e.g. finding
  out who is the current package maintainer of Foo or forking the
  package Bar and sending a PR back.

Hope all of this makes sense and would be something that is worth



Attachment: signature.asc
Description: PGP signature

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to