[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] 6 month release cycle
|
Or, we could test packages the old-fashioned way -- by actively getting
our community involved and excited about the developer builds. This
means Tweeting, blogging, announcing and selling the cool new features
that go into the new releases.
It's a lot of work, but I'm willing to bet that a large community
involvement will be more beneficial than any amount of smoke tests or
unit tests.
One way the EMO can help out here is to compile New and Noteworthy
changelogs from Bugzilla bugs featuring the "noteworthy" keyword so
that, from the main downloads page, we can easily point our users to
what's new. In turn, that should compel them to download developer
builds. Minimal effort on you, the committer.
I've opened http://bugs.eclipse.org/412317 to investigate this further.
Denis
On 07/04/2013 07:15 AM, Igor Fedorenko wrote:
I don't think this is a workable approach.
First, such a test needs to run on all supported platform and jvm
combinations, which makes already involved task pretty much impossible
to perform, at least for small dev teams like we have in m2e.
Second, this won't actually find interoperability problems because in
most cases "other" projects will remain dormant, i.e. you actually have
to have projects in git repository in order to see if your plugin works
with egit or not.
--
Regards,
Igor
On 2013-07-04 2:43 PM, Mickael Istria wrote:
On 07/04/2013 12:34 PM, Pascal Rapicault wrote:
What you seem to suggest is that a project higher up the stack test
against the base. I think that by construct this is true bearing the
change of version of the base.
Not exactly, what I'm suggesting is that a project run test against *all
the content* of the release train installed. Some will be dependencies
and are anyway necessary for test to start, some other are independent,
and may interact with the project in an unexpected way.
Any project contributor takes an Eclipse, installs all Kepler bundles
(EGit, Subversive, WTP, m2eclipse, GMF, XText...) with the magic "Select
All" button of p2 installer, then it runs the tests against this huge
platform. That's how project can notice, additionally to their
acceptance tests validation product functionality, some "integration"
bugs such as conflicting jobs/builders and can guarantee that it works
together with the whole release train.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
