Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tracecompass-dev] Proposal: Trace Compass Extension (Incubation) sub-project


I propose to start a new permanent incubator sub-project of Trace Compass called Trace Compass Extension.


1- Faster deployment of new features, to get feedback from the end users. In this sub-project, features can be submitted as soon as they are ready to go public and integrate nicely with the rest of Trace Compass. They don't necessarily have to be final, code-clean or go through thorough review as with the main repo.

2- Separate committers base. So anyone submitting a stand-alone feature should be granted committer status there and remain maintainer of the code.

3- No release cycle. Permanent incubators do not have releases, though they have builds and downloads, so the plugins there can have their own lifecycle. Also, nothing, except other plugins in the repo, should depend on them.

4- Having those additional features centralized at Eclipse make it easier to maintain and there is one place to look for them. Right now at Poly, we did experimental branches that are forks of Trace Compass, one for each conference we went to and had new features to showcase. That is hard to maintain, hard to discover, people are not really using that fork, and it often took months before the features demoed made it to Trace Compass master. Also, having those features at Eclipse ensures IP due diligence of the code, especially for students that may be long gone by the time their contributions makes it in.

5- Evolution by natural selection: plugins and features will be proposed in this new sub-project. Some may graduate to the main project (it is easy from a permanent incubator to its parent project), some may remain there and get their own development team there. Others may graduate to somewhere else maybe, and some will get extinct if there is no interest, but all will have a chance to reach the community.


1- Ideally, standalone features that do not require any changes to the main Trace Compass repo. That should actually be the way to develop new analyses/functionnality. That may require to make Trace Compass more extendable (for example, I have a few patches on gerrit to allow the XML analysis plugins to be extended by external plugins), but those changes should be small compared to the whole new features in the main repo, and have wider benefits. If there's need, we can discuss that, either on a patch, on the mailing list, on bugzilla, on irc...

2- Any work that falls within the scope of Trace Compass (see [1], because the scope of a sub-project has to be within the scope of its parent project), that would benefit the community and gain from exposure, but may not be fully clean and ready for main repo, under active development, etc. Code reviews will be less strict in this project: it has to work, not throw exceptions all over the place, there should be no aberration in the code, but otherwise, only code meant to graduate soon will be looked at in more details.

Example features that we (Polytechnique) plan to submit: Generic callstacks and Trace-Compass-traces analyses, Virtual machine analyses, Real-time constraint analysis, Web traces analyses

How? (the big idea: details will be documented later)

1- Plugins should come as Eclipse features, so they can be deployed on an update site: so typically, for a "feature", that means a few plugins: one .core, one .ui, optionally (but highly recommended) .tests and swtbot.tests, one feature plugin and one documentation plugin. They should be gathered in a sub-directory of the repo.

2- The pom.xml should be updated to take them into account. This sub-project is not a code dump. Features proposed here should be built and made available, so Hudson has to pass for each commit (though some project settings may be relaxed).

Thoughts? Objections? Questions? Planned contributions? ;-)




Back to the top