Hi Zach,
Thanks for putting the data in a spreadsheet - that’s easier to navigate.
And thanks for re-raising the question whether we have the right components in
bugzilla.
As I think this could be an area for lots of different opinions, without any
near-perfect solution, it has the potential to
Correct. One important part of the migration is the ability to keep
the various CIs and other integrations intact via switching to
svn-from-git bridge:
https://help.github.com/articles/support-for-subversion-clients/
Otherwise the things might be even more complicated for downstream users.
On Fri,
To elaborate, I didn't mean to group all components with less than 10 bugs
into one massive component. Rather, to do it separately for each
subcomponent. Grouping by expertise is fine, but I would argue that a
component with 2 or 3 bugs filed per year is not a very useful component.
There has to
Hello Alex, hello Pavel
I spent some time creating/streamlining our CMake infrastructure downstream of
LLDB and learned a few things about bundles, versions, code-signing etc.
(mostly on the Darwin side of things). I am currently sorting out what can be
upstreamed and prepare reviews.
Some wor
Hi Zach,
Thanks for elaborating.
I like your proposal. I agree it still groups per area of expertise. And it
makes the set of components we have easier to manage.
Before making changes though I hope to hear opinions from others on this.
What do others think?
Thanks,
Kristof
On 9 Nov 2018, at 1
I had considered a libraries/Backends:Other as well that would be separate
from libraries/Other
On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff wrote:
> I wonder if backends are a special case to the heuristic of "let's not
> make a bug component for code components that are too small". LLVM is
>
I also think that backends are a special case, and each should have its own
component. Also a code owner, which I think is already the case; and just like
ensuring patches get reviewed, a backend code owner should ensure there is a
triager. It makes the list of components a bit longer, but add
cc lldb-dev since the original message cc'd it.
On 11/9/18, 12:31 PM, "Alex Langford" wrote:
Hi Stefan,
Thanks for taking the time to improve LLDB's CMake infrastructure!
(1) I don't entirely remember the reason I had separated them out into
separate targets. A post-build
I tried to run this command:
(lldb) target variable "std::numeric_limits::max_exponent"
In Variable.cpp:386 we run a regex against the input string which results
in the above string being cut down to just `std::numeric_limits`. So then
I search my debug info and don't find anything.
What I need
