[Pulp-dev] Pulp2 Bug Backlog Closing?
Corey Welton
cwelton at redhat.com
Thu Apr 11 18:53:10 UTC 2019
Late to the party here, but is it prudent to close Pulp 2 issues given that
Pulp 2 will be sticking around Satellite for quite some time?
I have read the conversations in this thread about how to limit the scope
of closure, but I still wonder how wise a notion this is. Is it premature
to call Pulp 2 near EOL or "maintenance mode" when we've got downstream
products reliant on it for a significant amount of time in the future?
Not trying to open a can of worms, just wondering if we're going to need to
have more specific focus on Pulp 2 than previously anticipated.
On Fri, Apr 5, 2019 at 11:28 AM 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190411/a64e0572/attachment.htm>
More information about the Pulp-dev
mailing list