Re: Changes

[Dodji Seketeli <dseketel at redhat dot com>]

Thiago Jung Bauermann a Ãcrit :

[...]

> > * Integrate with Eclipse
>
> The debugger being in C++, do you see this happening with an MI-like
> interface?

I'd think that starting off with the debugging engine being alone in its 
own process can be something good for many reasons:

1/being in one coherent language, whatever the language is. If the 
language is c/c++ that eases debugging during developments thanks to 
tools like valgrind etc ...

2/shield the user interface against wierd things like signal based 
interactions that can happen between the debugging engine and the 
inferior process being debugged.

3/gives a chance to the UI process to be single threaded, using 
mainloops like the glib mainloop or the Qt mainloop to come up with non 
 blocking UIs and still being asynchronously notified about state 
changes in the remote debugging engine process.

This scenario requires a wire protocol. It's not obliged to be GDB/MI, 
though.

[...]

> Nice. IMHO, starting from scratch again in C++ would be just more work
> at the end of the day... IMHO again the way to go is to reuse as much
> code as possible, including from GDB. The idea is to take the shortest
> path to a good working solution.
Exactly. That's also why having the debugger in C/C++ can be 
interesting. It eases code sharing with GDB. Much more than if we need 
to write (and debug) bindings each time we want to use a C function 
coming from outside.

[...]

> So having a GUI separate from Eclipse is within the goal of the project?
> Just not the existing one? Sorry, I'm not sure I understood this part.

I'd think that if the APIs UI <-> debugging engine are well defined and 
nice, debugger UIs including ad hoc tools built by other project to 
debug particular scenarii we don't even know about today will be likely 
to flourish.

> > * Process.  We'd like to institute some form of patch review.  Ideally
> >   this would be low on bureaucracy; perhaps just an Apache-style "+1"
> >   voting system.  The intent here is to raise coding standards overall
> >   -- make sure that features have more polish when they go in, and
> >   that both internal and external documentation are included.
>
> I like the idea of a patch review process, I agree it will be a benefit.

Yes, I like that as well.

If we stick to git - I love git - I think it could be nice do something 
like what the X.org project did. Potential contributors foo could be 
given write access to sourceware.org/users/foo so that they can slam 
their own branches in there. They'd then post urls to the commits (in 
their branches) they want to see pushed to the official tree and wait 
for reviewers approval. Of course that wouldn't remove the possibility 
to send patches to the list directly.

My 2 euro cents.

Cheers,

Dodji.