On Wed, 2019-08-14 at 13:22 -0400, Ben Cotton wrote: > I want to publicly express my appreciation for Miro's efforts to > enforce our policy and his willingness to take the hits from people > being rightly upset at its flaws. I also appreciate that the community > has done a good job of understanding that the policy is the problem > and not making it a personal attack on Miro. > > On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote: > > > > > > > "MH" == Miro Hrončok <mhroncok@xxxxxxxxxx> writes: > > > > MH> If we stop here, the current "setting to ASSIGNED to stop this" > > MH> remains a problem. > > > > Let's think about why this is perceived as a problem. The maintainer > > has performed an affirmative act that shows they noticed. Can't we just > > accept that as some statement of intent and stop bugging them at that > > point? > > This is a reasonable compromise to make, IMO. In a perfect world, we'd > have enough active packagers to handle things in a timely manner. But > in this world, people have a lot going on and there's only so much we > can do. People setting a bug to ASSIGNED is a problem I'm willing to > accept. If there's an exceptional case, we can say FESCo has the > ability to step in and remove it. We should assume positive intent > with maintainers and trust that they're doing the right thing. Alternate perspective, entirely a personal one: I think the process is actually great. I kinda prefer the direction of travel where we expect that packages are actively maintained and quite aggressively throw them out if they aren't, to the direction where we accumulate cruft and only throw it out after extremely longwinded and easily-subverted processes. If a package hasn't built for months that's a *problem*. I don't think a packager should be allowed to get away with just setting a bug to ASSIGNED to have the package duck auto-orphaning and eventual removal, possibly forever. That shouldn't be a thing. Packages need to be taken care of. Exceptions should be for things that really ought to be removed but which we need to keep around. Removing unmaintained things shouldn't be the exception. I actually think the consequences of the revival of the old policy have been fine. We are throwing out tons of cruft. Occasionally we find something very crufty yet important: this is a *good* outcome of the process. It alerts us to the fact that important stuff depends on something which is not being properly maintained and allows us to address that. No actions here are reversible, retired packages can be and have been unretired. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
