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 <ti...@math.uh.edu> 
> wrote:
> > > > > > > "MH" == Miro Hrončok <mhron...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to