[Pulp-dev] Pulp2 Bug Backlog Closing?
David Davis
daviddavis at redhat.com
Wed Apr 10 16:36:02 UTC 2019
+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190410/b2857e0a/attachment.htm>
More information about the Pulp-dev
mailing list