On Mon, Feb 20, 2017 at 7:24 PM, Adam Williamson
On Mon, 2017-02-20 at 18:24 -0500, Neal Gompa wrote:
> I for one don't actually want Rawhide to be gated because it makes
> things much harder in terms of properly developing new features. We're
> simply not capable of being as good as OpenSUSE in terms of automation
> to be able to pull off the feats they do. There were major changes to
> how OpenSUSE did packaging to begin with to be able to pull off what
> they did, and I simply don't think anyone here is prepared to do even
> a small bit of that yet.
This is vague and non-actionable. What, specifically, do you think will
be a problem, and what, specifically, do you think needs changing to
fix the problem?
So, off the top of my head, there are a few things here:
* Version-Release formatting in Fedora packages is too complicated. We
store part of the upstream versioning in the Release field, making it
way more difficult to safely and sanely bump the release
automatically. Moving that information out of Release and back into
Version (where it belongs) drastically simplifies the Release field,
which leads to...
* Automatic rebuilding of dependency chains and submitting them as
part of updates. Right now, it's a ton of work to go through and find
the reverse dependencies of a package and build that chain and submit
it as part of an update. It should be that once someone has updated a
package past some kind of dependency drift point (could be any update
bumping the version or based on library soname or whatever), the
reverse dependencies should automatically be calculated, bumped with
an automatically generated changelog entry and release field bump, and
appended to an update (or just rebuilt and merged right back in after
an update package is pushed). There is way too much grunt work
involved in building dependency chains, and we don't seem to have any
will to fix that. Koschei already does a lot of this with scratch
building, but I do not think they should be scratch builds, and
instead should be actually submitted.
* We need actual post-build checks to occur right after the build,
using rpmlint and other tools. Right now, no one knows *anything*
about the usefulness of a package until we submit to Bodhi. That's
*way* too late in my view, and doesn't even make sense. As far as I
know, Koji has some (weak) support for post-build checks like SUSE's
OBS has, and we should be incorporating things like rpmlint, package
scans, etc. that Taskotron does as part of a post-build check *before*
updates are submitted. And the general disdain for package linting
needs to die. Being sloppy with our packaging because we can't know
whether our own tools are telling us the right thing is a terrible
Some other nice-to-haves that should probably make our lives a bit easier:
* Finding ways to eliminate Epoch as a general matter of consideration
for packagers. That means figuring out how to retool Fedora so that
Epoch doesn't need to persist beyond a single release. We can already
handle this with distro-sync in DNF, but if there are other pieces,
they need to be fixed up too. At first glance, this doesn't seem like
something all that important, but Epoch throws people off quite a bit
when setting up package dependencies, because it's not a field that we
usually use, and it's not always obvious when we're using it. Not to
mention, now that we don't actually need it to ensure upgrade paths,
we should try to get rid of it whenever we can. And this business of
"rawhide going down being bad" needs to die in a fire, since nobody
should be reasonably NOT using distro-sync in Rawhide or going to a
new Fedora release.
* Pushing to eliminate more scriptlets that people have to drop into
packages. Either turn the scriptlets into one-liner macros, turn them
into file triggers, or turn them into some kind of inotify thing so
that people *do not have to think about them*. Ideally the Scriptlets
page in the wiki should be nearly all including warnings that they
aren't to be used in Fedora. We've actually made some good progress on
this, but we've stalled out a bit...
* A dedicated application for doing package reviews. Bugzilla is
horrible for this. If you think Bugzilla is a good tool for this, then
you have Stockholm Syndrome somehow, because it's a really crappy
workflow. Ideally, it should be something that plugs into our build
infrastructure, so that as changes are made during a package review,
they are tracked and the reviewer can see the differences as they
come. OpenSUSE's OBS actually has this built into their system. The
"submit requests" provide exactly the same functionality in a rather
lightweight manner, and allow reviewers to look at *everything*,
including the contents of tarballs being submitted, if they want to.
Having a dedicated application that also does things like enable the
reviewer to go through the fedora-review checklist quickly and
accurately would make things much smoother.
There's probably more, but I can't remember all the things right now...
真実はいつも一つ！/ Always, there's only one truth!