Re: streamlining fedora-release (again)
On Thu, Jun 28, 2018 at 06:28:53AM -0400, Stephen Gallagher wrote: > On Wed, Jun 27, 2018 at 9:19 PM Dennis Gilmore wrote: > > > El mié, 27-06-2018 a las 11:58 +, Zbigniew Jędrzejewski-Szmek > > escribió: > > > Hi, > > > > > > I'd like to pick up the process of converting fedora-release from a > > > split "upstream"/"downstream" model into a single repo in src.fp.o. > > > > > > For previous discussions see > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje > > > ct.org/thread/CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C/#CIKK4WEF5ACVWZ6EWBKNH > > > SKKKCDTV27C > > > https://pagure.io/fedora-release/pull-request/119 > > > https://pagure.io/releng/issue/7293 > > > > > > I made the changes requested by Dennis Gilmore > > > (an exploded repo, no tarball) and they are available in > > > https://src.fedoraproject.org/fork/zbyszek/rpms/fedora-release/branch > > > /drop-upstream-split . > > > > > > "Tests" were requested — I tested using rpmdiff and diffoscope that > > > the changes only introduce timestamp differences, and then the > > > subsequent cleanup commits only introduce expected differences > > > (Group tag becomes "Unspecified", the description is updated, > > > whitespace changes in scriptlets). If additional testing is required > > > let me know what. > > > > > > As stated previously, I'm requesting co-maintainership of > > > fedora-release to merge presets requests in reasonable time > > > and to implement the changes described above. > > > > > > Let me know if you need anything else from me now. > > > (I'll revisit the outstanding PRs against fedora-release once > > > the new repo is established, I hope that happens quickly.) > > > > > > Zbyszek > > fedora-release is no longer in my scope of influence, however the > > testing requested was to make sure that any updates do not break the > > package, the reluctance to simplify the process is due to the number of > > times simple patches were submitted that broke things in unintended > > ways. > > > > > > In the recent past, we've had situations where the artificial split itself > resulted in errors because the person merging from upstream to downstream > didn't know that certain packages had to be updated outside the tarball due > to RPM limitations. Having a single repository would have avoided this. > > When you say "the reluctance to simplify the process is due to the number of > times simple patches were submitted that broke things in unintended > ways", it sounds like you're saying "we implemented the separation so we > could prevent this from happening, but in reality it didn't help at all > because the changes still got merged and built downstream". (And yes, I'm > aware that I was responsible for a non-trivial number of those). > > I think that eliminating the redundancy here is an improvement on its own. > I don't believe that adding new testing needs to be a pre-requisite for > this. It can (and should) be done, but we shouldn't block a positive change > waiting for a "perfect" one. Yes, that's my thinking too — we know that the simplified version results in identical packages. If you think some more checks should be added, that's OK, I'd be happy to do that, but a) please be more precise in what exactly those checks should be, b) they would apply to the old setup too in the same way, so this shouldn't block the change. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SGXKSNFUFPSOH4GZ2Y6ZJCFXWRKSDCMG/
Re: streamlining fedora-release (again)
On Wed, Jun 27, 2018 at 9:19 PM Dennis Gilmore wrote: > El mié, 27-06-2018 a las 11:58 +, Zbigniew Jędrzejewski-Szmek > escribió: > > Hi, > > > > I'd like to pick up the process of converting fedora-release from a > > split "upstream"/"downstream" model into a single repo in src.fp.o. > > > > For previous discussions see > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje > > ct.org/thread/CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C/#CIKK4WEF5ACVWZ6EWBKNH > > SKKKCDTV27C > > https://pagure.io/fedora-release/pull-request/119 > > https://pagure.io/releng/issue/7293 > > > > I made the changes requested by Dennis Gilmore > > (an exploded repo, no tarball) and they are available in > > https://src.fedoraproject.org/fork/zbyszek/rpms/fedora-release/branch > > /drop-upstream-split . > > > > "Tests" were requested — I tested using rpmdiff and diffoscope that > > the changes only introduce timestamp differences, and then the > > subsequent cleanup commits only introduce expected differences > > (Group tag becomes "Unspecified", the description is updated, > > whitespace changes in scriptlets). If additional testing is required > > let me know what. > > > > As stated previously, I'm requesting co-maintainership of > > fedora-release to merge presets requests in reasonable time > > and to implement the changes described above. > > > > Let me know if you need anything else from me now. > > (I'll revisit the outstanding PRs against fedora-release once > > the new repo is established, I hope that happens quickly.) > > > > Zbyszek > fedora-release is no longer in my scope of influence, however the > testing requested was to make sure that any updates do not break the > package, the reluctance to simplify the process is due to the number of > times simple patches were submitted that broke things in unintended > ways. > > In the recent past, we've had situations where the artificial split itself resulted in errors because the person merging from upstream to downstream didn't know that certain packages had to be updated outside the tarball due to RPM limitations. Having a single repository would have avoided this. When you say "the reluctance to simplify the process is due to the number of times simple patches were submitted that broke things in unintended ways", it sounds like you're saying "we implemented the separation so we could prevent this from happening, but in reality it didn't help at all because the changes still got merged and built downstream". (And yes, I'm aware that I was responsible for a non-trivial number of those). I think that eliminating the redundancy here is an improvement on its own. I don't believe that adding new testing needs to be a pre-requisite for this. It can (and should) be done, but we shouldn't block a positive change waiting for a "perfect" one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EHLXZBF6OVXQ4FD66GVXGMKHETQWFUCK/
Re: streamlining fedora-release (again)
El mié, 27-06-2018 a las 11:58 +, Zbigniew Jędrzejewski-Szmek escribió: > Hi, > > I'd like to pick up the process of converting fedora-release from a > split "upstream"/"downstream" model into a single repo in src.fp.o. > > For previous discussions see > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje > ct.org/thread/CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C/#CIKK4WEF5ACVWZ6EWBKNH > SKKKCDTV27C > https://pagure.io/fedora-release/pull-request/119 > https://pagure.io/releng/issue/7293 > > I made the changes requested by Dennis Gilmore > (an exploded repo, no tarball) and they are available in > https://src.fedoraproject.org/fork/zbyszek/rpms/fedora-release/branch > /drop-upstream-split . > > "Tests" were requested — I tested using rpmdiff and diffoscope that > the changes only introduce timestamp differences, and then the > subsequent cleanup commits only introduce expected differences > (Group tag becomes "Unspecified", the description is updated, > whitespace changes in scriptlets). If additional testing is required > let me know what. > > As stated previously, I'm requesting co-maintainership of > fedora-release to merge presets requests in reasonable time > and to implement the changes described above. > > Let me know if you need anything else from me now. > (I'll revisit the outstanding PRs against fedora-release once > the new repo is established, I hope that happens quickly.) > > Zbyszek fedora-release is no longer in my scope of influence, however the testing requested was to make sure that any updates do not break the package, the reluctance to simplify the process is due to the number of times simple patches were submitted that broke things in unintended ways. Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RIQWMU3GWFW2XLUE6VZXY6PHSXLOTAVH/
streamlining fedora-release (again)
Hi, I'd like to pick up the process of converting fedora-release from a split "upstream"/"downstream" model into a single repo in src.fp.o. For previous discussions see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C/#CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C https://pagure.io/fedora-release/pull-request/119 https://pagure.io/releng/issue/7293 I made the changes requested by Dennis Gilmore (an exploded repo, no tarball) and they are available in https://src.fedoraproject.org/fork/zbyszek/rpms/fedora-release/branch/drop-upstream-split . "Tests" were requested — I tested using rpmdiff and diffoscope that the changes only introduce timestamp differences, and then the subsequent cleanup commits only introduce expected differences (Group tag becomes "Unspecified", the description is updated, whitespace changes in scriptlets). If additional testing is required let me know what. As stated previously, I'm requesting co-maintainership of fedora-release to merge presets requests in reasonable time and to implement the changes described above. Let me know if you need anything else from me now. (I'll revisit the outstanding PRs against fedora-release once the new repo is established, I hope that happens quickly.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6BGQJOK5VV7BNZAUYGH5QZROO7E3N7GI/
Re: streamlining fedora-release
El mar, 05-12-2017 a las 07:31 +, Zbigniew Jędrzejewski-Szmek escribió: > On Mon, Dec 04, 2017 at 12:49:48PM -0600, Dennis Gilmore wrote: > > El vie, 10-11-2017 a las 09:12 -0500, Neal Gompa escribió: > > > On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: > > > > > Zbigniew Jędrzejewski-Szmek wrote: > > > > > > The fedora-release package contains stuff that is tied to > > > > > > each > > > > > > Fedora > > > > > > version and changes slowly, and it also contains the preset > > > > > > files for > > > > > > systemd units, which change fairly often (a few requests > > > > > > per > > > > > > month). > > > > > > > > > > Why not have a separate fedora-presets then? Just like > > > > > fedora- > > > > > repos was > > > > > split out from fedora-release several releases ago. > > > > > > > > Well, pfff, no particular reason, at least from my side. Just > > > > opening > > > > a new package and going through the (trivial) review, etc., is > > > > a > > > > bit > > > > of up-front effort, and then releasing updates for two packages > > > > is > > > > always a bit more effort then for one. So instead, I'd want a > > > > good > > > > reason > > > > to make another package and how that is going to solve > > > > something. > > > > So far I > > > > haven't seen anything except some hypothetical issues. > > > > > > This would allow us to deduplicate the presets shipped in > > > generic-release and fedora-release, wouldn't it? > > > > We do not keep them in sync between fedora-release and generic- > > release > > this is because generic-release is there just to provide an example > > of > > how you would setup a -release package for a custom forked OS. it > > is > > not intended to be a complete drop in for fedora-release. > > It might be still worth doing, just to avoid the duplication. > > Anyway, any thoughts on the major parts of my proposal? I am not opposed to it. I would however like to see a test suite built up. we have had too many changes that are well intentioned that have caused major breakages and bugs. So if it came along with the start of a test suite then sure. The spec itself will need changes to not use a tarball anymore, I would like to just use the exploded tree all managed in dist-git than have an awkward set of steps to upload the tarball that is made from the same location. Dennis > Zbyszek > > > > And as long has it has a "system-presets" Provides, downstream > > > folks > > > can swap them easily enough. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Mon, Dec 04, 2017 at 12:49:48PM -0600, Dennis Gilmore wrote: > El vie, 10-11-2017 a las 09:12 -0500, Neal Gompa escribió: > > On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek > > wrote: > > > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: > > > > Zbigniew Jędrzejewski-Szmek wrote: > > > > > The fedora-release package contains stuff that is tied to each > > > > > Fedora > > > > > version and changes slowly, and it also contains the preset > > > > > files for > > > > > systemd units, which change fairly often (a few requests per > > > > > month). > > > > > > > > Why not have a separate fedora-presets then? Just like fedora- > > > > repos was > > > > split out from fedora-release several releases ago. > > > > > > Well, pfff, no particular reason, at least from my side. Just > > > opening > > > a new package and going through the (trivial) review, etc., is a > > > bit > > > of up-front effort, and then releasing updates for two packages is > > > always a bit more effort then for one. So instead, I'd want a good > > > reason > > > to make another package and how that is going to solve something. > > > So far I > > > haven't seen anything except some hypothetical issues. > > > > This would allow us to deduplicate the presets shipped in > > generic-release and fedora-release, wouldn't it? > > We do not keep them in sync between fedora-release and generic-release > this is because generic-release is there just to provide an example of > how you would setup a -release package for a custom forked OS. it is > not intended to be a complete drop in for fedora-release. It might be still worth doing, just to avoid the duplication. Anyway, any thoughts on the major parts of my proposal? Zbyszek > > And as long has it has a "system-presets" Provides, downstream folks > > can swap them easily enough. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
El vie, 10-11-2017 a las 09:12 -0500, Neal Gompa escribió: > On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: > > > Zbigniew Jędrzejewski-Szmek wrote: > > > > The fedora-release package contains stuff that is tied to each > > > > Fedora > > > > version and changes slowly, and it also contains the preset > > > > files for > > > > systemd units, which change fairly often (a few requests per > > > > month). > > > > > > Why not have a separate fedora-presets then? Just like fedora- > > > repos was > > > split out from fedora-release several releases ago. > > > > Well, pfff, no particular reason, at least from my side. Just > > opening > > a new package and going through the (trivial) review, etc., is a > > bit > > of up-front effort, and then releasing updates for two packages is > > always a bit more effort then for one. So instead, I'd want a good > > reason > > to make another package and how that is going to solve something. > > So far I > > haven't seen anything except some hypothetical issues. > > This would allow us to deduplicate the presets shipped in > generic-release and fedora-release, wouldn't it? We do not keep them in sync between fedora-release and generic-release this is because generic-release is there just to provide an example of how you would setup a -release package for a custom forked OS. it is not intended to be a complete drop in for fedora-release. Dennis > And as long has it has a "system-presets" Provides, downstream folks > can swap them easily enough. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release: decision needed
On Mon, Nov 13, 2017 at 07:32:09AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Nov 09, 2017 at 03:44:49PM +, Zbigniew Jędrzejewski-Szmek wrote: > > OK, it seems that everybody commented. The part about allowing > > proven packagers more freedom with the package was controversial, > > so I'm withdrawing that, but otherwise I didn't see disagreement. > > > > Updated proposal: > > 1. drop "upstream" at https://pagure.io/fedora-release > >(PR to add an obsoletion note is at > > https://pagure.io/fedora-release/pull-request/119) > > 2. Allow pull requests in src.fp.o/fedora-release > >(one of the owners has to do this) > > 2b. Maybe also set "Block Un-Signed commits" while at it > > > > 3. add me to the commiters list (my account is 'zbyszek'). > >(Kevin said he is OK with that, I hope there is no disagreement. > > I don't see a button to requests ACLs anywhere.) > > > > 4. I'll start my pulling in > > https://pagure.io/fedora-release/pull-request/117 ;) > > > > Zbyszek > > Hi, > > fedora-release maintainers, ping. Hi fedora-release maintainers, I'd appreciate some kind of response and decision on the proposed workflow changes, and a reply to my request for write access. I think the package is need of help, I'm willing to help, we had a useful discussion that clarified a number of points, but it's hard to make progress if things just die when we get to actually doing anything. Zbyszek > > On Wed, Nov 08, 2017 at 08:48:05PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Wed, Nov 08, 2017 at 07:51:00PM +, Stephen Gallagher wrote: > > > > On Wed, Nov 8, 2017 at 2:45 PM Kevin Fenzi wrote: > > > > > > > > > On 11/08/2017 07:13 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > On Wed, Nov 08, 2017 at 10:03:30AM -0500, Neal Gompa wrote: > > > > > >> On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek > > > > > >> wrote: > > > > > >>> We have such special protections for the kernel (signing), firefox > > > > > (trademarks), > > > > > >>> and for bootloaders (signing again), and some packages which don't > > > > > consider > > > > > >>> the fedora repo the canonical location for sources. > > > > > >>> > > > > > >> > > > > > >> Hold the phone! When did we allow packages to not consider the > > > > > >> Fedora > > > > > >> Dist-Git the canonical location for sources? > > > > > > > > > > > > For fedora-release the idea is that "upsteam" has a copy of the spec > > > > > > file, and the changes are supposed to be copied both ways. But I > > > > > > think > > > > > > there's no disagreement with retiring "upstream", so this issue > > > > > > should > > > > > > be moot soon (independently of the other stuff being discussed). > > > > > > > > > > Well, this thread has had posts from 1 of the 4 maintainers. > > > > > I don't think it would be appropriate to change the package workflow > > > > > without input from the others. > > > > > > > > > > IMHO, if the problem here is that preset requests aren't being > > > > > processed > > > > > quickly enough, I'd be happy to add at least you (and any others that > > > > > showed over time they understand how presets work and can review PRs) > > > > > to > > > > > review, create and merge PRs and build and push updates. > > > > > > > > > > I don't know that anything else dramatic needs to happen here... > > > > > > > > > > > > > > Well, the merging to the upstream repo is only the start of the process. > > > > There's also a really awkward creation of a new tarball that has to be > > > > imported over in dist-git, then the spec file updated, etc. > > > > > > > > What I think Zbigniew is asking for is the ability to more quickly get > > > > *builds* including preset updates. Right now, even when the merges to > > > > the > > > > upstream repo happen quickly, it's often measured in weeks how long it > > > > takes to actually get a build of the Fedora RPM. > > > > > > Exactly. > > > > > > Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Thu, Nov 09, 2017 at 03:44:49PM +, Zbigniew Jędrzejewski-Szmek wrote: > OK, it seems that everybody commented. The part about allowing > proven packagers more freedom with the package was controversial, > so I'm withdrawing that, but otherwise I didn't see disagreement. > > Updated proposal: > 1. drop "upstream" at https://pagure.io/fedora-release >(PR to add an obsoletion note is at > https://pagure.io/fedora-release/pull-request/119) > 2. Allow pull requests in src.fp.o/fedora-release >(one of the owners has to do this) > 2b. Maybe also set "Block Un-Signed commits" while at it > > 3. add me to the commiters list (my account is 'zbyszek'). >(Kevin said he is OK with that, I hope there is no disagreement. > I don't see a button to requests ACLs anywhere.) > > 4. I'll start my pulling in https://pagure.io/fedora-release/pull-request/117 > ;) > > Zbyszek Hi, fedora-release maintainers, ping. Zbyszek > On Wed, Nov 08, 2017 at 08:48:05PM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Nov 08, 2017 at 07:51:00PM +, Stephen Gallagher wrote: > > > On Wed, Nov 8, 2017 at 2:45 PM Kevin Fenzi wrote: > > > > > > > On 11/08/2017 07:13 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > On Wed, Nov 08, 2017 at 10:03:30AM -0500, Neal Gompa wrote: > > > > >> On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek > > > > >> wrote: > > > > >>> We have such special protections for the kernel (signing), firefox > > > > (trademarks), > > > > >>> and for bootloaders (signing again), and some packages which don't > > > > consider > > > > >>> the fedora repo the canonical location for sources. > > > > >>> > > > > >> > > > > >> Hold the phone! When did we allow packages to not consider the Fedora > > > > >> Dist-Git the canonical location for sources? > > > > > > > > > > For fedora-release the idea is that "upsteam" has a copy of the spec > > > > > file, and the changes are supposed to be copied both ways. But I think > > > > > there's no disagreement with retiring "upstream", so this issue should > > > > > be moot soon (independently of the other stuff being discussed). > > > > > > > > Well, this thread has had posts from 1 of the 4 maintainers. > > > > I don't think it would be appropriate to change the package workflow > > > > without input from the others. > > > > > > > > IMHO, if the problem here is that preset requests aren't being processed > > > > quickly enough, I'd be happy to add at least you (and any others that > > > > showed over time they understand how presets work and can review PRs) to > > > > review, create and merge PRs and build and push updates. > > > > > > > > I don't know that anything else dramatic needs to happen here... > > > > > > > > > > > Well, the merging to the upstream repo is only the start of the process. > > > There's also a really awkward creation of a new tarball that has to be > > > imported over in dist-git, then the spec file updated, etc. > > > > > > What I think Zbigniew is asking for is the ability to more quickly get > > > *builds* including preset updates. Right now, even when the merges to the > > > upstream repo happen quickly, it's often measured in weeks how long it > > > takes to actually get a build of the Fedora RPM. > > > > Exactly. > > > > Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Fri, Nov 10, 2017 at 09:12:33AM -0500, Neal Gompa wrote: > On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: > >> Zbigniew Jędrzejewski-Szmek wrote: > >> > The fedora-release package contains stuff that is tied to each Fedora > >> > version and changes slowly, and it also contains the preset files for > >> > systemd units, which change fairly often (a few requests per month). > >> > >> Why not have a separate fedora-presets then? Just like fedora-repos was > >> split out from fedora-release several releases ago. > > > > Well, pfff, no particular reason, at least from my side. Just opening > > a new package and going through the (trivial) review, etc., is a bit > > of up-front effort, and then releasing updates for two packages is > > always a bit more effort then for one. So instead, I'd want a good reason > > to make another package and how that is going to solve something. So far I > > haven't seen anything except some hypothetical issues. > > This would allow us to deduplicate the presets shipped in > generic-release and fedora-release, wouldn't it? That is a very good point. It would probably make sense to do such deduplication. But I think it should be a separate step after fedora-release is reorganized. Doing everything at once is more likely to lead to a mess. But yeah, it's definitely something I'll want to do later on. Zbyszek > And as long has it has a "system-presets" Provides, downstream folks > can swap them easily enough. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: >> Zbigniew Jędrzejewski-Szmek wrote: >> > The fedora-release package contains stuff that is tied to each Fedora >> > version and changes slowly, and it also contains the preset files for >> > systemd units, which change fairly often (a few requests per month). >> >> Why not have a separate fedora-presets then? Just like fedora-repos was >> split out from fedora-release several releases ago. > > Well, pfff, no particular reason, at least from my side. Just opening > a new package and going through the (trivial) review, etc., is a bit > of up-front effort, and then releasing updates for two packages is > always a bit more effort then for one. So instead, I'd want a good reason > to make another package and how that is going to solve something. So far I > haven't seen anything except some hypothetical issues. This would allow us to deduplicate the presets shipped in generic-release and fedora-release, wouldn't it? And as long has it has a "system-presets" Provides, downstream folks can swap them easily enough. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > The fedora-release package contains stuff that is tied to each Fedora > > version and changes slowly, and it also contains the preset files for > > systemd units, which change fairly often (a few requests per month). > > Why not have a separate fedora-presets then? Just like fedora-repos was > split out from fedora-release several releases ago. Well, pfff, no particular reason, at least from my side. Just opening a new package and going through the (trivial) review, etc., is a bit of up-front effort, and then releasing updates for two packages is always a bit more effort then for one. So instead, I'd want a good reason to make another package and how that is going to solve something. So far I haven't seen anything except some hypothetical issues. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
Zbigniew Jędrzejewski-Szmek wrote: > The fedora-release package contains stuff that is tied to each Fedora > version and changes slowly, and it also contains the preset files for > systemd units, which change fairly often (a few requests per month). Why not have a separate fedora-presets then? Just like fedora-repos was split out from fedora-release several releases ago. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, 2017-11-08 at 15:23 +, Peter Robinson wrote: > > But why? _Any_ package can completely screw up the system with a bad > > scriplet or a dependency. Let's take one step back and consider why a > > package would need special protections: only when there's something > > _tricky_ about the package. We have such special protections for the > > kernel (signing), firefox (trademarks), and for bootloaders (signing again), > > Well the fedora-release package could be arguably open to trademark. There *are* also some non-obvious bits about fedora-release, too. There's the duality with generic-release and the common 'system- release' virtual provide, which people may forget/not know about. And IIRC it contains various files whose existence or text contents are magic in various ways, like the /etc/*release files. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
OK, it seems that everybody commented. The part about allowing proven packagers more freedom with the package was controversial, so I'm withdrawing that, but otherwise I didn't see disagreement. Updated proposal: 1. drop "upstream" at https://pagure.io/fedora-release (PR to add an obsoletion note is at https://pagure.io/fedora-release/pull-request/119) 2. Allow pull requests in src.fp.o/fedora-release (one of the owners has to do this) 2b. Maybe also set "Block Un-Signed commits" while at it 3. add me to the commiters list (my account is 'zbyszek'). (Kevin said he is OK with that, I hope there is no disagreement. I don't see a button to requests ACLs anywhere.) 4. I'll start my pulling in https://pagure.io/fedora-release/pull-request/117 ;) Zbyszek On Wed, Nov 08, 2017 at 08:48:05PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Nov 08, 2017 at 07:51:00PM +, Stephen Gallagher wrote: > > On Wed, Nov 8, 2017 at 2:45 PM Kevin Fenzi wrote: > > > > > On 11/08/2017 07:13 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > On Wed, Nov 08, 2017 at 10:03:30AM -0500, Neal Gompa wrote: > > > >> On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek > > > >> wrote: > > > >>> We have such special protections for the kernel (signing), firefox > > > (trademarks), > > > >>> and for bootloaders (signing again), and some packages which don't > > > consider > > > >>> the fedora repo the canonical location for sources. > > > >>> > > > >> > > > >> Hold the phone! When did we allow packages to not consider the Fedora > > > >> Dist-Git the canonical location for sources? > > > > > > > > For fedora-release the idea is that "upsteam" has a copy of the spec > > > > file, and the changes are supposed to be copied both ways. But I think > > > > there's no disagreement with retiring "upstream", so this issue should > > > > be moot soon (independently of the other stuff being discussed). > > > > > > Well, this thread has had posts from 1 of the 4 maintainers. > > > I don't think it would be appropriate to change the package workflow > > > without input from the others. > > > > > > IMHO, if the problem here is that preset requests aren't being processed > > > quickly enough, I'd be happy to add at least you (and any others that > > > showed over time they understand how presets work and can review PRs) to > > > review, create and merge PRs and build and push updates. > > > > > > I don't know that anything else dramatic needs to happen here... > > > > > > > > Well, the merging to the upstream repo is only the start of the process. > > There's also a really awkward creation of a new tarball that has to be > > imported over in dist-git, then the spec file updated, etc. > > > > What I think Zbigniew is asking for is the ability to more quickly get > > *builds* including preset updates. Right now, even when the merges to the > > upstream repo happen quickly, it's often measured in weeks how long it > > takes to actually get a build of the Fedora RPM. > > Exactly. > > Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 08, 2017 at 07:51:00PM +, Stephen Gallagher wrote: > On Wed, Nov 8, 2017 at 2:45 PM Kevin Fenzi wrote: > > > On 11/08/2017 07:13 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > On Wed, Nov 08, 2017 at 10:03:30AM -0500, Neal Gompa wrote: > > >> On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek > > >> wrote: > > >>> We have such special protections for the kernel (signing), firefox > > (trademarks), > > >>> and for bootloaders (signing again), and some packages which don't > > consider > > >>> the fedora repo the canonical location for sources. > > >>> > > >> > > >> Hold the phone! When did we allow packages to not consider the Fedora > > >> Dist-Git the canonical location for sources? > > > > > > For fedora-release the idea is that "upsteam" has a copy of the spec > > > file, and the changes are supposed to be copied both ways. But I think > > > there's no disagreement with retiring "upstream", so this issue should > > > be moot soon (independently of the other stuff being discussed). > > > > Well, this thread has had posts from 1 of the 4 maintainers. > > I don't think it would be appropriate to change the package workflow > > without input from the others. > > > > IMHO, if the problem here is that preset requests aren't being processed > > quickly enough, I'd be happy to add at least you (and any others that > > showed over time they understand how presets work and can review PRs) to > > review, create and merge PRs and build and push updates. > > > > I don't know that anything else dramatic needs to happen here... > > > > > Well, the merging to the upstream repo is only the start of the process. > There's also a really awkward creation of a new tarball that has to be > imported over in dist-git, then the spec file updated, etc. > > What I think Zbigniew is asking for is the ability to more quickly get > *builds* including preset updates. Right now, even when the merges to the > upstream repo happen quickly, it's often measured in weeks how long it > takes to actually get a build of the Fedora RPM. Exactly. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 2:45 PM Kevin Fenzi wrote: > On 11/08/2017 07:13 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Nov 08, 2017 at 10:03:30AM -0500, Neal Gompa wrote: > >> On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek > >> wrote: > >>> We have such special protections for the kernel (signing), firefox > (trademarks), > >>> and for bootloaders (signing again), and some packages which don't > consider > >>> the fedora repo the canonical location for sources. > >>> > >> > >> Hold the phone! When did we allow packages to not consider the Fedora > >> Dist-Git the canonical location for sources? > > > > For fedora-release the idea is that "upsteam" has a copy of the spec > > file, and the changes are supposed to be copied both ways. But I think > > there's no disagreement with retiring "upstream", so this issue should > > be moot soon (independently of the other stuff being discussed). > > Well, this thread has had posts from 1 of the 4 maintainers. > I don't think it would be appropriate to change the package workflow > without input from the others. > > IMHO, if the problem here is that preset requests aren't being processed > quickly enough, I'd be happy to add at least you (and any others that > showed over time they understand how presets work and can review PRs) to > review, create and merge PRs and build and push updates. > > I don't know that anything else dramatic needs to happen here... > > Well, the merging to the upstream repo is only the start of the process. There's also a really awkward creation of a new tarball that has to be imported over in dist-git, then the spec file updated, etc. What I think Zbigniew is asking for is the ability to more quickly get *builds* including preset updates. Right now, even when the merges to the upstream repo happen quickly, it's often measured in weeks how long it takes to actually get a build of the Fedora RPM. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On 11/08/2017 07:13 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Nov 08, 2017 at 10:03:30AM -0500, Neal Gompa wrote: >> On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek >> wrote: >>> We have such special protections for the kernel (signing), firefox >>> (trademarks), >>> and for bootloaders (signing again), and some packages which don't consider >>> the fedora repo the canonical location for sources. >>> >> >> Hold the phone! When did we allow packages to not consider the Fedora >> Dist-Git the canonical location for sources? > > For fedora-release the idea is that "upsteam" has a copy of the spec > file, and the changes are supposed to be copied both ways. But I think > there's no disagreement with retiring "upstream", so this issue should > be moot soon (independently of the other stuff being discussed). Well, this thread has had posts from 1 of the 4 maintainers. I don't think it would be appropriate to change the package workflow without input from the others. IMHO, if the problem here is that preset requests aren't being processed quickly enough, I'd be happy to add at least you (and any others that showed over time they understand how presets work and can review PRs) to review, create and merge PRs and build and push updates. I don't know that anything else dramatic needs to happen here... kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 7:18 PM, Stephen John Smoogen wrote:
> On 8 November 2017 at 13:50, Peter Robinson wrote:
>> On Wed, Nov 8, 2017 at 6:47 PM, Zbigniew Jędrzejewski-Szmek
>> wrote:
>>> On Wed, Nov 08, 2017 at 05:58:13PM +, Stephen Gallagher wrote:
On Wed, Nov 8, 2017 at 10:53 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Wed, Nov 08, 2017 at 03:23:37PM +, Peter Robinson wrote:
> > On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > But why? _Any_ package can completely screw up the system with a bad
> > > scriplet or a dependency. Let's take one step back and consider why a
> > > package would need special protections: only when there's something
> > > _tricky_ about the package. We have such special protections for the
> > > kernel (signing), firefox (trademarks), and for bootloaders (signing
> again),
> >
> > Well the fedora-release package could be arguably open to trademark.
>
> Hmm, Fedora as such certainly. But fedora-release itself I don't think
> so.
> It has a
> /usr/share/licenses/fedora-release/{Fedora-Legal-README.txt,LICENSE}
> which shouldn't be touched, as in any other package, but apart from
> that it's just a bunch of text files.
>
>
Well, there are a number of places where changing the contents of those
text files can have a significant adverse effect on the distribution. In
particular, many packages rely on the ID=, ID_LIKE=, and VARIANT_ID= fields
in os-release to make decisions. Changing those without an understanding of
what might break would be dangerous. I think that's a good argument for
keeping this package under tighter control.
>>>
>>> That'd have to be a malicious change. So either a maintainer of
>>> fedora-release
>>> or a proven packager would have to try to intentionally break the system.
>>> It's not something I'd worry about.
>>
>> We've had issues with this from experienced people so you might not
>> worry about it but you're also not the one people will scream at.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
> And most of the time it has not been malicious. It was "I need this to
> fix my thing and it can't break anything since I tested it on my box".
> It has happened enough times that it isn't something to be considered
> a "never will happen again" because it is usually someone else needing
> something fixed for a deadline and their brain circuits shortcutting
> because of it.
Correct, sorry if my response wasn't clear, there has never been, as
far as I've been aware, any malicious intention. It's mostly that the
Fedora project is large and people test things in their view of the
Fedora world, and in those contexts it's perfect, but the impact on
other desktops/architectures/virt platforms etc sometimes needs
perspective/history or more importantly knowing who you need to double
check with.
Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On 8 November 2017 at 13:50, Peter Robinson wrote:
> On Wed, Nov 8, 2017 at 6:47 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
>> On Wed, Nov 08, 2017 at 05:58:13PM +, Stephen Gallagher wrote:
>>> On Wed, Nov 8, 2017 at 10:53 AM Zbigniew Jędrzejewski-Szmek <
>>> zbys...@in.waw.pl> wrote:
>>>
>>> > On Wed, Nov 08, 2017 at 03:23:37PM +, Peter Robinson wrote:
>>> > > On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek
>>> > > wrote:
>>> > > > But why? _Any_ package can completely screw up the system with a bad
>>> > > > scriplet or a dependency. Let's take one step back and consider why a
>>> > > > package would need special protections: only when there's something
>>> > > > _tricky_ about the package. We have such special protections for the
>>> > > > kernel (signing), firefox (trademarks), and for bootloaders (signing
>>> > again),
>>> > >
>>> > > Well the fedora-release package could be arguably open to trademark.
>>> >
>>> > Hmm, Fedora as such certainly. But fedora-release itself I don't think so.
>>> > It has a
>>> > /usr/share/licenses/fedora-release/{Fedora-Legal-README.txt,LICENSE}
>>> > which shouldn't be touched, as in any other package, but apart from
>>> > that it's just a bunch of text files.
>>> >
>>> >
>>> Well, there are a number of places where changing the contents of those
>>> text files can have a significant adverse effect on the distribution. In
>>> particular, many packages rely on the ID=, ID_LIKE=, and VARIANT_ID= fields
>>> in os-release to make decisions. Changing those without an understanding of
>>> what might break would be dangerous. I think that's a good argument for
>>> keeping this package under tighter control.
>>
>> That'd have to be a malicious change. So either a maintainer of
>> fedora-release
>> or a proven packager would have to try to intentionally break the system.
>> It's not something I'd worry about.
>
> We've had issues with this from experienced people so you might not
> worry about it but you're also not the one people will scream at.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
And most of the time it has not been malicious. It was "I need this to
fix my thing and it can't break anything since I tested it on my box".
It has happened enough times that it isn't something to be considered
a "never will happen again" because it is usually someone else needing
something fixed for a deadline and their brain circuits shortcutting
because of it.
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 6:47 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Wed, Nov 08, 2017 at 05:58:13PM +, Stephen Gallagher wrote:
>> On Wed, Nov 8, 2017 at 10:53 AM Zbigniew Jędrzejewski-Szmek <
>> zbys...@in.waw.pl> wrote:
>>
>> > On Wed, Nov 08, 2017 at 03:23:37PM +, Peter Robinson wrote:
>> > > On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek
>> > > wrote:
>> > > > But why? _Any_ package can completely screw up the system with a bad
>> > > > scriplet or a dependency. Let's take one step back and consider why a
>> > > > package would need special protections: only when there's something
>> > > > _tricky_ about the package. We have such special protections for the
>> > > > kernel (signing), firefox (trademarks), and for bootloaders (signing
>> > again),
>> > >
>> > > Well the fedora-release package could be arguably open to trademark.
>> >
>> > Hmm, Fedora as such certainly. But fedora-release itself I don't think so.
>> > It has a
>> > /usr/share/licenses/fedora-release/{Fedora-Legal-README.txt,LICENSE}
>> > which shouldn't be touched, as in any other package, but apart from
>> > that it's just a bunch of text files.
>> >
>> >
>> Well, there are a number of places where changing the contents of those
>> text files can have a significant adverse effect on the distribution. In
>> particular, many packages rely on the ID=, ID_LIKE=, and VARIANT_ID= fields
>> in os-release to make decisions. Changing those without an understanding of
>> what might break would be dangerous. I think that's a good argument for
>> keeping this package under tighter control.
>
> That'd have to be a malicious change. So either a maintainer of fedora-release
> or a proven packager would have to try to intentionally break the system.
> It's not something I'd worry about.
We've had issues with this from experienced people so you might not
worry about it but you're also not the one people will scream at.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 08, 2017 at 05:58:13PM +, Stephen Gallagher wrote:
> On Wed, Nov 8, 2017 at 10:53 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
> > On Wed, Nov 08, 2017 at 03:23:37PM +, Peter Robinson wrote:
> > > On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > > > But why? _Any_ package can completely screw up the system with a bad
> > > > scriplet or a dependency. Let's take one step back and consider why a
> > > > package would need special protections: only when there's something
> > > > _tricky_ about the package. We have such special protections for the
> > > > kernel (signing), firefox (trademarks), and for bootloaders (signing
> > again),
> > >
> > > Well the fedora-release package could be arguably open to trademark.
> >
> > Hmm, Fedora as such certainly. But fedora-release itself I don't think so.
> > It has a
> > /usr/share/licenses/fedora-release/{Fedora-Legal-README.txt,LICENSE}
> > which shouldn't be touched, as in any other package, but apart from
> > that it's just a bunch of text files.
> >
> >
> Well, there are a number of places where changing the contents of those
> text files can have a significant adverse effect on the distribution. In
> particular, many packages rely on the ID=, ID_LIKE=, and VARIANT_ID= fields
> in os-release to make decisions. Changing those without an understanding of
> what might break would be dangerous. I think that's a good argument for
> keeping this package under tighter control.
That'd have to be a malicious change. So either a maintainer of fedora-release
or a proven packager would have to try to intentionally break the system.
It's not something I'd worry about.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 10:53 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Wed, Nov 08, 2017 at 03:23:37PM +, Peter Robinson wrote:
> > On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > But why? _Any_ package can completely screw up the system with a bad
> > > scriplet or a dependency. Let's take one step back and consider why a
> > > package would need special protections: only when there's something
> > > _tricky_ about the package. We have such special protections for the
> > > kernel (signing), firefox (trademarks), and for bootloaders (signing
> again),
> >
> > Well the fedora-release package could be arguably open to trademark.
>
> Hmm, Fedora as such certainly. But fedora-release itself I don't think so.
> It has a
> /usr/share/licenses/fedora-release/{Fedora-Legal-README.txt,LICENSE}
> which shouldn't be touched, as in any other package, but apart from
> that it's just a bunch of text files.
>
>
Well, there are a number of places where changing the contents of those
text files can have a significant adverse effect on the distribution. In
particular, many packages rely on the ID=, ID_LIKE=, and VARIANT_ID= fields
in os-release to make decisions. Changing those without an understanding of
what might break would be dangerous. I think that's a good argument for
keeping this package under tighter control.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 08, 2017 at 03:23:37PM +, Peter Robinson wrote:
> On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Wed, Nov 08, 2017 at 02:05:12PM +, Stephen Gallagher wrote:
> >> On Wed, Nov 8, 2017 at 8:43 AM Peter Robinson wrote:
> >>
> >> > On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek
> >> > wrote:
> >> > > I propose simplifying this and opening fedora-release releases to more
> >> > > contributors:
> >> > >
> >> > > 1. Let's drop "upstream" at https://pagure.io/fedora-release and
> >> > >make the "downstream" the canonical source of the package,
> >> > >
> >> > > 2. Allow pull requests in src.fp.o/fedora-release,
> >> >
> >> > I agree with both of these
> >
> > Cool!
> >
> > → https://pagure.io/fedora-release/pull-request/119
> >
> >> > > 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer
> >> > >to suggest improvements to the package (through PRs) and it'll also
> >> > >be possible for proven packagers to do changes without stepping on
> >> > >the toes of the maintainers and interfering with the separate
> >> > "upstream"
> >> > >repo. Let's agree to allow pps to update fedora-release as necessary
> >> > >when the main maintainers are busy.
> >> >
> >> > I don't agree with this, there's often reasons for things and we often
> >> > get pull requests that are incorrect and need a couple of revisions.
> >> >
> >> >
> >> I think I agree with Peter here. fedora-release is a package that probably
> >> *shouldn't* be granted access to provenpackagers.
> >
> > But why? _Any_ package can completely screw up the system with a bad
> > scriplet or a dependency. Let's take one step back and consider why a
> > package would need special protections: only when there's something
> > _tricky_ about the package. We have such special protections for the
> > kernel (signing), firefox (trademarks), and for bootloaders (signing again),
>
> Well the fedora-release package could be arguably open to trademark.
Hmm, Fedora as such certainly. But fedora-release itself I don't think so.
It has a /usr/share/licenses/fedora-release/{Fedora-Legal-README.txt,LICENSE}
which shouldn't be touched, as in any other package, but apart from
that it's just a bunch of text files.
> > and some packages which don't consider the fedora repo the canonical
> > location
> > for sources. Doing those kinds of protections for a package like
> > fedora-release which is _simple_ would be just adding red tape. There's
> > nothing rel-eng-y about fedora-release.
> >
> > There's a general policy for what proven packagers can do (widely
> > agreed-upon changes, cleanups, trivial fixups, etc), and I don't see any
> > reason to exclude fedora-release from this.
> >
> >> That said, I think we should probably set a policy in place that releng
> >> will quickly merge any changes limited to presets that are acked by a
> >> trusted individual such as Zbigniew. We can write up some simple rules for
> >> this which would probably boil down to "Must have followed the preset
> >> request policy and include a comment pointing to the relevant BZ".
> >
> > Well, if we trust somebody to do the review, they should be trusted to
> > do the merge.
>
> I didn't say that we shouldn't open it up to a wider set of
> maintainers, but I don't think it should be wide open for all proven
> packagers to commit, to submit PRs sure, but not just to push. There's
> a few people that consistently push bad bits and have to be requested
> to resubmit.
OK. The whole thing about proven packagers is much more contentious then
I expected. Let's leave it be ;)
As long as there's a general agreement that additional maintainers can
be added (following normal procedure), that's the important part.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Nov 08, 2017 at 02:05:12PM +, Stephen Gallagher wrote: >> On Wed, Nov 8, 2017 at 8:43 AM Peter Robinson wrote: >> >> > On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek >> > wrote: >> > > I propose simplifying this and opening fedora-release releases to more >> > > contributors: >> > > >> > > 1. Let's drop "upstream" at https://pagure.io/fedora-release and >> > >make the "downstream" the canonical source of the package, >> > > >> > > 2. Allow pull requests in src.fp.o/fedora-release, >> > >> > I agree with both of these > > Cool! > > → https://pagure.io/fedora-release/pull-request/119 > >> > > 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer >> > >to suggest improvements to the package (through PRs) and it'll also >> > >be possible for proven packagers to do changes without stepping on >> > >the toes of the maintainers and interfering with the separate >> > "upstream" >> > >repo. Let's agree to allow pps to update fedora-release as necessary >> > >when the main maintainers are busy. >> > >> > I don't agree with this, there's often reasons for things and we often >> > get pull requests that are incorrect and need a couple of revisions. >> > >> > >> I think I agree with Peter here. fedora-release is a package that probably >> *shouldn't* be granted access to provenpackagers. > > But why? _Any_ package can completely screw up the system with a bad > scriplet or a dependency. Let's take one step back and consider why a > package would need special protections: only when there's something > _tricky_ about the package. We have such special protections for the > kernel (signing), firefox (trademarks), and for bootloaders (signing again), Well the fedora-release package could be arguably open to trademark. > and some packages which don't consider the fedora repo the canonical location > for sources. Doing those kinds of protections for a package like > fedora-release which is _simple_ would be just adding red tape. There's > nothing rel-eng-y about fedora-release. > > There's a general policy for what proven packagers can do (widely > agreed-upon changes, cleanups, trivial fixups, etc), and I don't see any > reason to exclude fedora-release from this. > >> That said, I think we should probably set a policy in place that releng >> will quickly merge any changes limited to presets that are acked by a >> trusted individual such as Zbigniew. We can write up some simple rules for >> this which would probably boil down to "Must have followed the preset >> request policy and include a comment pointing to the relevant BZ". > > Well, if we trust somebody to do the review, they should be trusted to > do the merge. I didn't say that we shouldn't open it up to a wider set of maintainers, but I don't think it should be wide open for all proven packagers to commit, to submit PRs sure, but not just to push. There's a few people that consistently push bad bits and have to be requested to resubmit. >> > > 4. Release fedora-release quickly, so that when a preset change request >> > >comes in [1], it can be handled in a few days or a week. (Having such >> > >requests hanging usually blocks changes to the package in question, >> > >so it's important to have the resolution of the preset status without >> > >undue delay.) >> > >> > There's no reason for that not to happen, and generally most of the >> > holdups that people perceive here are not actually the maintainers but >> > issues with the PR or the review of the actual changes being made. >> > >> > I believe for such a critical package that has the ability to break >> > the distribution there should be review of the proposed changes. > I'm all for review. In fact I reviewed many of the PRs that have been > submitted recently. > >> I suppose the other thing we could try to do would be to separate the >> presets into its own package, but that seems like unnecessary overhead >> compared to coming up with a decent review-and-merge policy. > Yeah, that seems like a worse option. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 08, 2017 at 10:03:30AM -0500, Neal Gompa wrote: > On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > We have such special protections for the kernel (signing), firefox > > (trademarks), > > and for bootloaders (signing again), and some packages which don't consider > > the fedora repo the canonical location for sources. > > > > Hold the phone! When did we allow packages to not consider the Fedora > Dist-Git the canonical location for sources? For fedora-release the idea is that "upsteam" has a copy of the spec file, and the changes are supposed to be copied both ways. But I think there's no disagreement with retiring "upstream", so this issue should be moot soon (independently of the other stuff being discussed). > As far as I know, this is > explicitly forbidden[1]. If there are any packages protected for that > reason, their protections should be absolutely stripped. > > [1]: > https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity Yeah, but that's a longer conversation for another thread. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 9:56 AM, Zbigniew Jędrzejewski-Szmek wrote: > We have such special protections for the kernel (signing), firefox > (trademarks), > and for bootloaders (signing again), and some packages which don't consider > the fedora repo the canonical location for sources. > Hold the phone! When did we allow packages to not consider the Fedora Dist-Git the canonical location for sources? As far as I know, this is explicitly forbidden[1]. If there are any packages protected for that reason, their protections should be absolutely stripped. [1]: https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 08, 2017 at 02:05:12PM +, Stephen Gallagher wrote: > On Wed, Nov 8, 2017 at 8:43 AM Peter Robinson wrote: > > > On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek > > wrote: > > > I propose simplifying this and opening fedora-release releases to more > > > contributors: > > > > > > 1. Let's drop "upstream" at https://pagure.io/fedora-release and > > >make the "downstream" the canonical source of the package, > > > > > > 2. Allow pull requests in src.fp.o/fedora-release, > > > > I agree with both of these Cool! → https://pagure.io/fedora-release/pull-request/119 > > > 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer > > >to suggest improvements to the package (through PRs) and it'll also > > >be possible for proven packagers to do changes without stepping on > > >the toes of the maintainers and interfering with the separate > > "upstream" > > >repo. Let's agree to allow pps to update fedora-release as necessary > > >when the main maintainers are busy. > > > > I don't agree with this, there's often reasons for things and we often > > get pull requests that are incorrect and need a couple of revisions. > > > > > I think I agree with Peter here. fedora-release is a package that probably > *shouldn't* be granted access to provenpackagers. But why? _Any_ package can completely screw up the system with a bad scriplet or a dependency. Let's take one step back and consider why a package would need special protections: only when there's something _tricky_ about the package. We have such special protections for the kernel (signing), firefox (trademarks), and for bootloaders (signing again), and some packages which don't consider the fedora repo the canonical location for sources. Doing those kinds of protections for a package like fedora-release which is _simple_ would be just adding red tape. There's nothing rel-eng-y about fedora-release. There's a general policy for what proven packagers can do (widely agreed-upon changes, cleanups, trivial fixups, etc), and I don't see any reason to exclude fedora-release from this. > That said, I think we should probably set a policy in place that releng > will quickly merge any changes limited to presets that are acked by a > trusted individual such as Zbigniew. We can write up some simple rules for > this which would probably boil down to "Must have followed the preset > request policy and include a comment pointing to the relevant BZ". Well, if we trust somebody to do the review, they should be trusted to do the merge. > > > 4. Release fedora-release quickly, so that when a preset change request > > >comes in [1], it can be handled in a few days or a week. (Having such > > >requests hanging usually blocks changes to the package in question, > > >so it's important to have the resolution of the preset status without > > >undue delay.) > > > > There's no reason for that not to happen, and generally most of the > > holdups that people perceive here are not actually the maintainers but > > issues with the PR or the review of the actual changes being made. > > > > I believe for such a critical package that has the ability to break > > the distribution there should be review of the proposed changes. I'm all for review. In fact I reviewed many of the PRs that have been submitted recently. > I suppose the other thing we could try to do would be to separate the > presets into its own package, but that seems like unnecessary overhead > compared to coming up with a decent review-and-merge policy. Yeah, that seems like a worse option. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 9:05 AM, Stephen Gallagher wrote: > > > On Wed, Nov 8, 2017 at 8:43 AM Peter Robinson wrote: >> >> On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek >> wrote: >> > I propose simplifying this and opening fedora-release releases to more >> > contributors: >> > >> > 1. Let's drop "upstream" at https://pagure.io/fedora-release and >> >make the "downstream" the canonical source of the package, >> > >> > 2. Allow pull requests in src.fp.o/fedora-release, >> >> I agree with both of these >> >> > 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer >> >to suggest improvements to the package (through PRs) and it'll also >> >be possible for proven packagers to do changes without stepping on >> >the toes of the maintainers and interfering with the separate >> > "upstream" >> >repo. Let's agree to allow pps to update fedora-release as necessary >> >when the main maintainers are busy. >> >> I don't agree with this, there's often reasons for things and we often >> get pull requests that are incorrect and need a couple of revisions. >> > > I think I agree with Peter here. fedora-release is a package that probably > *shouldn't* be granted access to provenpackagers. > > That said, I think we should probably set a policy in place that releng will > quickly merge any changes limited to presets that are acked by a trusted > individual such as Zbigniew. We can write up some simple rules for this > which would probably boil down to "Must have followed the preset request > policy and include a comment pointing to the relevant BZ". That makes sense. >> > 4. Release fedora-release quickly, so that when a preset change request >> >comes in [1], it can be handled in a few days or a week. (Having such >> >requests hanging usually blocks changes to the package in question, >> >so it's important to have the resolution of the preset status without >> >undue delay.) >> >> There's no reason for that not to happen, and generally most of the >> holdups that people perceive here are not actually the maintainers but >> issues with the PR or the review of the actual changes being made. >> >> I believe for such a critical package that has the ability to break >> the distribution there should be review of the proposed changes. >> > > I suppose the other thing we could try to do would be to separate the > presets into its own package, but that seems like unnecessary overhead > compared to coming up with a decent review-and-merge policy. Agreed. The only thing I would add is that if we have to opportunity to increase the number of people that understand and can do the reviews, we should take advantage of it. We need to spread knowledge where we can and increase participation responsibly. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 8:43 AM Peter Robinson wrote: > On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > I propose simplifying this and opening fedora-release releases to more > > contributors: > > > > 1. Let's drop "upstream" at https://pagure.io/fedora-release and > >make the "downstream" the canonical source of the package, > > > > 2. Allow pull requests in src.fp.o/fedora-release, > > I agree with both of these > > > 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer > >to suggest improvements to the package (through PRs) and it'll also > >be possible for proven packagers to do changes without stepping on > >the toes of the maintainers and interfering with the separate > "upstream" > >repo. Let's agree to allow pps to update fedora-release as necessary > >when the main maintainers are busy. > > I don't agree with this, there's often reasons for things and we often > get pull requests that are incorrect and need a couple of revisions. > > I think I agree with Peter here. fedora-release is a package that probably *shouldn't* be granted access to provenpackagers. That said, I think we should probably set a policy in place that releng will quickly merge any changes limited to presets that are acked by a trusted individual such as Zbigniew. We can write up some simple rules for this which would probably boil down to "Must have followed the preset request policy and include a comment pointing to the relevant BZ". > > 4. Release fedora-release quickly, so that when a preset change request > >comes in [1], it can be handled in a few days or a week. (Having such > >requests hanging usually blocks changes to the package in question, > >so it's important to have the resolution of the preset status without > >undue delay.) > > There's no reason for that not to happen, and generally most of the > holdups that people perceive here are not actually the maintainers but > issues with the PR or the review of the actual changes being made. > > I believe for such a critical package that has the ability to break > the distribution there should be review of the proposed changes. > > I suppose the other thing we could try to do would be to separate the presets into its own package, but that seems like unnecessary overhead compared to coming up with a decent review-and-merge policy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek wrote: > Hi fedora-release maintainers and fellow developers, > > The fedora-release package contains stuff that is tied to each Fedora > version and changes slowly, and it also contains the preset files for > systemd units, which change fairly often (a few requests per month). > > Currently fedora-release has a fairly complicated maintenance > structure, with an "upstream" project at https://pagure.io/fedora-release > and "downstream" at https://src.fedoraproject.org/rpms/fedora-release. > "upstream" is only used for this single "downstream", and in fact changes > made in packaging "downstream" are sometimes lost when the next version > of "upstream" is imported. > > I propose simplifying this and opening fedora-release releases to more > contributors: > > 1. Let's drop "upstream" at https://pagure.io/fedora-release and >make the "downstream" the canonical source of the package, > > 2. Allow pull requests in src.fp.o/fedora-release, I agree with both of these > 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer >to suggest improvements to the package (through PRs) and it'll also >be possible for proven packagers to do changes without stepping on >the toes of the maintainers and interfering with the separate "upstream" >repo. Let's agree to allow pps to update fedora-release as necessary >when the main maintainers are busy. I don't agree with this, there's often reasons for things and we often get pull requests that are incorrect and need a couple of revisions. > 4. Release fedora-release quickly, so that when a preset change request >comes in [1], it can be handled in a few days or a week. (Having such >requests hanging usually blocks changes to the package in question, >so it's important to have the resolution of the preset status without >undue delay.) There's no reason for that not to happen, and generally most of the holdups that people perceive here are not actually the maintainers but issues with the PR or the review of the actual changes being made. I believe for such a critical package that has the ability to break the distribution there should be review of the proposed changes. > To implement this, not much action is required, mostly acceptance of the > maintainers to amend and open up the process. Concrete steps that do need > to be taken: > > 1. tweak https://src.fedoraproject.org/rpms/fedora-release/settings >to allow PRs > 2. push a commit to "upstream" that that repo is dead > 3. make a README for "downstream" that PRs can be submitted and outline >the requirements. > > I'll be happy to submit the PRs for 2 and 3. I'll also be applying for > co-maintainership in the fedora-release package, because I want to push > those changes forward. > > What do you think? > > Zbyszek > > [1] > https://fedoraproject.org/wiki/Packaging:DefaultServices#How_to_enable_a_service_by_default ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
streamlining fedora-release
Hi fedora-release maintainers and fellow developers, The fedora-release package contains stuff that is tied to each Fedora version and changes slowly, and it also contains the preset files for systemd units, which change fairly often (a few requests per month). Currently fedora-release has a fairly complicated maintenance structure, with an "upstream" project at https://pagure.io/fedora-release and "downstream" at https://src.fedoraproject.org/rpms/fedora-release. "upstream" is only used for this single "downstream", and in fact changes made in packaging "downstream" are sometimes lost when the next version of "upstream" is imported. I propose simplifying this and opening fedora-release releases to more contributors: 1. Let's drop "upstream" at https://pagure.io/fedora-release and make the "downstream" the canonical source of the package, 2. Allow pull requests in src.fp.o/fedora-release, 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer to suggest improvements to the package (through PRs) and it'll also be possible for proven packagers to do changes without stepping on the toes of the maintainers and interfering with the separate "upstream" repo. Let's agree to allow pps to update fedora-release as necessary when the main maintainers are busy. 4. Release fedora-release quickly, so that when a preset change request comes in [1], it can be handled in a few days or a week. (Having such requests hanging usually blocks changes to the package in question, so it's important to have the resolution of the preset status without undue delay.) To implement this, not much action is required, mostly acceptance of the maintainers to amend and open up the process. Concrete steps that do need to be taken: 1. tweak https://src.fedoraproject.org/rpms/fedora-release/settings to allow PRs 2. push a commit to "upstream" that that repo is dead 3. make a README for "downstream" that PRs can be submitted and outline the requirements. I'll be happy to submit the PRs for 2 and 3. I'll also be applying for co-maintainership in the fedora-release package, because I want to push those changes forward. What do you think? Zbyszek [1] https://fedoraproject.org/wiki/Packaging:DefaultServices#How_to_enable_a_service_by_default ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
