Re: Fedora kernel workflow feedback
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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz >>> (taken from >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae83d0b416db002fe95601e7f97f64b59514d936 >>> Use something like this everywhere else: >>> Source0: >>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.6.6.tar.gz >>> * 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_signatures >> […] >> 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@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org > ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz >> (taken from >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae83d0b416db002fe95601e7f97f64b59514d936 >> Use something like this everywhere else: >> Source0: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.6.6.tar.gz >> * 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_signatures > […] > 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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/kernel@lists.fedoraproject.org/message/PZ3ZCUL2WI7ECONM5HNE6QNZMKTO64VR/ > ), 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/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz > (taken from > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae83d0b416db002fe95601e7f97f64b59514d936 > > Use something like this everywhere else: > > Source0: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.6.6.tar.gz > > * 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_signatures 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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz > > 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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/kernel@lists.fedoraproject.org/message/PZ3ZCUL2WI7ECONM5HNE6QNZMKTO64VR/ ), 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/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz (taken from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae83d0b416db002fe95601e7f97f64b59514d936 Use something like this everywhere else: Source0: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.6.6.tar.gz * 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_signatures CU, knurd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz 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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/kernel@lists.fedoraproject.org/thread/I2JXHKX3P4EIRXGRU7JRY33EBQRCLRI4/#IBRZXHKW72PNN7USTJJHPCQQZJAVOEMD > > > > 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/snapshot/linux-5.7-rc1.tar.gz; > – 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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/create-tarball.sh - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/kernel@lists.fedoraproject.org/thread/I2JXHKX3P4EIRXGRU7JRY33EBQRCLRI4/#IBRZXHKW72PNN7USTJJHPCQQZJAVOEMD > > 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/snapshot/linux-5.7-rc1.tar.gz; – which is a bad example, as that is a tarball again, but you get the idea). CU, knurd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
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/kernel@lists.fedoraproject.org/thread/I2JXHKX3P4EIRXGRU7JRY33EBQRCLRI4/#IBRZXHKW72PNN7USTJJHPCQQZJAVOEMD 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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
Fedora kernel workflow feedback
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 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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/kernel@lists.fedoraproject.org
