[Pulp-dev] Pulp2 Bug Backlog Closing?
Kersom
kersom at redhat.com
Fri Apr 12 20:52:49 UTC 2019
Total per component.
Crane 16
Docker Support 52
Nectar 17
OSTree Support 11
Pulp 689
Puppet Support 41
Python Support 12
RPM Support 186
Total 1024
On Fri, Apr 12, 2019 at 4:33 PM Brian Bouterse <bbouters at redhat.com> wrote:
> As I'm sure you can see from the redmine notifications, the mass-closing
> happened. 1024 issues were CLOSED - WONTFIX, each with a comment inviting
> it to be reopened if someone is able to contribute to it.
>
> Attached is a csv file containing all of the issues that were closed
> WONTFIX. This is a pretty easy way to look over them if anyone is
> interested.
>
> Thank you,
> Brian
>
>
> On Thu, Apr 11, 2019 at 3:12 PM Robin Chan <rchan at redhat.com> wrote:
>
>> Corey,
>> I agree that the term "near" to "maintentance mode" will probably not be
>> within the "near" expectation for most folks.
>> We agreed to exclude redmine issue with external trackers associated to
>> it for Satellite and do a evaluation of those on a 1x1 basis.
>> However I don't think that anything in the foreseeable future changing
>> our resource dedication to Pulp 3. Any changes in Pulp 2 are probably yet
>> to be requested now (issue not written yet) or in those items we will
>> review on a 1x1 basis.
>> Does that help?
>> Robin
>>
>> On Thu, Apr 11, 2019 at 2:53 PM Corey Welton <cwelton at redhat.com> wrote:
>>
>>> 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
>>>>
>>> _______________________________________________
>> 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/20190412/93cd1f0c/attachment.htm>
More information about the Pulp-dev
mailing list