@EvanProdromou, that sounds like a good thing to pursue. Definitely something worth investigating. Let me poke Tyler/Dan to see the feasibility for using K8s for that today. I know that there's some work in this space that could be leveraged.
@Aklapper, this was basically a request for assistance with Chromium profiling. If you know any particular person and/or team that might have expertise with this, please let me know. That being said, I'm not sure if Piotr still needs help with this.
@pmiazga, is this something that you still need help with? If not, are there any learnings/findings about this topic that you're able to share?
Fri, Feb 15
Thu, Feb 14
@greg @Kunal, @Krinkle and I were chatting about moving this forward. Sounds like the next step is to have a discussion about what it would take to archive the data. Once we scope it out a bit we'll be in a better position to understand the effort involved and whether or not we need to get supplemental funding.
Wed, Feb 13
In any case, and with the risk of repeating myself, the service is under a code stewardship request cause it does not have currently a maintainer. If we want to keep it around, we need first and foremost a maintainer.
@MarcoAurelio, we're going to move forward on undeploying this extension from production. I'll create a task shortly.
Tue, Feb 12
Thu, Jan 24
If I interpret this correctly, the reason we are looking to undeploy/sunset this extension is because it is no longer actively used for code review activities and we are looking to reduce the deployed code base in order to minimize complexity/failure points. It is however, used for historical review of past code changes. The desired outcome would then be to undeploy the extension whilst preserving access to past code review activities.
My key takeaway from this discuss is that although we could address the issues/shortcomings of this extension as it is today, there isn't much perceived value in doing so. As a result, it appears to make the most sense to move forward undeploying/sunsetting this extension.
Jan 16 2019
I was thinking about having a session about the broader Code Health topic on the unconference day. Perhaps we could discuss this in more depth during that session (if it happens :-)).
Dec 17 2018
Dec 13 2018
Dec 11 2018
Nov 27 2018
The post mortem process now includes a section on test/escape analysis.
Current unit test coverage has become part of the Code Health newsletter. Code coverage numbers will also be a key component of what is reported through the Code Health Metrics.
Progress to date:
- Slow going at first as this is a shared goal. Originally a Q1 goal, this has moved to a Q2 goal in order to allow CPT to get through some of its PEP planning.
- Meeting with CPT this week to plan next steps.
Progress to date:
@Catrope, we can certainly find another home for this extension if you think another team is a better fit. Out of curiosity, is this related at all to the change from Collaboration to Growth? I'm trying to get a sense of whether the wrong call was made when we first reviewed this extension for Code Stewardship or if things just changed since then.
Nov 15 2018
Nov 6 2018
@Aklapper, I was thinking that simply removing it from Developers/Maintainers would suffice from a documentation perspective. As maintenance of Developers/Maintainers page is currently manual and this removal comes as a result of the code stewardship review process, I'll make the edit(if it's not already been removed).
@Liuxinyu970226, yes that makes sense.
Nice work all!
Oct 29 2018
Oct 25 2018
Oct 22 2018
Oct 12 2018
Oct 3 2018
Forgot my password :-( Waiting for reset.
Yeah, not a stellar job of documentation :-) I'll do a better job next time. I do want to followup to make sure that this made it through the change from Collaboration to Growth.
@Krinkle, it's supposed to mean that a Code Steward has been found/assigned. In this case it was the Collaboration team. Which is now the Growth team if I understand correctly.
Oct 2 2018
Sep 25 2018
Sep 24 2018
Makes sense to me.