On Tue, Jun 8, 2021 at 9:22 AM Ahmad Samir <a.samir...@gmail.com> wrote: > > On 07/06/2021 22:52, Albert Astals Cid wrote: > > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va > > escriure: > >> Hello folks, > >> > >> The Fedora packagers were mentioning to me today that it would be a lot > >> easier for them to ship Qt with our patch collection if we made tags and > >> tarballs. Is this something we could look into doing? > > > > We explicitly do not want to make releases > > https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F > > > > Making a release means having to use of a version number, and any version > > number we use will be wrong. > > > > Don't think this as a product, think of it as a central place where patches > > are collected. > > > > If they want a tarball because using git is a problem, they can always use > > https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 > > ? > > > > Cheers, > > Albert > > > Alternatively they could treat it like backported kernel patches? > https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/Patchlist.changelog > I don't know the > details but it's doable is what I am saying. > > The thing is, IIUC the KDE Qt patch curators don't want to create a release, > just a set of > "important" patches on top of the last open-source Qt release, i.e. deal with > it like any other > project whose upstream hasn't made any new releases in a long time, but there > are new commits in > git; I am sure most distro packagers have seen one or two cases as such. >
The kernel has a weird, special workflow that no other package does. It's because the RHEL kernel and Fedora kernel sources are merged and non-upstream RHEL-ish changes are now always present in the source tree. -- 真実はいつも一つ!/ Always, there's only one truth!