What is IMHO crucial is the understanding that the part of Fedora
infrastructure facing maintainers *needs* to respect the fact that
each (upstream) project is different, has different workflow, version
control system, way to make releases and to ship them, ... . Thus
Fedora must allow different approaches for different package(r)s.
A lot of automation would be appreciated, but it would turn to great
pain if enforced.
So, allow to go with PR-only workflow. Allow the PRs to be tested and
allow them to be automatically merged after passed testing, if the
maintainer sets so.
Opening PRs by release monitoring would be nice. Though the release
monitoring doesn’t work for my pkgs, since upstream does a series of
changes, git submodules fetching, and patching by other projects
before they release the tarball meant to be used as the sources.
Though it takes days to weeks after the upstream mark a certain commit
as “this we will release as version X.Y.Z.”, before they prepare the
tarball and test it for every channel they support.
Also, I *strongly believe*, we - as a significant GNU/Linux distro -
should use tools as are intended, instead of contrariwise.
And I believe the Git commit messages weren’t ever supposed to contain
magic words which will be parsed by some other tooling in order to
take actions. The annotated tags, on the other hand, seems (to me)
like a brilliant idea allowing us to kill the changelog that so much
maintainers desire to.
At the same time, there is so little documentation about “the right
way” to do things, as they are meant to. And only a small amount of
packagers knows the right ways and even less are taking them.
Commit messages are often useless as they don’t explain what changed,
why, and how. Patches doesn’t have any comments. Specfiles often
doesn’t have any good comments too - what the patch does, what for is
this dependency, why is that bundled, why is that test disabled, why
the build flags override … . (not only just) Provenpackages walking
around introducing changes that doesn’t make sense and doesn’t even
have a good justifications. Some people don't even care about e.g.
mentioning bundled part of the code … .
Working with other people’s packages are really hard. But IMHO, mostly
because of the people … .
As I work with newcomers, I see that it is really hard for new faces
to start - both before becoming packagers and even after that.
A huge number of tools and places they *should ideally* work with -
dist git, bodhi, bugzilla, PRs, pagure (to reach rel-engs), FAS,
koschei, abrt, anytia, modularity, wiki pages about the packages, wiki
pages about the changes, mailing lists, IRC, rpmlint, testing, … .
Even I find difficult to explore the full toolset that Fedora offers
and after years I still have no idea what the infrastructure looks
like, or where should I look it up.
And what is IMHO missing is the easy to explore documentation, or at
least some map of tools, ways and places with a “you are standing
here” mark and easy way to understand how to get where you want to be.
A huge FAQ (which would just link to the part of the documentation
with the answer) might help too, as I constantly see people new around
me asking the same questions again and again. Example questions: “can
I delete a branch? How to set EOL date for a module - it still keeps
building. How to write this and that in RPM. what to write to
changelog, what to commit message, what to bodhi update message, … ?
What does men the “rm -rf $RPM_BUILD_ROOT” in %install section? What
does that macro means? How do I find macro for this? Never heard of
“%{?systemd_requires}”, what’s that good for? Hey, you made that
scratch build just for aarch64 - how? ...”
All other observations, based on previous 200 mails, I’d summarize as:
*Please do:*
- kill changelog, please
- by annotated git tags, please
- Unificate the authentication methods
- Make release monitoring submit PRs instead of patches to bugzilla
- Give packagers tools for working with the distribution (e.g. show me
my dependency tree.)
- Tools to maintain the package as a part of ditro, instead of alone
- "Give me a list of all the things my package depends on, what
hasn't been updated in X years"
- “rebuild things that depend on my package upon this commit”
- unified web UI with all the information & build states and a unified
CLI client for doing literally everything.
- Allow to adjusts packager’s workflow as he wants (in some mantinels)
via automatization
- here I mean mostly automated testing, reporting, bodhi updates
(templates?), PR merging
*Please don’t:*
- require {most of the ideas} (like PR-only access, single branch,
source git, every commit is built...)
- because they just doesn't work for everybody
- Kill ancient artifact around Fedora packaging (e.g. “rm -rf
$RPM_BUILD_ROOT” in `rpmdev-newspec`, about which newcommers still
asking )
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
