[Pulp-dev] Pulp2 Bug Backlog Closing?

Tatiana Tereshchenko ttereshc at redhat.com
Thu Apr 11 10:31:15 UTC 2019


Thank you!
+1

On Wed, Apr 10, 2019 at 6:37 PM David Davis <daviddavis at redhat.com> wrote:

> +1
>
> David
>
>
> On Wed, Apr 10, 2019 at 11:19 AM Dennis Kliban <dkliban at redhat.com> wrote:
>
>>
>> On Wed, Apr 10, 2019 at 11:12 AM Brian Bouterse <bbouters at redhat.com>
>> wrote:
>>
>>> Thank you for the feedback. Also, this is a great idea. Overall I think
>>> some helpful info on why this is being closed and what anyone could do to
>>> reopen it would be good. This way anyone who does want to contribute still
>>> can and we are clear on that. What about if I leave the following comment
>>> on all items closed on Friday in the query? Please edit or +1 or send more
>>> ideas.
>>>
>>> ---- comment start ----
>>>
>>> Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not
>>> being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is
>>> still accepting contributions though, so if you want to contribute a fix
>>> for this ticket, please reopen or comment on it. If you don't have
>>> permissions to reopen this ticket, or you want to discuss an issue, please
>>> reach out via the "developer mailing list":
>>> https://www.redhat.com/mailman/listinfo/pulp-dev.
>>>
>>> --- commend end ----
>>>
>>>
>> That looks great to me.
>>
>>
>>
>>> On Tue, Apr 9, 2019 at 1:19 PM Tatiana Tereshchenko <ttereshc at redhat.com>
>>> wrote:
>>>
>>>> Sounds good to me.
>>>> One suggestion. How about asking for a contribution before closing,
>>>> however only in cases when we expect to accept the contribution?
>>>> e.g. not a huge or risky change, and the bug fix is important for a
>>>> reporter.
>>>> It will be clear for community that we are still willing to accept
>>>> contributions to Pulp 2 if they really need those changes.
>>>> Adding issues to the sprint usually indicates that Pulp core team is
>>>> working on them or there is already a PR opened.
>>>>
>>>> Tanya
>>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 11:18 PM Brian Bouterse <bbouters at redhat.com>
>>>> wrote:
>>>>
>>>>> In conversation with @kersom a question came up:  How would Pulp2 bugs
>>>>> be handled in the future?
>>>>>
>>>>> With Pulp2 approaching maintenance mode I think the general idea is
>>>>> that Pulp2 bugs can be filed, but unless they are added to the sprint
>>>>> during triage they would be closed WONTFIX with a note indicating Pulp2 is
>>>>> approaching maintenance mode. This is effectively the same process we
>>>>> already apply to Pulp2 bugs except that instead of sending to the Pulp2
>>>>> backlog we close them.
>>>>>
>>>>> Ideas and feedback is welcome!
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 8, 2019 at 4:47 PM Brian Bouterse <bbouters at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>> _______________________________________________
>>>>> 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/20190411/f241c873/attachment.htm>


More information about the Pulp-dev mailing list