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.