On Thu, Jun 28, 2018 at 06:28:53AM -0400, Stephen Gallagher wrote: > On Wed, Jun 27, 2018 at 9:19 PM Dennis Gilmore <den...@ausil.us> wrote: > > > El mié, 27-06-2018 a las 11:58 +0000, 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/
