On 09. 08. 19 16:22, Martin Kolman wrote:
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. :)
Tough question: Would the package get any attention if it was not retired?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
