[Pulp-dev] Pulp2 Bug Backlog Closing?

Brian Bouterse bbouters at redhat.com
Mon Apr 8 20:47:23 UTC 2019


Thanks David!

Here is a new query with that addition:  http://tinyurl.com/yxqyto7q

On Mon, Apr 8, 2019 at 4:40 PM David Davis <daviddavis at redhat.com> wrote:

> 8 of the issues in your query are on the current sprint. You should
> probably filter by Sprint = None.
>
> David
>
>
> On Mon, Apr 8, 2019 at 4:11 PM Brian Bouterse <bbouters at redhat.com> wrote:
>
>> There seems to be some support to close those Pulp2 issues not in an
>> external tracker. How do people feel about us taking a mass-close action
>> this Friday April 12th? Specifically on Friday I would:
>>
>> 1. close all issues shown in the "no external tracker related" items,
>> this query: http://tinyurl.com/yyf3m8ma
>> 2. send an email with a csv record of everything that was mass-closed.
>> This way anyone can look at them at any point and port, reopen, re-read,
>> etc.
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 5, 2019 at 11:52 PM Om Prakash Singh <ompnix at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 05-Apr-2019, at 8:53 PM, Robin Chan <rchan at redhat.com> wrote:
>>>
>>> Let me amend my comments to say, I was recommending the closures for
>>> Pulp 2 issue not linked to an external tracker. Also, another suggestion is
>>> that mini-team could take the action to close the Pulp 2 redmine issues as
>>> a way to break up the work.
>>>
>>> I think it would be great if we can copy over the correct issues over to
>>> GitHub issues and close the rest of others.
>>>
>>> For issues linked to an external bug tracker -David Davis on IRC
>>> indicated yesterday that the number of issues linked to an external bug
>>> tracker is manageable to go through. I'd want to make sure we aren't going
>>> to cause any automation to change statuses on the external bug tracker that
>>> aren't discussed ahead of time with stakeholders.
>>>
>>> On Thu, Apr 4, 2019 at 9:55 AM David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> At first I was thinking we could keep stories open and just close bugs
>>>> and tasks. However, I skimmed through open Pulp 2 stories and it seems a
>>>> lot (or most) aren't even applicable to Pulp 3.
>>>>
>>>> It's easy enough for a user to re-open (or open) an issue if they feel
>>>> like it needs to be addressed in Pulp 2 or Pulp 3. So I agree with bulk
>>>> closing.
>>>>
>>>> David
>>>>
>>>>
>>>> On Thu, Apr 4, 2019 at 9:47 AM Dennis Kliban <dkliban at redhat.com>
>>>> wrote:
>>>>
>>>>> Byan,
>>>>>
>>>>> What you are saying makes a lot of sense to me. The architectural
>>>>> differences between Pulp 2 and Pulp 3 are so great that most bugs don't
>>>>> translate well from one to the other. I would prefer if we just mass close
>>>>> Pulp 2 issues.
>>>>>
>>>>> On Thu, Apr 4, 2019 at 9:27 AM Bryan Kearney <bkearney at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I was involved in the Satellite 5 to Satellite 6 bug triage. We
>>>>>> brought
>>>>>> known issues foreward, and after a few months the language and usage
>>>>>> was
>>>>>> so different that we ended up buk closing.
>>>>>>
>>>>>> So, I could see moving over feature requests if they may sense, but if
>>>>>> the RFE is unique to pulp2 or if it is bug against pulp2 I would
>>>>>> suggest
>>>>>> you delete/abandon it.
>>>>>>
>>>>>> -- bk
>>>>>>
>>>>>> On 4/4/19 8:52 AM, Kersom wrote:
>>>>>> > I do like the idea to evaluate Pulp 2 issues and create tickets for
>>>>>> Pulp
>>>>>> > 3 - mainly to avoid some known problems.
>>>>>> >
>>>>>> > Perhaps, we could create a new label on pulp.plan.io
>>>>>> > <http://pulp.plan.io> to distinguish those ones when migrated to
>>>>>> Pulp 3.
>>>>>> > And file as a related issue to the previous Pulp 2 one.
>>>>>> >
>>>>>> > On Thu, Apr 4, 2019 at 8:45 AM Robin Chan <rchan at redhat.com
>>>>>> > <mailto:rchan at redhat.com>> wrote:
>>>>>> >
>>>>>> >     re: going through open tickets - you can use the BK suggested
>>>>>> >     algorithm and monthly query for from some criteria (say last
>>>>>> >     touched) and review & close with the same message. We a pick a
>>>>>> >     target by which we wish to close all of the older Pulp 2 issues
>>>>>> that
>>>>>> >     won't be addressed and pick a criteria to chunk through them.
>>>>>> >
>>>>>> >     I would pick a fixed amount of time (both deadline &
>>>>>> communicating
>>>>>> >     to other active devs so we aren't doubling effort) to dedicate
>>>>>> to
>>>>>> >     finding issues to keep & convert to Pulp 3 items and just cut
>>>>>> it off
>>>>>> >     after that. That approach makes sense to me in that once you get
>>>>>> >     past a certain time (which I believe is pretty small,) you are
>>>>>> >     hitting diminishing returns. We could use that time to fix more
>>>>>> >     issues or just write a ticket again on Pulp 3.
>>>>>> >
>>>>>> >     Care should be taken to ensure pulp-list & blog post to cover:
>>>>>> >     - why prior to the closing
>>>>>> >     - what a user should do if they would like to pursue a fix (i.e.
>>>>>> >     will we take a pr? can they open a pulp 3 issue?)
>>>>>> >
>>>>>> >     -Robin
>>>>>> >
>>>>>> >     On Wed, Apr 3, 2019 at 5:28 PM Brian Bouterse <
>>>>>> bbouters at redhat.com
>>>>>> >     <mailto:bbouters at redhat.com>> wrote:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >         On Tue, Apr 2, 2019 at 5:23 PM Austin Macdonald
>>>>>> >         <austin at redhat.com <mailto:austin at redhat.com>> wrote:
>>>>>> >
>>>>>> >             I think if we close a lot of them, closed issues will be
>>>>>> >             very difficult to find with ~4500 bugs (open and
>>>>>> closed).
>>>>>> >             I've been spending some time combing the backlog
>>>>>> recently,
>>>>>> >             and I'm compiling lists of bugs that I think can be
>>>>>> closed.
>>>>>> >             What I am also finding are tickets that could
>>>>>> reasonably be
>>>>>> >             updated for Pulp 3. IMO, these tickets are common enough
>>>>>> >             that it would be worth our time to consider them.
>>>>>> >
>>>>>> >
>>>>>> >         I think this list would be great. Can we start a shared list
>>>>>> >         somewhere for backlog items we do want to keep?
>>>>>> >
>>>>>> >
>>>>>> >             Of course, going through the enormous backlog will be
>>>>>> very
>>>>>> >             time consuming. If we agree that there is too much
>>>>>> value to
>>>>>> >             close the lot of them, then AFAICT the only path
>>>>>> forward is
>>>>>> >             to coordinate the effort and move through it over time.
>>>>>> >
>>>>>> >
>>>>>> >         This is my concern mainly. I don't know how to go through
>>>>>> 1125
>>>>>> >         tickets. Also, I am also partly concerned with an outcome
>>>>>> where
>>>>>> >         the Pulp3 issues contain a historical record of pulp2
>>>>>> requests
>>>>>> >         "ported" to pulp3. If the reporter or stakeholder isn't
>>>>>> around
>>>>>> >         to advocate for a fix or feature themselves, then I believe
>>>>>> we
>>>>>> >         can serve the current users best by focusing on those things
>>>>>> >         that are actively being requested (newly file'd issues).
>>>>>> >
>>>>>> >         Still, if you have a list of items and they make sense to
>>>>>> port
>>>>>> >         we should do so.
>>>>>> >
>>>>>> >
>>>>>> >             On Tue, Apr 2, 2019 at 5:22 PM Austin Macdonald
>>>>>> >             <austin at redhat.com <mailto:austin at redhat.com>> wrote:
>>>>>> >
>>>>>> >                 I think if we close a lot of them, closed issues
>>>>>> will be
>>>>>> >                 very difficult to find with ~4500 bugs (open and
>>>>>> >                 closed). I've been spending some time combing the
>>>>>> >                 backlog recently, and I'm compiling lists of bugs
>>>>>> that I
>>>>>> >                 think can be closed. What I am also finding are
>>>>>> tickets
>>>>>> >                 that could reasonably be updated for Pulp 3. IMO,
>>>>>> these
>>>>>> >                 tickets are common enough that it would be worth our
>>>>>> >                 time to consider them.
>>>>>> >
>>>>>> >                 Of course, going through the enormous backlog will
>>>>>> be
>>>>>> >                 very time consuming. If we agree that there is too
>>>>>> much
>>>>>> >                 value to close the lot of them, then AFAICT the only
>>>>>> >                 path forward is to coordinate the effort and move
>>>>>> >                 through it over time.
>>>>>> >
>>>>>> >                 On Tue, Apr 2, 2019 at 5:06 PM Brian Bouterse
>>>>>> >                 <bbouters at redhat.com <mailto:bbouters at redhat.com>>
>>>>>> wrote:
>>>>>> >
>>>>>> >                     As Pulp2 approaches the maintenance mode we
>>>>>> have a
>>>>>> >                     large number of Pulp2 bugs open. A query [0]
>>>>>> shows
>>>>>> >                     1125 open Pulp2 bugs alone as of just now. We
>>>>>> will
>>>>>> >                     likely address a small set of these before Pulp2
>>>>>> >                     reaches its final release. What can we do to
>>>>>> bring
>>>>>> >                     transparency into what will versus won't be
>>>>>> fixed
>>>>>> >                     for Pulp2?
>>>>>> >
>>>>>> >                     The most reasonable option I can think to
>>>>>> propose is
>>>>>> >                     a mass-close of the Pulp2 bugs except for those
>>>>>> that
>>>>>> >                     we are actively working or planning to start
>>>>>> work
>>>>>> >                     soon on. Overall I believe Pulp2 is nearing a
>>>>>> point
>>>>>> >                     that if we aren't actively working or planning
>>>>>> >                     something for it we won't want to leave it open
>>>>>> on
>>>>>> >                     the "Pulp 2 backlog ". Bugs accidentally closed
>>>>>> >                     could be reopened without much trouble probably.
>>>>>> >
>>>>>> >                     What do you think about the of a
>>>>>> >                     close-all-but-active Pulp2 bugs idea?
>>>>>> >                     How would you coordinate such an effort?
>>>>>> >
>>>>>> >                     [0]: https://tinyurl.com/y289wx5p
>>>>>> >
>>>>>> >                     Thanks,
>>>>>> >                     Brian
>>>>>> >
>>>>>> >
>>>>>> >                     _______________________________________________
>>>>>> >                     Pulp-dev mailing list
>>>>>> >                     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com
>>>>>> >
>>>>>> >
>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>> >
>>>>>> >             _______________________________________________
>>>>>> >             Pulp-dev mailing list
>>>>>> >             Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>>>>>> >             https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>> >
>>>>>> >         _______________________________________________
>>>>>> >         Pulp-dev mailing list
>>>>>> >         Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>>>>>> >         https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>> >
>>>>>> >     _______________________________________________
>>>>>> >     Pulp-dev mailing list
>>>>>> >     Pulp-dev at redhat.com <mailto: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
>>>>>> >
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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/20190408/9c766974/attachment.htm>


More information about the Pulp-dev mailing list