Re: [cross-project-issues-dev] 6 month release cycle

[Doug Schaefer <dschaefer@xxxxxxx>]

Agreed, and we do get a fair amount of testing of the packages right now.
The download numbers aren't zero.

But we only really get that during a ramp down which gives focus to that
marketing. While the idea of allowing projects to release at any
"milestone" gives them much needed flexibility, we still need to ensure
we're providing focus on the packages and having official release
cadences, maybe on 6 month cycles, would give us the best of both worlds.
And besides, the train is what brings the community together as a greater
whole. I'd hate to lose that.

BTW, I love the idea of testing your projects with everything else in the
repository. It's amazing how different behaviour is from language project
to language project. I have half a mind to create an true Eclipse IDE
package that contained everything so people can see what it's like :)

D

On 13-07-04 9:41 AM, "Denis Roy" <denis.roy@xxxxxxxxxxx> wrote:

>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
>>
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev