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(a)fedoraproject.org> 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