On 9/24/26 01:52, Gordon Messmer wrote:
I’d like to discuss adding “upstream-release branches” in Fedora
dist-git. Although it’s a small change, I expect we’ll need to discuss
various aspects in detail, in a series of threads. Among other topics,
we will probably discuss whether those branches can be automated to
avoid increasing maintainer workload (I think we might have the
confidence to do that since they wouldn’t be used directly by
distribution releases). We’ll need to review previous
branch-management implementations to see if any previous work is
reusable or needed. We’ll need to discuss whether there are concerns
specific to Forgejo. We’ll probably discuss whether we can use quay.io
and the existing Flatpak registry or if a separate registry is needed.
But before we discuss any of those topics, I’d like to hear first from
people who think that this would help them. Would having branches that
track upstream releases, so that they can build an application and
dependencies decoupled from the distribution release, targeting a
container output make it easier to build a package that you maintain?
Would it make it possible to build something that you would like to
build but currently cannot? Would these tools be useful to you outside
of Fedora, to build software for your own?
TL;DR easier does not mean better.
A lot to unpack here, but the base of it, i.e. tracking the exact
dependencies that upstream has (probably down to the toolchains), that I
do not find it a good direction. We have mechanisms to package multiple
versions of dependencies as the language/ecosystem allows it, and in
other cases we have vendoring. But I do not see the vendoring as being
good for the overall health of the ecosystem, both for downstream and
upstream projects themselves.
How many projects in the vendored list have not been updated, have dead
upstream, have been obsoleted, etc. I see on a regular basis our
packagers contributing to upstream making things compatible with the
latest versions, flagging important vulnerability updates, and just
coming up with better improvements in the tooling ecosystem. Seeing this
makes me incredibly happy and proud to be part of this community and
effort. Let's not go into packager burnout and anything in this thread,
and just acknowledge all of the hard work everyone is putting on a
regular basis, and just close it here with an unbound thank you to everyone.
But with the move towards vendoring, I can't help but feel that we risk
losing out this contribution that we have been doing. Sure we have tools
for detecting CVEs in vendored dependencies, but that's only one narrow
part of how we contribute to upstream. We do not have tools to bump the
dependencies versions, and nor do I think we should do that vendored
dependencies, because to which version do we do? I do understand the
case for golang where the whole ecosystem is actively working against a
packaging index, but I don't think it would be good to push this to the
other ecosystems as well which can work well without it.
I can understand that some packagers veiwpoint of just wanting to get
something out the door and have the package done and ready to use. But
what about the maintenance? I would appreciate if proposals such as
these come with receipts of the experience in the maintenance and having
gone through all of the ways things are going wrong. E.g. the openssl4
transition was not fun for the rust packages that were vendoring. Or
even the day-to-day maintenance experience after going through the
hurdle of getting a whole rust dependency tree to work, which I do not
find that daunting (mostly due to help of everyone's collaboration).
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
