[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[tracecompass-dev] Proposal: Trace Compass Extension (Incubation) sub-project
|
Hi,
I propose to start a new permanent incubator sub-project of Trace
Compass called Trace Compass Extension.
Why?
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.
What?
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? ;-)
Cheers,
Geneviève
[1] https://projects.eclipse.org/projects/tools.tracecompass/governance
