On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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? _______________________________________________ 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
