The current policy says:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_...
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).
Miro Hrončok wrote:
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).
Of course they were, to prevent you from retiring them even sooner.
Kevin Kofler
On 11. 08. 19 0:34, Kevin Kofler wrote:
Miro Hrončok wrote:
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).
Of course they were, to prevent you from retiring them even sooner.
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.
Miro Hrončok 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.
This is not about you personally, but about the FTBFS process. :-)
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.
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
On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok mhroncok@redhat.com wrote:
On 11. 08. 19 0:34, Kevin Kofler wrote:
Miro Hrončok wrote:
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).
Of course they were, to prevent you from retiring them even sooner.
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.
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?
On 11. 08. 19 2:31, Christopher wrote:
On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok mhroncok@redhat.com wrote:
On 11. 08. 19 0:34, Kevin Kofler wrote:
Miro Hrončok wrote:
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).
Of course they were, to prevent you from retiring them even sooner.
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.
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).
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 https://pagure.io/releng/issue/8599
(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.
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.
If that package was actually buil after the F30 mass rebuild, it should ahve not been retired. Do you have the package name?
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.
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.)
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".
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.
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?
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.
Miro Hrončok 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 https://pagure.io/releng/issue/8599
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
-
Christopher -
Kevin Kofler -
Miro Hrončok