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 <davidda...@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 <bbout...@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 <omp...@gmail.com> >> wrote: >> >>> >>> >>> On 05-Apr-2019, at 8:53 PM, 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. >>> >>> 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 <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 >>> >> _______________________________________________ >> 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