Mikhail Khodjaiants wrote:
I agree with the proposed
process in general, it seems to be the way to go. Here are my 2
cents (or pennies, whichever currency you prefer)
:-)
The hierarchy of components
should follow the simple rule: from generic to more specific. For
instance, the following would be the ideal structure for Debug
(I understand it would require some serious efforts to implement it):
Common core and UI: used by
all debug models, includes support for generic breakpoints, common
views and menu actions, common launch configuration parts
Model level components: standard model/CDI, DSF, etc
Implementation
level components: CDI/GDB, DSF/GDB, etc
I absolutely agree that the debug component could and should be split
in such a way, but it will take some work to separate these components
into their own plugins which is a requirement in my proposall for
having separate components. I didn't want this change to hinge upon any
future development work so that's why I suggested to just have this
Debug component for now until it could be split.
The proposal to have a PMC and component
leaders is very good, but it would take a lot of time from the persons
involved. Is it realistic to expect this type of commitment
from companies? The first step would be to find out who is committed to
take these roles.
Absolutely. So if a component ddidn't have a volunteer to act as a
leader, the process in that component would just remain as it is now.
However, given that there would be a formal role defined for a
component leader that would hopefully give some incentive for a
volunteer to fill that role and gain the recognition that goes with
it. Also, in reality there already are leaders in the CDT community
who contribute to the process that exists in CDT.
Cheers,
Pawel
Regards,
Mikhail
Hi All,
...
|
