On 2/13/2012 1:51 AM, Martyn Russell wrote:
On 10/02/12 16:14, Lionel Dricot wrote:
Hi,
Hello Lionel,
After discussing with Taras during FOSDEM, I've put some thoughts on how
to make DXR rock and have some appeal in the community.
Currently, I see some weaknesses that may hurt DXR massive adoption.
IMHO, this should be fixed before speaking more about DXR.
1) Indexing consume too much memory, making it impossible to use on less
than high-end server.
I agree. But this is really a hurdle subject to the project you index at
the moment. If you use glib or not some conglomerate project like
LibreOffice then things are fine.
I think it needs tackling at some point.
2) DXR is too tight to mozilla-central
Do you mean "tied" ?
If so, can you elaborate?
3) Indexing is currently too slow (is it really a problem?)
Generally in our experience with Tracker¹ on embedded devices, you
either choose to optimise for querying or indexing. I think querying is
more important here.
There may also be some low hanging fruit to improve the indexing speed
here though that we should look into :)
¹ http://projects.gnome.org/tracker/
4) DXR is hard to install and to use.
I agree. I was discussing this with Carlos/Lionel on Friday. It wouldn't
be much work to make the project properly deploy-able and to have a bit
more documentation to make the process and tools easier to use for first
timers.
5) I still don't have a clear picture on how to use one DXR instance
with multiple repositories
Well, right now AFAIU, it doesn't matter. You point DXR at a directory
and it will index it. This directory could contain all your project
interests.
I think ultimately, you don't want a separate virtual host or URL per
project, you want one for all.
I want debian/fedora to DXR all of their code, so we can have a
replacement for google code :)
Regarding 2), we have identified the HG link and are currently trying to
put that in a config file.
A solution that covers git and other repositories should also be
considered IMO.
1) and 3) looks rather critical because, for now, you need an high-end
machine and lote of time just to test it.
Well, yes, with mozilla-central. Most people will likely try the project
with smaller projects, but we should expect some famous cases (like the
Linux Kernel) to be tried I agree.
For 4), Carlos think that DXR should use autotools (or, I would say,
python-distutils). That would allow easy installation and, even more,
distribution packages. We should also make some clear shell commands :
index, deploy. Even a small PyGTK gui might be done quickly. Anyway, lot
of opportunity there.
So, what are, in your opinion, the priorities of DXR as an OpenSource
project? Should we try to make a roadmap?
I think a wiki with a roadmap makes sense so others can edit it in
place. Taras, is this possible to do here:
https://wiki.mozilla.org/DXR
Above wiki has a specific structure for Malini and other build&release
people.
Feel free to take over https://wiki.mozilla.org/DXR_Future_Work_Plan .
As long as we have a really appealing dxr.mozilla.org(current iteration
shows potential, but is not yet very appealing) and have a sufficiently
sane deployment story contributors will help us with the rest the
"papercut" issues discussed above.
Taras
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
