On Tue, Oct 6, 2020 at 1:49 AM Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
Lo!
Am 05.10.20 um 22:36 schrieb GitLab Bridge on behalf of dzickusrh:
> From: Don Zickus <dzickus(a)redhat.com>
>
> This in spirit reverts 0409b218390b564c44dd0181c5d0fe177d4c6bc3
> and converts the broken out Red Hat patches back into a single diff.
I don't like that idea. And as mentioned a few month ago: I think it's
violating the Fedora packaging guidelines, see first para of this:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
Hence I think you should get this vetted by the Fedora packaging comittee
or work with them to update the guidelines, as there were reasons why they
were written like that.
It does still meet with the packaging guidelines, we have an upstream
tarball, and then a patch applied. The patch is broken out from
upstream and separated. Prior to ark, it was not uncommon for us to
have a single patch file which included a number of patches. Though I
did not feel that it necessarily met with the spirit of the
guidelines, which is why I recommended the patchlist with commit
hashes. We are not trying to hide anything, but we are trying to make
things actually work. For a couple of months now, it has been
impossible to generate a working dist-git simply following the
documentation. I have an ark commit script which I have to modify from
time to time which will edit patches so they still apply, etc. The
end goal is to make it *much* easier for people to contribute to ark,
and make it possible for people to generate a working dist-git by
simply following the directions.
In addition, by letting us move to a single merge tree instead of a
rebase tree, we end the problem of having to rebase ark-patches from
time to time. As a rebase rewrites history, it creates a problem
where any pending merge request gets completely messed up and needs to
also be rebased, no longer applying until it has been. This patch
doesn't change that workflow, but is a pre-req to make it happen. The
goal is to get it all in this week before the merge window.
Anyway, I didn't give this a try, but I have a comment on this
line:
> +git log --no-merges --pretty=oneline --no-decorate master.. $EXCLUDE_FILES \
> + > $SOURCES/Patchlist.changelog
Would be nice if those could be links to the commits in question,
as that makes it easy to look at them. How about something like this:
$ git log --no-merges --pretty=oneline --no-decorate master..$EXCLUDE_FILES | sed
's!^!https://gitlab.com/cki-project/kernel-ark/-/commit/!; s! !\n !; s!$!\n!' >
$SOURCES/Patchlist.changelog
Then something (note: I did it with some random git tree I had at hand,
not with kernel-ark, hence the URLs won't work) like this
a755240762dd07bb48cf3e561b1e6cfa894f9178 docs: reporting-bugs: add SPDX tag and license
hint, remove markers
42d0e4956abf7ea2b0ea15f56afb1720a11739f1 docs: reporting-bugs: explain things could be
easier
aac1d02c1ca7d4a20dfe47ae6f824e1091c654e3 docs: reporting-bugs: explain why users might
get neither reply nor fix
Becomes
https://gitlab.com/cki-project/kernel-ark/-/commit/a755240762dd07bb48cf3e...
docs: reporting-bugs: add SPDX tag and license hint, remove markers
https://gitlab.com/cki-project/kernel-ark/-/commit/42d0e4956abf7ea2b0ea15...
docs: reporting-bugs: explain things could be easier
https://gitlab.com/cki-project/kernel-ark/-/commit/aac1d02c1ca7d4a20dfe47...
docs: reporting-bugs: explain why users might get neither reply nor fix
This is not a bad update. I would be okay with this, though it does
make it less simple for people working in an actual git tree, having
to select the commit hash carefully vs just a double click to copy.
Justin