Fedora kernel workflow feedback

[Don Zickus]

Hi,

For those that don't know me, my name is Don Zickus, a RHEL kernel engineer
for the last decade or so.  I am the group lead of various projects
including the Fedora kernel workflow changes.

I know as Jeremy and Justin have rolled out changes recently there have been
concerns over technical and non-technical issues.  While they are happy to
make various tweaks to the workflow that might have broken during the
conversion, I am asking for some of the bigger concerns, folks reach out to
me.

A couple of years ago, I convinced Laura Abbott and Jeremy to pursue this
workflow change with me and they implemented the pieces to make this work.
Laura even gave a talk about this at Flock in 2019.

I am sure there are pieces we overlooked in our attempt to change the
workflow and over the next few months we will try to address what makes
sense.  I just ask folks to redirect their concerns to me and work with us
to get them resolved.

The two concerns I am aware that need addressing are:
* broken out patches
* handle drive-by users who know dist-git by not the source git tree

Is there any other large concern with the new workflow?

-----
Why did we go this way?
* The goal was to create a proper development environment and have
  developers use the Fedora ecosystem to do their work in a natural way and
  easily leverage creating and building rpms, using CI services and any
  other Fedora infrastructure.  IOW make it easier to use Fedora as the
  place to do development.
* Another goal was to respectfully integrate the RHEL kernel workflow
  (_without_ removing Fedora freedoms and liberties) such that our partners
  and customers can contribute to the stability of this kernel in
  preparation for future RHEL kernels.  Increasing focus on Fedora kernel
  was considered a good thing.

The downside of this approach is the impact on those users who prefer a
dist-git world.

The result we have today is what the RHEL development world has looked like
for 10+ years.  Is it perfect? No.  Is there better ways to do things?
Absolutely.

The Fedora kernel is not the only package going in this direction.  Dozens
of other packages are looking to packages like the kernel to see what this
world would look like.  As a leader in this direction, there will be
unforseen bumps that we need to work through.

However, over time, we would like this new source git tree world to be a new
type of standard and the dist-git world a mechanical back-end process.

We understand not everyone will agree with this change, but are hopeful that
we can work with everyone to address the concerns respectfully and still
achieve our goal of having Fedora be the easiest and most natural way to do
upstream development.

Thanks!

Cheers,
Don

[Thorsten Leemhuis]

Hi Don!

Am 17.04.20 um 20:55 schrieb Don Zickus:
>  
>  I know as Jeremy and Justin have rolled out changes recently there have been 
>  concerns over technical and non-technical issues.  While they are
> happy to 
>  make various tweaks to the workflow that might have broken during the
>  conversion, I am asking for some of the bigger concerns, folks reach
> out to 
>  me. 
FWIW from the perspective of someone that deals with kernel.spec in his
spare time occasionally I think the conversation worked mostly well. Thx
for that. A bit of fine tuning might be needed here and there, but well,
that's often the case in situations like this :-D

>  I am sure there are pieces we overlooked in our attempt to change
> the
>  workflow and over the next few months we will try to address what makes
>  sense.  I just ask folks to redirect their concerns to me and work with us
>  to get them resolved.
>  
>  The two concerns I am aware that need addressing are:
>  * broken out patches 
Which is already in the works (thx again Jeremy!)

>  * handle drive-by users who know dist-git by not the source git tree
A few additional comments in the spec file and the readme that Jeremy
proposed will take care of most of it afaics. And one more thing, see
next part of this reply.

>  Is there any other large concern with the new workflow? 
The more I think about this the more I dislike that we are not using
official, pristine tarballs anymore. This "Source0 is a tarball
generated from a git tree maintained outside of the Fedora infra and
patched with buildscripts" IMHO violates the intention of the SourceURL
part of the Fedora Packaging Guidelines that was put in place for good
reasons (by both red hat and community contributors):
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/

This can be fixed afaics, as it was already discussed in this mail and
the answer to it:
https://lists.fedoraproject.org/archives/list/[e-mail]....

Yes, it will be some work, but I think it would be wise to do that "to
cleanly separate upstream source from vendor modifications" (that's a
quote from the guidelines).

CU, knurd

[Thorsten Leemhuis]

Just a quick clarification:

Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
>  Am 17.04.20 um 20:55 schrieb Don Zickus: 
> > Is there any other large concern with the new workflow?
>  
>  The more I think about this the more I dislike that we are not using
>  official, pristine tarballs anymore. This "Source0 is a tarball
>  generated from a git tree maintained outside of the Fedora infra and
>  patched with buildscripts" IMHO violates the intention of the SourceURL
>  part of the Fedora Packaging Guidelines that was put in place for good
>  reasons (by both red hat and community contributors):
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
>  
>  This can be fixed afaics, as it was already discussed in this mail and
>  the answer to it:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]....
>  
>  Yes, it will be some work, but I think it would be wise to do that "to
>  cleanly separate upstream source from vendor modifications" (that's a
>  quote from the guidelines). 
Note: What I wrote might sound like I want to stick to tarballs forever.
That is not the case, I only would prefer something where all vendor
modifications are clearly separated from the sources upstream released
(which was the case for the kernel.spec until a few days ago). IOW: I'm
totally fine if RPM and/or Dist-Git learn to understand source URLs that
download sources from a signed tag somehow (say: "Source0:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...
– which is a bad example, as that is a tarball again, but you get the idea).

CU, knurd

[Don Zickus]

On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote:
>  Just a quick clarification:
>  
>  Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
>  > Am 17.04.20 um 20:55 schrieb Don Zickus:
>  
>  >> Is there any other large concern with the new workflow?
>  > 
>  > The more I think about this the more I dislike that we are not using
>  > official, pristine tarballs anymore. This "Source0 is a tarball
>  > generated from a git tree maintained outside of the Fedora infra and
>  > patched with buildscripts" IMHO violates the intention of the SourceURL
>  > part of the Fedora Packaging Guidelines that was put in place for good
>  > reasons (by both red hat and community contributors):
>  > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
>  > 
>  > This can be fixed afaics, as it was already discussed in this mail and
>  > the answer to it:
>  >
> https://lists.fedoraproject.org/archives/list/[e-mail]....
>  > 
>  > Yes, it will be some work, but I think it would be wise to do that "to
>  > cleanly separate upstream source from vendor modifications" (that's a
>  > quote from the guidelines).
>  
>  Note: What I wrote might sound like I want to stick to tarballs forever.
>  That is not the case, I only would prefer something where all vendor
>  modifications are clearly separated from the sources upstream released
>  (which was the case for the kernel.spec until a few days ago). IOW: I'm
>  totally fine if RPM and/or Dist-Git learn to understand source URLs that
>  download sources from a signed tag somehow (say: "Source0:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...
>  – which is a bad example, as that is a tarball again, but you get the idea). 
Hi knurd,

Thanks for the feedback!  I believe we would like to work out a solution for
this.  But as Jeremy and Laura (in your reference thread) pointed out, there
are multiple ways to solve this.  It comes down to what is a reasonable and
comfortable approach for the community.

Signed tags could work, but they are only applied to releases, not the -rcX
updates.  So there is limitation to that.

Looking through the Fedora Doc you posted, they seem to provide examples of
using a git commit for reference (despite kernel.org using tarballs).  In
essence that is what we are doing, using more of the upstream commit and
generating our own tarball from that commit.

Obviously, the problem comes down to trust.  Just trying to figure out the
most reasonable way to prove we didn't make any mistakes when generating the
tarball using the tools we have available.

Thoughts?

Cheers,
Don

[Thorsten Leemhuis]

Am 20.04.20 um 18:55 schrieb Don Zickus:
>  On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote:
> > Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
> >> Am 17.04.20 um 20:55 schrieb Don Zickus:
> >>> Is there any other large concern with the new workflow?
> >> The more I think about this the more I dislike that we are not using
> >> official, pristine tarballs anymore. This "Source0 is a tarball
> >> generated from a git tree maintained outside of the Fedora infra and
> >> patched with buildscripts" IMHO violates the intention of the SourceURL
> >> part of the Fedora Packaging Guidelines that was put in place for good
> >> reasons (by both red hat and community contributors):
> >> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
>  […]
>  Thanks for the feedback!  I believe we would like to work out a solution for
>  this. […]> Signed tags could work, but they are only applied to releases, not the
> -rcX> updates.  So there is limitation to that.
>  
>  Looking through the Fedora Doc you posted, they seem to provide examples of
>  using a git commit for reference (despite kernel.org using tarballs).  In
>  essence that is what we are doing, using more of the upstream commit and
>  generating our own tarball from that commit.
>  
>  Obviously, the problem comes down to trust.  Just trying to figure out the
>  most reasonable way to prove we didn't make any mistakes when generating the
>  tarball using the tools we have available.
>  
>  Thoughts? 
This overlaps a bit with my reply I just sent to Jeremy  (
https://lists.fedoraproject.org/archives/list/[e-mail]....
), nevertheless:

How about something like this:

* For Source0 on Rawhide with its daily snapshots use something like this:
Source0:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...
(taken from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...

Use something like this everywhere else:

Source0:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot...

* For rawhide and its daily snapshots just trust what everyone can download at
git.kernel.org. Everywhere else verify the signed tag in the %prep section of the spec
file just like the packaging guidelines suggest:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_sig...

CU, knurd

[Don Zickus]

On Tue, Apr 21, 2020 at 05:44:14PM +0200, Thorsten Leemhuis wrote:
>  Am 20.04.20 um 18:55 schrieb Don Zickus:
>  > On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote:
>  >> Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
>  >>> Am 17.04.20 um 20:55 schrieb Don Zickus:
>  >>>> Is there any other large concern with the new workflow?
>  >>> The more I think about this the more I dislike that we are not using
>  >>> official, pristine tarballs anymore. This "Source0 is a tarball
>  >>> generated from a git tree maintained outside of the Fedora infra and
>  >>> patched with buildscripts" IMHO violates the intention of the
> SourceURL
>  >>> part of the Fedora Packaging Guidelines that was put in place for good
>  >>> reasons (by both red hat and community contributors):
>  >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
>  > […]
>  > Thanks for the feedback!  I believe we would like to work out a solution for
>  > this. […]> Signed tags could work, but they are only applied to releases, not the
> -rcX> updates.  So there is limitation to that.
>  > 
>  > Looking through the Fedora Doc you posted, they seem to provide examples of
>  > using a git commit for reference (despite kernel.org using tarballs).  In
>  > essence that is what we are doing, using more of the upstream commit and
>  > generating our own tarball from that commit.
>  > 
>  > Obviously, the problem comes down to trust.  Just trying to figure out the
>  > most reasonable way to prove we didn't make any mistakes when generating the
>  > tarball using the tools we have available.
>  > 
>  > Thoughts?
>  
>  This overlaps a bit with my reply I just sent to Jeremy  (
>
> https://lists.fedoraproject.org/archives/list/[e-mail]....
>  ), nevertheless:
>  
>  How about something like this:
>  
>  * For Source0 on Rawhide with its daily snapshots use something like this:
>  Source0:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...
>  (taken from
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
>  
>  Use something like this everywhere else:
>  
>  Source0:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot...
>  
>  * For rawhide and its daily snapshots just trust what everyone can download at
> git.kernel.org. Everywhere else verify the signed tag in the %prep section of the spec
> file just like the packaging guidelines suggest:
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_sig... 
Hi Knurd,

Thanks for the suggestions!  In order to make this merge happen and satisfy
our goals in the timeframe my management chain was looking for, we hacked the
Fedora and ARK trees together in a rather un-clean way.

Implementing your suggested changes make take a little time to go through
the spaghetti we created.  Let me work with Jeremy and Justin about what is
the best course of action.

For now, I am tracking this issue as
https://gitlab.com/cki-project/kernel-ark/-/issues/28 to not lose it.

Does that work for you?

Cheers,
Don

[Thorsten Leemhuis]

Am 22.04.20 um 22:00 schrieb Don Zickus:
>  On Tue, Apr 21, 2020 at 05:44:14PM +0200, Thorsten Leemhuis wrote:
> > Am 20.04.20 um 18:55 schrieb Don Zickus:
> >> On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote:
> >>> Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
> >>>> Am 17.04.20 um 20:55 schrieb Don Zickus:
> > How about something like this:
> > * For Source0 on Rawhide with its daily snapshots use something like this:
> > Source0:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...
> > (taken from
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
> > Use something like this everywhere else:
> > Source0:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot...
> > * For rawhide and its daily snapshots just trust what everyone can download at
> git.kernel.org. Everywhere else verify the signed tag in the %prep section of the spec
> file just like the packaging guidelines suggest:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_sig...
>  […]
>  Implementing your suggested changes make take a little time to go through
>  the spaghetti we created.  Let me work with Jeremy and Justin about what is
>  the best course of action. 
Thx.

>  For now, I am tracking this issue as
>  https://gitlab.com/cki-project/kernel-ark/-/issues/28 to not lose it.
>  Does that work for you? 
Yeah, sure, no need to hurry.

BTW: I know, renaming branches is hard, but when you go thought the
spaghetti could you please consider renaming the "internal" branch to
something more intuitive? I have no better name at hand, but "rpmify" or
something like that would make it a lot more obvious what the changes in
that branch are about.

Thx for your work, Cu, knurd

[Prarit Bhargava]

On 4/23/20 3:28 AM, Thorsten Leemhuis wrote:
>  Am 22.04.20 um 22:00 schrieb Don Zickus:
> > On Tue, Apr 21, 2020 at 05:44:14PM +0200, Thorsten Leemhuis wrote:
> >> Am 20.04.20 um 18:55 schrieb Don Zickus:
> >>> On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote:
> >>>> Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
> >>>>> Am 17.04.20 um 20:55 schrieb Don Zickus:
> >> How about something like this:
> >> * For Source0 on Rawhide with its daily snapshots use something like this:
> >> Source0:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...
> >> (taken from
> >>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
> >> Use something like this everywhere else:
> >> Source0:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot...
> >> * For rawhide and its daily snapshots just trust what everyone can download at
> git.kernel.org. Everywhere else verify the signed tag in the %prep section of the spec
> file just like the packaging guidelines suggest:
> >> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_sig...
> > […]
> > Implementing your suggested changes make take a little time to go through
> > the spaghetti we created.  Let me work with Jeremy and Justin about what is
> > the best course of action.
>  
>  Thx.
>  
> > For now, I am tracking this issue as
> > https://gitlab.com/cki-project/kernel-ark/-/issues/28 to not lose it.
> > Does that work for you?
>  
>  Yeah, sure, no need to hurry.
>  
>  BTW: I know, renaming branches is hard, but when you go thought the
>  spaghetti could you please consider renaming the "internal" branch to
>  something more intuitive? I have no better name at hand, but "rpmify" or
>  something like that would make it a lot more obvious what the changes in
>  that branch are about.
>   
"os-build" is what I was suggesting.

P.

>  Thx for your work, Cu, knurd
>  _______________________________________________
>  kernel mailing list -- kernel(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>

[Don Zickus]

On Thu, Apr 23, 2020 at 07:36:45AM -0400, Prarit Bhargava wrote:
>  > Thx.
>  > 
>  >> For now, I am tracking this issue as
>  >> https://gitlab.com/cki-project/kernel-ark/-/issues/28 to not lose it.
>  >> Does that work for you?
>  > 
>  > Yeah, sure, no need to hurry.
>  > 
>  > BTW: I know, renaming branches is hard, but when you go thought the
>  > spaghetti could you please consider renaming the "internal" branch to
>  > something more intuitive? I have no better name at hand, but "rpmify" or
>  > something like that would make it a lot more obvious what the changes in
>  > that branch are about.
>  > 
>  
>  "os-build" is what I was suggesting. 

Haha.  Yes.  That seems to be everyone's top suggestion lately. :-)  I will
see what we can do.  Thanks!

Cheers,
Don

[Jeremy Cline]

On Fri, Apr 17, 2020 at 10:06:02PM +0200, Thorsten Leemhuis wrote:
>  Hi Don!
>  
>  Am 17.04.20 um 20:55 schrieb Don Zickus:
>  > 
>  > I know as Jeremy and Justin have rolled out changes recently there have been
>  
>  > concerns over technical and non-technical issues.  While they are happy to
>  
>  > make various tweaks to the workflow that might have broken during the
>  
>  > conversion, I am asking for some of the bigger concerns, folks reach out to
>  
>  > me.
>  
>  FWIW from the perspective of someone that deals with kernel.spec in his
>  spare time occasionally I think the conversation worked mostly well. Thx
>  for that. A bit of fine tuning might be needed here and there, but well,
>  that's often the case in situations like this :-D
>  
>  > I am sure there are pieces we overlooked in our attempt to change the
>  > workflow and over the next few months we will try to address what makes
>  > sense.  I just ask folks to redirect their concerns to me and work with us
>  > to get them resolved.
>  > 
>  > The two concerns I am aware that need addressing are:
>  > * broken out patches
>  
>  Which is already in the works (thx again Jeremy!)
>  
>  > * handle drive-by users who know dist-git by not the source git tree
>  
>  A few additional comments in the spec file and the readme that Jeremy
>  proposed will take care of most of it afaics. And one more thing, see
>  next part of this reply.
>  
>  > Is there any other large concern with the new workflow?
>  
>  The more I think about this the more I dislike that we are not using
>  official, pristine tarballs anymore. This "Source0 is a tarball
>  generated from a git tree maintained outside of the Fedora infra and
>  patched with buildscripts" IMHO violates the intention of the SourceURL
>  part of the Fedora Packaging Guidelines that was put in place for good
>  reasons (by both red hat and community contributors):
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
>   
It sounds like maybe there's confusion about what the new tarball
contains.

The tarballs that are generated and checked into dist-git contain no
Fedora modifications and are directly from a commit or tag Linus's git
tree generated with git-archive[0]. The only thing that changed is
before we took the latest tagged release, then applied an rc patch from
upstream if available, then the snapshot from that week's development as
a patch generated on the maintainer's machine, then applied
Fedora-specific patches. Now we just git-archive Linus's master branch
for the day.

We can download the tarball (created by git-archive on a signed tag)
from kernel.org instead of running git-archive on a signed tag
ourselves if that will really help people sleep at night, but we'll
still be slapping unsigned snapshots on top of that so it's not clear to
me that we'll be gaining much.

[0]
https://gitlab.com/cki-project/kernel-ark/-/blob/internal/redhat/scripts/...


- Jeremy

[Thorsten Leemhuis]

Lo!

Am 20.04.20 um 16:41 schrieb Jeremy Cline:
>  On Fri, Apr 17, 2020 at 10:06:02PM +0200, Thorsten Leemhuis wrote:
> > Am 17.04.20 um 20:55 schrieb Don Zickus:
>  […]
> >> Is there any other large concern with the new workflow?
> > The more I think about this the more I dislike that we are not using
> > official, pristine tarballs anymore. This "Source0 is a tarball
> > generated from a git tree maintained outside of the Fedora infra and
> > patched with buildscripts" IMHO violates the intention of the SourceURL
> > part of the Fedora Packaging Guidelines that was put in place for good
> > reasons (by both red hat and community contributors):
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
>
>  It sounds like maybe there's confusion about what the new tarball
>  contains. 
Yes, there…

>  The tarballs that are generated and checked into dist-git contain no
>  Fedora modifications and are directly from a commit or tag Linus's git
>  tree generated with git-archive[0]. 
…indeed was. I apologize for getting this wrong. Just one suggestion in
that case:

>  The only thing that changed is
>  before we took the latest tagged release, then applied an rc patch from
>  upstream if available, then the snapshot from that week's development as
>  a patch generated on the maintainer's machine, then applied
>  Fedora-specific patches. Now we just git-archive Linus's master branch
>  for the day. 
Can't we make that clearer by using something like this?

Source0:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...

That was for 5.7-rc2 and makes it obvious where I can download this from
if I do not trust the contents of the SRPM. And/or a comment right
before the Source0 line that explains the situation for ordinary people
might be good enough (yes, there is one, but it's hard to understand).

>  We can download the tarball (created by git-archive on a signed tag)
>  from kernel.org instead of running git-archive on a signed tag
>  ourselves if that will really help people sleep at night, but we'll
>  still be slapping unsigned snapshots on top of that so it's not clear to
>  me that we'll be gaining much. 
Yeah, you definitely have a point for rawhide. But once this scheme is
used for stable releases it's a bit different, as there the base will
normally have signed tag.

CU, knurd

[Jeremy Cline]

On Tue, Apr 21, 2020 at 05:23:47PM +0200, Thorsten Leemhuis wrote:
>  Lo!
>  
>  Am 20.04.20 um 16:41 schrieb Jeremy Cline:
>  > On Fri, Apr 17, 2020 at 10:06:02PM +0200, Thorsten Leemhuis wrote:
>  >> Am 17.04.20 um 20:55 schrieb Don Zickus:
>  > […]
>  >>> Is there any other large concern with the new workflow?
>  >> The more I think about this the more I dislike that we are not using
>  >> official, pristine tarballs anymore. This "Source0 is a tarball
>  >> generated from a git tree maintained outside of the Fedora infra and
>  >> patched with buildscripts" IMHO violates the intention of the SourceURL
>  >> part of the Fedora Packaging Guidelines that was put in place for good
>  >> reasons (by both red hat and community contributors):
>  >> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
>  >
>  > It sounds like maybe there's confusion about what the new tarball
>  > contains.
>  
>  Yes, there…
>  
>  > The tarballs that are generated and checked into dist-git contain no
>  > Fedora modifications and are directly from a commit or tag Linus's git
>  > tree generated with git-archive[0].
>  
>  …indeed was. I apologize for getting this wrong. Just one suggestion in
>  that case:
>  
>  > The only thing that changed is
>  > before we took the latest tagged release, then applied an rc patch from
>  > upstream if available, then the snapshot from that week's development as
>  > a patch generated on the maintainer's machine, then applied
>  > Fedora-specific patches. Now we just git-archive Linus's master branch
>  > for the day.
>  
>  Can't we make that clearer by using something like this?
>  
>  Source0:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapsh...
>  
>  That was for 5.7-rc2 and makes it obvious where I can download this from
>  if I do not trust the contents of the SRPM. And/or a comment right
>  before the Source0 line that explains the situation for ordinary people
>  might be good enough (yes, there is one, but it's hard to understand).
>   
I lean towards a clearer comment. If we change the actual Source0 we
have to stop xz-compressing the tarball and change the naming scheme to
line up with the URL naming format.

>  > We can download the tarball (created by git-archive on a signed
> tag)
>  > from kernel.org instead of running git-archive on a signed tag
>  > ourselves if that will really help people sleep at night, but we'll
>  > still be slapping unsigned snapshots on top of that so it's not clear to
>  > me that we'll be gaining much.
>  
>  Yeah, you definitely have a point for rawhide. But once this scheme is
>  used for stable releases it's a bit different, as there the base will
>  normally have signed tag.
>   
We've not actually got any machinery for stable releases yet so I think
we can take that into account when we do that.

- Jeremy