Re: [tracecompass-dev] Proposal: Trace Compass Extension (Incubation) su

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

This makes a lot of sense in my opinion.

It works very well in the optic of having a place that can get student's
work out to users faster this is marketing gold.

I personally would love to use this as a way to share ideas that are IMO
good to go, but not yet in Trace Compass. One thing to be very careful
of is to make sure the code is IP-clean though. That would be
super-painful to deal with later. The point of this IMO would be to make
it easier to pull contributions by generating buzz around them.

@All, how about putting the zesty callgraph view in there?

I for one am excited

Matthew


On 17-03-15 10:49 AM, Genevieve Bastien wrote:
> 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
>
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev