DevHeads.net

Package removal for FTBFS: Add automatic orphaning?

The current policy says:

<a href="https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/" title="https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/">https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fa...</a>

7. A week before the mass branching, any packages which still have open FTBFS
bugs from the previous release will be retired.

I propose we add a point just before that that says:

7. 7 weeks before the mass branching, any packages which still have open FTBFS
bugs from the previous release will be orphaned.
8. A week before the mass branching, any packages which still have open FTBFS
bugs from the previous release will be retired.

In theory, the 8. doesn't need to be there, but in practice, it prevents
packagers from claiming the package but not fixing it.

This should raise awareness and prevent surprises.

But, there is one communication failure:

Imagine a maintainer says: "Yes, I'm working on this, fix will be ready next
week." And the response is "Your package has been orphaned."

Obviously, we can prevent this by only orphaning packages with NEW bugz, but
that doesn't really solve anything, because lot of the retired packages were
actually ASSIGNED/POST/MODIFIED (for months).

Comments

Re: Package removal for FTBFS: Add automatic orphaning?

By Kevin Kofler at 08/10/2019 - 17:34

Miro Hrončok wrote:
Of course they were, to prevent you from retiring them even sooner.

Kevin Kofler

Re: Package removal for FTBFS: Add automatic orphaning?

By =?UTF-8?B?TWlyb... at 08/10/2019 - 18:32

On 11. 08. 19 0:34, Kevin Kofler wrote:
If the only reason to set the status to ASSIGNED/POST/MODIFIED is to prevent
**me** from retiring the package, something is fundamentally broken.

If somebody has a legitimate reason to have a FTBFS package not retired, they
can ask for some kind of exception from Releng, not provide inaccurate information.

Re: Package removal for FTBFS: Add automatic orphaning?

By Christopher at 08/10/2019 - 19:31

On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok < ... at redhat dot com> wrote:
I was actually trying to work on some of mine... one of the FTBFS
(thrift) I had was actually because of an optional python2-only
component from upstream I was intending to disable once F31 was
released, if I couldn't recruit a python person to help me fix it
(because I don't know python). But, the entire package was retired
anyway.... it was *very* much unexpected for me, because I thought I'd
have some more time to patch it once F31 came out (the package in F30
is fine... and I don't care about rawhide... I care about the latest
version of Fedora that people are actually using).

Several other packages I had were Java packages that I was still
trying to figure out the state of their BuildRequires which were in
modules. The last I read on this list was "there may be some news
about that"... and then *bam* RETIRED... at least one I know for sure
was marked ASSIGNED. At least one of these I had fixed the FTBFS once,
but then it broke again, so I left the same issue open until I could
fix that one also... but it also was retired.

This FTBFS policy is *TOO* aggressive, and very unfriendly to casual
packagers, and at a time of significant disruption in Fedora due to
modularity. There should be some extra leniency for a few versions
while the dust from modularity settles, and it *definitely* should be
orphaned first if the maintainer isn't responding to FTBFS bugs.

There's so much disruption going on in Fedora right now... things are
moving too quickly for casual packagers, and it seems like a lot of it
is behind the scenes, motivated by internal interests of RedHat, and
*not* what is in the best interests of the community. It was *not* the
right time to forcibly retire hundreds of packages while these changes
are occurring. Many of these broken packages are probably because
casual maintainers like me are struggling to keep up with the changes.
Instead, now is the time to apply more mentoring, and leadership to
assist those packagers get things in order, to figure out how to get
those packages into appropriate modules, as needed, to assist in
patching for python3, to help them take orphaned BRs, etc.

This sends a very bad message, something along the lines of "only
hard-core, full-time, dedicated packagers allowed; you're on your own
and if you can't get things working in Fedora, you're out".

Also, I have a question about retirement as it pertains to modularity:
let's say a package was retired because its BRs moved into modules....
but now the only way to get the BRs (short of packaging all the java
stuff myself) is to put it in a module. Can I do this for a retired
package? Does ursine packages have to be un-retired in order to create
a module?

Re: Package removal for FTBFS: Add automatic orphaning?

By =?UTF-8?B?TWlyb... at 08/11/2019 - 03:05

On 11. 08. 19 2:31, Christopher wrote:
I hear that this was not properly communicated. I am already trying to figure
out how to make that better -see my e-mail that started this thread or
<a href="https://pagure.io/releng/issue/8599" title="https://pagure.io/releng/issue/8599">https://pagure.io/releng/issue/8599</a>

(Note that other people care about rawhide.)

Also: You can unretire the package if this was not expected by you, it's not
like the retirement is endgame.

If that package was actually buil after the F30 mass rebuild, it should ahve not
been retired. Do you have the package name?

Any idea how to:

- prevent arguably broken packages to stay in the distro forever
- stop being too aggressive to casual contributors?

We can change the policy and I am listening to ideas and arguments.

OTOH I think that we should stop breaking the distro (via modularity and other
means) and not invent workarounds for the situation.

(Arguably, we should deal with every FTBFS bug individually, but we lack the
resources for that. A policy is needed.)

That is indeed a bad message. The message intended here was:

"FTBFS packages are not allowed, fix them or remove them"

Obviously, if you cannot fix it, that's not an actionable message.
Packagers should be able to reach for help in that case. Ask on devel: My
package doesn't help, I have no idea what to do now.

This again comes to the main issue: The procedure didn't happen since Fedora
~25. People were surprised this time (as it was not properly communicated).

If people are actually used to this process they now that FTBFS needs to be
fixed and if they don't know how, the proper thing to do is to ask for help,
possibly for exception, rather than doing nothing.

Package is retired on a specific branch and they were retired on master. I
believe this doesn't stop anybody from creating a modular build of such package,
but I'm not sure how does the modular branch get created.

Re: Package removal for FTBFS: Add automatic orphaning?

By Kevin Kofler at 08/11/2019 - 05:51

Miro Hrončok wrote:
IMHO, proper communication would have been to at least add another reminder
comment with a final warning to each still open FTBFS bug 1 or 2 weeks
before actually retiring the package.

The surprise came because months-old bugs that maintainers had long
forgotten of suddenly got acted upon with no further warning.

Luckily, in my case, the FTBFS for my KDE 3 packages actually resolved
itself (the output of the "file" tool on aarch64 was somehow changed back to
something the old libtool understands, so the workaround that I had already
applied to a handful packages and was intending to apply to the rest (had I
actually been warned before the mass retirement started) was no longer
needed) and so the bugs were closed as WORKSFORME and the packages not
retired. But I could easily had been hit too.

The 4 F31 FTBFS bugs that I'm CCed on are all already fixed now, by the way.
(Though qtwebkit will be screwed again when your draconian python2 removal
hits, but that is for another thread.)

Kevin Kofler

Re: Package removal for FTBFS: Add automatic orphaning?

By =?UTF-8?B?TWlyb... at 08/11/2019 - 03:12

On 11. 08. 19 10:05, Miro Hrončok wrote:
My package doesn't build I have no idea what to do now.

(I'll try to read my next e-mail before posting it.)

Re: Package removal for FTBFS: Add automatic orphaning?

By Kevin Kofler at 08/10/2019 - 18:56

Miro Hrončok wrote:
This is not about you personally, but about the FTBFS process. :-)

Packagers' time is limited, and there are usually much more important issues
to solve than an FTBFS in Rawhide. (In fact, anything in Rawhide is lowest-
priority for me. If it is an FTBFS without an associated broken dependency,
even more so.) So if setting the bug from NEW to ASSIGNED buys the
maintainer a few months extra time to fix the low-priority issue (which is
the case in the current bizarre rules), why would they NOT do this?

The best way to prevent bugs being falsely set to ASSIGNED is to just drop
the perverse incentive to do so by dropping point 5 from the FTBFS policy.

Kevin Kofler