On Fri, 2019-08-09 at 15:14 +0100, Daniel P. Berrangé wrote: > On Fri, Aug 09, 2019 at 03:13:07PM +0200, Martin Kolman wrote: > > On Fri, 2019-08-09 at 14:00 +0100, Daniel P. Berrangé wrote: > > > On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote: > > > > On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko < > > > > ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > Well, it was retired because it did not built since F30 mass rebuild… > > > > > > > > > > > > > I went ahead and built it with the testsuite disabled for now: I suppose > > > > any Proven Packager could also have done, but yeah normally it should be > > > > done by the maintainers. > > > > I admit the ball was dropped on this by various people (myself included), > > > > and sorry about that. [1] > > > > The new major upstream release was also a long time coming... > > > > > > > > But to me the deeper question is still "why are we proactively breaking the > > > > distro" in this way with package retirements by non-maintainers? > > > > > > > > Sure FTBFS is bad but there is no need to proactively remove core packages > > > > which are still working okay. > > > > I really really wish could stop this... causing more busy work and stress. > > > > > > When a FTBFS hits, we don't know whether the package is still working > > > ok or not as there are many possible reasons for the failure. > > Maybe this is something gating tests could help with ? If a package is FTBFS > > and has reasonable gating test coverage, you will know it is working. > > The gating CI is a pretty low bar right now. As CI is made stronger, > it could well actually make FTBFS *more* common, as CI is introducing > more scope for things to be classed as a failure. So be careful what > you wish for :-) > > > > Filing > > > the FTBFS BZs informs the maintainer(s) & allows them to investigate, > > > figure what has gone wrong & decide what changes are needed. Missing > > > on 2 mass rebuilds means the package is still build with F29 toolchain, > > > and thus lacking desired improvements Fedora is introducing, so this > > > has a cost for the rest of the distro. Somewhere there's a balance > > > between cost for the maintainer in work & cost for the distro in the > > > package being outdated. > > > > > > There was no acknowlegement on the BZ that anyone was actively working > > > on fixing it in 6 months. This is true for so many of the FTBFS BZs that > > > get filed. If the packages don't get orphaned after 6+ months of being > > > ignored, when would they ever be fixed ? > > > > > > Having said that, I think in the case of packages which are deps of > > > so much of the distro, it could have been useful to have a warning of > > > imminent orphaning on fedora-devel. There was a warning that orphaning > > > was starting, but no list of affected packages included. > > Maybe another job for automated tests/CI ? > > > > Before dropping a batch of packages, do a test compose without them and postpone > > the drop if the compose run crashes and burns. > > > > Sounds really like something doable which could save a lot of everyones time once in place. > > We can't carry on postponing things indefinitely though - at some point we > have to say enough, and expect a maintainer to actually do some maintaining. Sure & I totally agree with that. I'm just trying to find ways that can sound the alarm bells & prevent everyone impacting Rawhide breakage before it's too late and things need to be fixed post-mortem. An this case really looks like something that an automated check should be able to catch soon enough. :) > > Regards, > Daniel _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
