[Pulp-dev] Dealing with our redmine backlog

David Davis daviddavis at redhat.com
Fri Aug 7 15:32:59 UTC 2020

After open floor, the consensus was to give all users the ability to reopen
issues aside from dupes or completed/released. I've done that.

I think we want to go through open issues and close them out or groom them
regardless of what we decide about doing a mass close so I went ahead and
added an agenda item to our pulpcore meeting.


On Fri, Aug 7, 2020 at 10:49 AM Tatiana Tereshchenko <ttereshc at redhat.com>

> +1 to allow all users to re-open issues.
> If ^, then +1 to closing as many backlog issues as seems needed.
> We can close based on the date and then review manually items with redmine
> issue number less than N - old ones, to see if they have recent comments or
> just spam.
> On Thu, Aug 6, 2020 at 6:08 PM Ina Panova <ipanova at redhat.com> wrote:
>> --------
>> Regards,
>> Ina Panova
>> Senior Software Engineer| Pulp| Red Hat Inc.
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>> On Wed, Aug 5, 2020 at 8:54 PM David Davis <daviddavis at redhat.com> wrote:
>>> We've been discussing the possibility of closing issues in redmine due
>>> to the overwhelming number of issues at NEW. Currently, we have 930 issues
>>> at NEW and I think that exceeds our capacity to address each issue
>>> individually.
>>> The first item I want to bring up for discussion is expanding the
>>> ability for users to reopen closed issues. Currently only authors can
>>> reopen issues at CLOSED excluding CLOSED - DUPLICATE and CLOSED - COMPLETE.
>>> Should we expand this to all redmine users?
>> +1 to expand it to all users.
>>> If we expand this permission, this should give us the ability to safely
>>> close out issues that fit some criteria. I looked at the pulpcore issues
>>> and limited the issues to just ones without a Katello tag or a BZ and that
>>> were created before 2020[0]. This still leaves us with almost 300 NEW
>>> issues in pulpcore which still seems unrealistic to go through. Any
>>> thoughts on what criteria to use?
>> We could also exclude issues that have Pulp2 tag.
>> Even if we end up having 300 issues to process, I know that sounds a lot,
>> but we can regularly dedicate 5 mins(timeboxed!) of our pulpcore team
>> meeting, or open floor to go through. For some issues it is enough to read
>> the title to make a decision.
>> I *think* this might be a feasible idea, look how many and good
>> improvements we did in redmine having it on the agenda for each open floor.
>> Alsom, what will be the state of the issues we are going to mass close -
>>> [0] It would be better to use updated at to scope issues but
>>> unfortunately a lot of older issues have been updated recently due to spam
>>> comment
>>> David
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200807/066bbe9a/attachment.htm>

More information about the Pulp-dev mailing list