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 <rc...@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 <davidda...@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 <dkli...@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 <bkear...@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 <rc...@redhat.com >>>> > <mailto:rc...@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 < >>>> bbout...@redhat.com >>>> > <mailto:bbout...@redhat.com>> wrote: >>>> > >>>> > >>>> > >>>> > On Tue, Apr 2, 2019 at 5:23 PM Austin Macdonald >>>> > <aus...@redhat.com <mailto:aus...@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 >>>> > <aus...@redhat.com <mailto:aus...@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 >>>> > <bbout...@redhat.com <mailto:bbout...@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@redhat.com <mailto:Pulp-dev@redhat.com> >>>> > https://www.redhat.com/mailman/listinfo/pulp-dev >>>> > >>>> > _______________________________________________ >>>> > Pulp-dev mailing list >>>> > Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com> >>>> > https://www.redhat.com/mailman/listinfo/pulp-dev >>>> > >>>> > _______________________________________________ >>>> > Pulp-dev mailing list >>>> > Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com> >>>> > https://www.redhat.com/mailman/listinfo/pulp-dev >>>> > >>>> > _______________________________________________ >>>> > Pulp-dev mailing list >>>> > Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com> >>>> > https://www.redhat.com/mailman/listinfo/pulp-dev >>>> > >>>> > >>>> > _______________________________________________ >>>> > Pulp-dev mailing list >>>> > Pulp-dev@redhat.com >>>> > https://www.redhat.com/mailman/listinfo/pulp-dev >>>> > >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
