On 11. 08. 19 2:31, Christopher wrote:
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).
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
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
