6 month release cycle

Discussion:

6 month release cycle

(too old to reply)

Doug Schaefer

2013-07-02 19:30:47 UTC

Hey gang,

We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that.

Doug.

Konstantin Komissarchik

2013-07-02 19:39:26 UTC

In a lot of ways, we already have this with the service releases. A number
of projects have shifted to shipping feature-bearing, but compatible
releases as part of SRs. If we wanted to formalize what seems to have
evolved organically, we could call June releases "major" and the other two
"minor".

- Konstantin

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Doug
Schaefer
Sent: Tuesday, July 02, 2013 12:31 PM
To: cross-project-issues-***@eclipse.org
Subject: [cross-project-issues-dev] 6 month release cycle

Hey gang,

We have a discussion going in the CDT community and we are currently
planning out how to achieve a 6 month release cycle. The feeling is that we
need to get new features out faster to our users. The year long wait we
currently have is making releases sluggish and I fear it's slowing down
growth in our community. A 6 month cycle should infuse us with a little more
energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our
larger Eclipse community thought it might be a good idea for other projects
at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and
everything, I thought we should bring that to a greater audience and see
what other projects thought and whether it's something we should bring to
the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream during
the year, but bringing things together more often might be a help to many
others. But I'd like to hear your thoughts on that.

Doug.

Doug Schaefer

2013-07-02 19:47:00 UTC

[cross-project-issues-de= ] on behalf of Konstantin Komissarchik [konstantin.kom= ]

1970-01-01 00:00:00 UTC

For more context, here is the proposal we put to the CDT community after our monthly conference call. We didn't really consider whether the train would change as well:
----
Hey gang,

We talked about this on our call this morning. There is a lot of interest, and actually always has been, in moving to more frequent release cycle. Yearly is great if you are a stable platform that doesn't need to change much, but our feeling is that the CDT still has a lot of work left to do.

And I actually think that yearly cycles reduces the appeal of contributing to Eclipse. Who wants to make a contribution and then wait a year to have a release they can use it with. Even the major Linux distros release semi-yearly.

So here's what we came up with and we need to hear from you and tweak it so that it's captures all our needs (or as many as we can).

* Release in June along with the Eclipse release train as before.
* Release the SR-1 for that release in Sept as before.
* Release a new feature release in December, not too late where it interferes with the holiday season.
* Release the SR-2 for the last June release with the rest of the train in Feb as before to satisfy the needs of people stuck on the older CDT release.
* Release the SR-1 for the December release in March or April.
* Release in June again, and repeat.

So, for example, this year we have:

June – 8.2.0
Sept – 8.2.1
Dec – 8.3.0
Feb – 8.2.2
Mar – 8.3.1
June – 8.4.0

________________________________
From: cross-project-issues-dev-***@eclipse.org [cross-project-issues-dev-***@eclipse.org] on behalf of Konstantin Komissarchik [***@oracle.com]
Sent: Tuesday, July 02, 2013 3:39 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] 6 month release cycle

In a lot of ways, we already have this with the service releases. A number of projects have shifted to shipping feature-bearing, but compatible releases as part of SRs. If we wanted to formalize what seems to have evolved organically, we could call June releases “major” and the other two “minor”.

- Konstantin

From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Doug Schaefer
Sent: Tuesday, July 02, 2013 12:31 PM
To: cross-project-issues-***@eclipse.org
Subject: [cross-project-issues-dev] 6 month release cycle

Hey gang,

We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that.

Doug.

--_000_B915FC3FDD916C49A6D8918DA94036D1066F04BDexmbx3ottqnxcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style>

</style><style type="text/css" id="owaParaStyle"></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">

Igor Fedorenko

2013-07-02 19:49:43 UTC

I agree, one year is way too long. I am not even sure 6 months is often
enough. We had three m2e releases between Juno and Kepler, and I
consider m2e mature, (relatively) low-activity project. At the same
time, I never use R builds myself, I always use M-builds as primary
development environment for my $DAY_JOB. I don't suggest we do
full-blown release every 6 weeks, but maybe there is a way to elevate
perceived status of M builds such that users are more comfortable using
them.

--
Regards,
Igor

On 2013-07-02 11:30 PM, Doug Schaefer wrote:
> Hey gang,
>
> We have a discussion going in the CDT community and we are currently
> planning out how to achieve a 6 month release cycle. The feeling is that
> we need to get new features out faster to our users. The year long wait
> we currently have is making releases sluggish and I fear it's slowing
> down growth in our community. A 6 month cycle should infuse us with a
> little more energy, so goes the hope.
>
> I mentioned CDT's plans on twitter and a number of senior members of our
> larger Eclipse community thought it might be a good idea for other
> projects at Eclipse and maybe for the train itself. And I think so too.
>
> Instead of continuing that discussion on twitter, which is fun and
> everything, I thought we should bring that to a greater audience and see
> what other projects thought and whether it's something we should bring
> to the Planning Council and the rest of the EMO.
>
> I know there are a number of projects already releasing off stream
> during the year, but bringing things together more often might be a help
> to many others. But I'd like to hear your thoughts on that.
>
> Doug.
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

Doug Schaefer

2013-07-02 19:56:11 UTC

Funny, that came up in our conversation too. Years ago, M releases were awesome. They always had new features and the quality was pretty good. But then the quality stopped being so good and there were less features, so people cared less about M releases. And that has left a long period of time where people really care about Eclipse releases.

D

________________________________________
From: cross-project-issues-dev-***@eclipse.org [cross-project-issues-dev-***@eclipse.org] on behalf of Igor Fedorenko [***@sonatype.com]
Sent: Tuesday, July 02, 2013 3:49 PM
To: cross-project-issues-***@eclipse.org
Subject: Re: [cross-project-issues-dev] 6 month release cycle

I agree, one year is way too long. I am not even sure 6 months is often
enough. We had three m2e releases between Juno and Kepler, and I
consider m2e mature, (relatively) low-activity project. At the same
time, I never use R builds myself, I always use M-builds as primary
development environment for my $DAY_JOB. I don't suggest we do
full-blown release every 6 weeks, but maybe there is a way to elevate
perceived status of M builds such that users are more comfortable using
them.

--
Regards,
Igor

On 2013-07-02 11:30 PM, Doug Schaefer wrote:
> Hey gang,
>
> We have a discussion going in the CDT community and we are currently
> planning out how to achieve a 6 month release cycle. The feeling is that
> we need to get new features out faster to our users. The year long wait
> we currently have is making releases sluggish and I fear it's slowing
> down growth in our community. A 6 month cycle should infuse us with a
> little more energy, so goes the hope.
>
> I mentioned CDT's plans on twitter and a number of senior members of our
> larger Eclipse community thought it might be a good idea for other
> projects at Eclipse and maybe for the train itself. And I think so too.
>
> Instead of continuing that discussion on twitter, which is fun and
> everything, I thought we should bring that to a greater audience and see
> what other projects thought and whether it's something we should bring
> to the Planning Council and the rest of the EMO.
>
> I know there are a number of projects already releasing off stream
> during the year, but bringing things together more often might be a help
> to many others. But I'd like to hear your thoughts on that.
>
> Doug.
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

Igor Fedorenko

2013-07-02 20:17:08 UTC

What's the point of releasing often if there are no new features?

--
Regards,
Igor

On 2013-07-02 11:56 PM, Doug Schaefer wrote:
> Funny, that came up in our conversation too. Years ago, M releases were awesome. They always had new features and the quality was pretty good. But then the quality stopped being so good and there were less features, so people cared less about M releases. And that has left a long period of time where people really care about Eclipse releases.
>
> D
>
> ________________________________________
> From: cross-project-issues-dev-***@eclipse.org [cross-project-issues-dev-***@eclipse.org] on behalf of Igor Fedorenko [***@sonatype.com]
> Sent: Tuesday, July 02, 2013 3:49 PM
> To: cross-project-issues-***@eclipse.org
> Subject: Re: [cross-project-issues-dev] 6 month release cycle
>
> I agree, one year is way too long. I am not even sure 6 months is often
> enough. We had three m2e releases between Juno and Kepler, and I
> consider m2e mature, (relatively) low-activity project. At the same
> time, I never use R builds myself, I always use M-builds as primary
> development environment for my $DAY_JOB. I don't suggest we do
> full-blown release every 6 weeks, but maybe there is a way to elevate
> perceived status of M builds such that users are more comfortable using
> them.
>
> --
> Regards,
> Igor
>
> On 2013-07-02 11:30 PM, Doug Schaefer wrote:
>> Hey gang,
>>
>> We have a discussion going in the CDT community and we are currently
>> planning out how to achieve a 6 month release cycle. The feeling is that
>> we need to get new features out faster to our users. The year long wait
>> we currently have is making releases sluggish and I fear it's slowing
>> down growth in our community. A 6 month cycle should infuse us with a
>> little more energy, so goes the hope.
>>
>> I mentioned CDT's plans on twitter and a number of senior members of our
>> larger Eclipse community thought it might be a good idea for other
>> projects at Eclipse and maybe for the train itself. And I think so too.
>>
>> Instead of continuing that discussion on twitter, which is fun and
>> everything, I thought we should bring that to a greater audience and see
>> what other projects thought and whether it's something we should bring
>> to the Planning Council and the rest of the EMO.
>>
>> I know there are a number of projects already releasing off stream
>> during the year, but bringing things together more often might be a help
>> to many others. But I'd like to hear your thoughts on that.
>>
>> Doug.
>>
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-***@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

Ian Bull

2013-07-02 20:08:32 UTC

One of the things we need to understand is *what do we want from a release
train?*

1. Is it simply a release of the latest and greatest stuff Eclipse has?
2. Is it a set of plugins / components that are known to 'work together'?
3. Is it a co-ordinated marketing exercise?
4. Is it a snap-shot in time of what we have?
5. Is it something else?

There is nothing wrong with components doing their own release and coming
together 1+2 times a year (release plus SRs). In this case the latest and
greatest are in the SR0, SR1 & SR2. We could also approach this from a
two-stream perspective. Latest and greatest is in the Milestones, and the
SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I
don't think we should mix & match approaches.

I'm sure with 71 projects in the release train, we'll arrive at 71
different meanings for the train.

Doug, in the case of CDT, could you consider M4 & M7 your 'releases' (after
a few rounds of RCs of course)? What version of the platform do you want
for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do
you expect / need marketing support for both releases? Do you expect both
releases to be of the same quality (will vendors build on both)?

Just a few more questions to hopefully help drive the discussion :-)

Cheers,
Ian

On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko <***@sonatype.com>wrote:

> I agree, one year is way too long. I am not even sure 6 months is often
> enough. We had three m2e releases between Juno and Kepler, and I
> consider m2e mature, (relatively) low-activity project. At the same
> time, I never use R builds myself, I always use M-builds as primary
> development environment for my $DAY_JOB. I don't suggest we do
> full-blown release every 6 weeks, but maybe there is a way to elevate
> perceived status of M builds such that users are more comfortable using
> them.
>
> --
> Regards,
> Igor
>
>
> On 2013-07-02 11:30 PM, Doug Schaefer wrote:
>
>> Hey gang,
>>
>> We have a discussion going in the CDT community and we are currently
>> planning out how to achieve a 6 month release cycle. The feeling is that
>> we need to get new features out faster to our users. The year long wait
>> we currently have is making releases sluggish and I fear it's slowing
>> down growth in our community. A 6 month cycle should infuse us with a
>> little more energy, so goes the hope.
>>
>> I mentioned CDT's plans on twitter and a number of senior members of our
>> larger Eclipse community thought it might be a good idea for other
>> projects at Eclipse and maybe for the train itself. And I think so too.
>>
>> Instead of continuing that discussion on twitter, which is fun and
>> everything, I thought we should bring that to a greater audience and see
>> what other projects thought and whether it's something we should bring
>> to the Planning Council and the rest of the EMO.
>>
>> I know there are a number of projects already releasing off stream
>> during the year, but bringing things together more often might be a help
>> to many others. But I'd like to hear your thoughts on that.
>>
>> Doug.
>>
>>
>> ______________________________**_________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>
>> ______________________________**_________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Doug Schaefer

2013-07-02 20:27:51 UTC

Spurring on the development of new features is part of what's driving
this. Only the early adopters ever download milestone builds and we're
trying to be more agile to a larger audience by going twice as often.

D

On 13-07-02 4:17 PM, "Igor Fedorenko" <***@sonatype.com> wrote:

>What's the point of releasing often if there are no new features?
>
>--
>Regards,
>Igor
>
>On 2013-07-02 11:56 PM, Doug Schaefer wrote:
>> Funny, that came up in our conversation too. Years ago, M releases were
>>awesome. They always had new features and the quality was pretty good.
>>But then the quality stopped being so good and there were less features,
>>so people cared less about M releases. And that has left a long period
>>of time where people really care about Eclipse releases.
>>
>> D
>>
>> ________________________________________
>> From: cross-project-issues-dev-***@eclipse.org
>>[cross-project-issues-dev-***@eclipse.org] on behalf of Igor
>>Fedorenko [***@sonatype.com]
>> Sent: Tuesday, July 02, 2013 3:49 PM
>> To: cross-project-issues-***@eclipse.org
>> Subject: Re: [cross-project-issues-dev] 6 month release cycle
>>
>> I agree, one year is way too long. I am not even sure 6 months is often
>> enough. We had three m2e releases between Juno and Kepler, and I
>> consider m2e mature, (relatively) low-activity project. At the same
>> time, I never use R builds myself, I always use M-builds as primary
>> development environment for my $DAY_JOB. I don't suggest we do
>> full-blown release every 6 weeks, but maybe there is a way to elevate
>> perceived status of M builds such that users are more comfortable using
>> them.
>>
>> --
>> Regards,
>> Igor
>>
>> On 2013-07-02 11:30 PM, Doug Schaefer wrote:
>>> Hey gang,
>>>
>>> We have a discussion going in the CDT community and we are currently
>>> planning out how to achieve a 6 month release cycle. The feeling is
>>>that
>>> we need to get new features out faster to our users. The year long wait
>>> we currently have is making releases sluggish and I fear it's slowing
>>> down growth in our community. A 6 month cycle should infuse us with a
>>> little more energy, so goes the hope.
>>>
>>> I mentioned CDT's plans on twitter and a number of senior members of
>>>our
>>> larger Eclipse community thought it might be a good idea for other
>>> projects at Eclipse and maybe for the train itself. And I think so too.
>>>
>>> Instead of continuing that discussion on twitter, which is fun and
>>> everything, I thought we should bring that to a greater audience and
>>>see
>>> what other projects thought and whether it's something we should bring
>>> to the Planning Council and the rest of the EMO.
>>>
>>> I know there are a number of projects already releasing off stream
>>> during the year, but bringing things together more often might be a
>>>help
>>> to many others. But I'd like to hear your thoughts on that.
>>>
>>> Doug.
>>>
>>>
>>> _______________________________________________
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-***@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-***@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-***@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-***@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Doug Schaefer

2013-07-02 20:28:15 UTC

Thanks Ian, to answer your questions:

We do expect both releases to be the same quality and vendors will build on both, especially those vendors who need and are likely contributing the new features.

We would build the mid-term release on the June platform. Although, we would love it if the platform released on the same cadence since a lot of what we need requires changes to both (project/build, debug/launch). Not to mention any serious contribution to cleaning up the Eclipse Platform UI to improve look and workflows that would benefit everyone, but that's a whole other set of issues.

Both releases require their own ramp down so I'm not sure the M's would line up with the train properly. But I haven't looked at that yet.

We do acknowledge that we need to spin the Eclipse C/C++ IDE package every six months as well to ensure our objective of getting users the new features faster is met. And the marketing along with that would certainly help get the word out that a new release is available.

From: Ian Bull <***@eclipsesource.com<mailto:***@eclipsesource.com>>
Reply-To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>
Date: Tuesday, 2 July, 2013 4:08 PM
To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>
Subject: Re: [cross-project-issues-dev] 6 month release cycle

One of the things we need to understand is what do we want from a release train?

1. Is it simply a release of the latest and greatest stuff Eclipse has?
2. Is it a set of plugins / components that are known to 'work together'?
3. Is it a co-ordinated marketing exercise?
4. Is it a snap-shot in time of what we have?
5. Is it something else?

There is nothing wrong with components doing their own release and coming together 1+2 times a year (release plus SRs). In this case the latest and greatest are in the SR0, SR1 & SR2. We could also approach this from a two-stream perspective. Latest and greatest is in the Milestones, and the SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't think we should mix & match approaches.

I'm sure with 71 projects in the release train, we'll arrive at 71 different meanings for the train.

Doug, in the case of CDT, could you consider M4 & M7 your 'releases' (after a few rounds of RCs of course)? What version of the platform do you want for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you expect / need marketing support for both releases? Do you expect both releases to be of the same quality (will vendors build on both)?

Just a few more questions to hopefully help drive the discussion :-)

Cheers,
Ian

On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko <***@sonatype.com<mailto:***@sonatype.com>> wrote:
I agree, one year is way too long. I am not even sure 6 months is often
enough. We had three m2e releases between Juno and Kepler, and I
consider m2e mature, (relatively) low-activity project. At the same
time, I never use R builds myself, I always use M-builds as primary
development environment for my $DAY_JOB. I don't suggest we do
full-blown release every 6 weeks, but maybe there is a way to elevate
perceived status of M builds such that users are more comfortable using
them.

--
Regards,
Igor

On 2013-07-02 11:30 PM, Doug Schaefer wrote:
Hey gang,

We have a discussion going in the CDT community and we are currently
planning out how to achieve a 6 month release cycle. The feeling is that
we need to get new features out faster to our users. The year long wait
we currently have is making releases sluggish and I fear it's slowing
down growth in our community. A 6 month cycle should infuse us with a
little more energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our
larger Eclipse community thought it might be a good idea for other
projects at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and
everything, I thought we should bring that to a greater audience and see
what other projects thought and whether it's something we should bring
to the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream
during the year, but bringing things together more often might be a help
to many others. But I'd like to hear your thoughts on that.

Doug.

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Ian Bull

2013-07-02 21:03:44 UTC

The schedule you propose is interesting Doug. Two things stand out -- Your
december release only has a one SR. (There is no 8.3.2). The second thing
is that you plan on maintaining your June (Kepler) contribution in Feb
(Kepler SR2). This is fine, but this is the opposite of what others have
done. EGit (and Mylyn too, I think) have released new versions with the
SRs. I'm not going judge what's better, but I don't like the fact that they
are different.

For example, the February 2014 will potentially have the latest and
greatest EGit and a maintenance release of CDT after a new release was just
announced. Combine that with the milestone stream that will undoubtedly be
moving forward and our users will be hit with a confusing set of available
sites from which to find their software. Also, what version of the CDT will
be available in the MarketPlace next February?

I'm not picking on anybody here. I think this demonstrates that we need to
do something regarding multiple releases per year, and I'm doing my best do
understand the different constraints we have.

Cheers,
Ian

On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer <***@qnx.com> wrote:

> Thanks Ian, to answer your questions:
>
> We do expect both releases to be the same quality and vendors will build
> on both, especially those vendors who need and are likely contributing the
> new features.
>
> We would build the mid-term release on the June platform. Although, we
> would love it if the platform released on the same cadence since a lot of
> what we need requires changes to both (project/build, debug/launch). Not to
> mention any serious contribution to cleaning up the Eclipse Platform UI to
> improve look and workflows that would benefit everyone, but that's a whole
> other set of issues.
>
> Both releases require their own ramp down so I'm not sure the M's would
> line up with the train properly. But I haven't looked at that yet.
>
> We do acknowledge that we need to spin the Eclipse C/C++ IDE package
> every six months as well to ensure our objective of getting users the new
> features faster is met. And the marketing along with that would certainly
> help get the word out that a new release is available.
>
>
> From: Ian Bull <***@eclipsesource.com>
> Reply-To: Cross project issues <cross-project-issues-***@eclipse.org>
> Date: Tuesday, 2 July, 2013 4:08 PM
> To: Cross project issues <cross-project-issues-***@eclipse.org>
>
> Subject: Re: [cross-project-issues-dev] 6 month release cycle
>
> One of the things we need to understand is *what do we want from a
> release train?*
>
> 1. Is it simply a release of the latest and greatest stuff Eclipse has?
> 2. Is it a set of plugins / components that are known to 'work together'?
> 3. Is it a co-ordinated marketing exercise?
> 4. Is it a snap-shot in time of what we have?
> 5. Is it something else?
>
> There is nothing wrong with components doing their own release and
> coming together 1+2 times a year (release plus SRs). In this case the
> latest and greatest are in the SR0, SR1 & SR2. We could also approach this
> from a two-stream perspective. Latest and greatest is in the Milestones,
> and the SR0, SR1 and SR2s are the LTS versions. Both of these will work,
> but I don't think we should mix & match approaches.
>
> I'm sure with 71 projects in the release train, we'll arrive at 71
> different meanings for the train.
>
> Doug, in the case of CDT, could you consider M4 & M7 your 'releases'
> (after a few rounds of RCs of course)? What version of the platform do you
> want for your mid-term release (i.e. will Dec 2013 build on Kepler or
> Luna)? Do you expect / need marketing support for both releases? Do you
> expect both releases to be of the same quality (will vendors build on both)?
>
> Just a few more questions to hopefully help drive the discussion :-)
>
> Cheers,
> Ian
>
>
> On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko <***@sonatype.com>wrote:
>
>> I agree, one year is way too long. I am not even sure 6 months is often
>> enough. We had three m2e releases between Juno and Kepler, and I
>> consider m2e mature, (relatively) low-activity project. At the same
>> time, I never use R builds myself, I always use M-builds as primary
>> development environment for my $DAY_JOB. I don't suggest we do
>> full-blown release every 6 weeks, but maybe there is a way to elevate
>> perceived status of M builds such that users are more comfortable using
>> them.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2013-07-02 11:30 PM, Doug Schaefer wrote:
>>
>>> Hey gang,
>>>
>>> We have a discussion going in the CDT community and we are currently
>>> planning out how to achieve a 6 month release cycle. The feeling is that
>>> we need to get new features out faster to our users. The year long wait
>>> we currently have is making releases sluggish and I fear it's slowing
>>> down growth in our community. A 6 month cycle should infuse us with a
>>> little more energy, so goes the hope.
>>>
>>> I mentioned CDT's plans on twitter and a number of senior members of our
>>> larger Eclipse community thought it might be a good idea for other
>>> projects at Eclipse and maybe for the train itself. And I think so too.
>>>
>>> Instead of continuing that discussion on twitter, which is fun and
>>> everything, I thought we should bring that to a greater audience and see
>>> what other projects thought and whether it's something we should bring
>>> to the Planning Council and the rest of the EMO.
>>>
>>> I know there are a number of projects already releasing off stream
>>> during the year, but bringing things together more often might be a help
>>> to many others. But I'd like to hear your thoughts on that.
>>>
>>> Doug.
>>>
>>>
>>> ______________________________**_________________
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
>>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>>
>>> ______________________________**_________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>
>
>
>
> --
> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
> http://eclipsesource.com | http://twitter.com/eclipsesource
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Konstantin Komissarchik

2013-07-02 21:27:12 UTC

It goes back to the primary goal behind simrel. The original goal was to
synchronize the releases and aggregation was secondary. With some projects
wishing to release more frequently and some projects slowing down, perhaps
the primary focus should be on aggregation rather than synchronizing
everyone's schedule.

Suppose for a minute that we ran the aggregation process monthly. All
projects contribute the latest finished release they have, dependencies are
reconciled, some cross-testing happens and it's out. Every month, there is a
repo with versions of all participating projects that are known to work
together. Users are happy because they only need to check for updates from
the aggregate repository that delivers new stuff to them frequently.
Projects are happy because they can set schedules that make sense for their
needs and if they miss one deadline, the next opportunity is not that far
away.

- Konstantin

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Ian Bull
Sent: Tuesday, July 02, 2013 2:04 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

The schedule you propose is interesting Doug. Two things stand out -- Your
december release only has a one SR. (There is no 8.3.2). The second thing is
that you plan on maintaining your June (Kepler) contribution in Feb (Kepler
SR2). This is fine, but this is the opposite of what others have done. EGit
(and Mylyn too, I think) have released new versions with the SRs. I'm not
going judge what's better, but I don't like the fact that they are
different.

For example, the February 2014 will potentially have the latest and greatest
EGit and a maintenance release of CDT after a new release was just
announced. Combine that with the milestone stream that will undoubtedly be
moving forward and our users will be hit with a confusing set of available
sites from which to find their software. Also, what version of the CDT will
be available in the MarketPlace next February?

I'm not picking on anybody here. I think this demonstrates that we need to
do something regarding multiple releases per year, and I'm doing my best do
understand the different constraints we have.

Cheers,

Ian

On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer <***@qnx.com> wrote:

Thanks Ian, to answer your questions:

We do expect both releases to be the same quality and vendors will build on
both, especially those vendors who need and are likely contributing the new
features.

We would build the mid-term release on the June platform. Although, we would
love it if the platform released on the same cadence since a lot of what we
need requires changes to both (project/build, debug/launch). Not to mention
any serious contribution to cleaning up the Eclipse Platform UI to improve
look and workflows that would benefit everyone, but that's a whole other set
of issues.

Both releases require their own ramp down so I'm not sure the M's would line
up with the train properly. But I haven't looked at that yet.

We do acknowledge that we need to spin the Eclipse C/C++ IDE package every
six months as well to ensure our objective of getting users the new features
faster is met. And the marketing along with that would certainly help get
the word out that a new release is available.

From: Ian Bull <***@eclipsesource.com>
Reply-To: Cross project issues <cross-project-issues-***@eclipse.org>
Date: Tuesday, 2 July, 2013 4:08 PM
To: Cross project issues <cross-project-issues-***@eclipse.org>

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

One of the things we need to understand is what do we want from a release
train?

1. Is it simply a release of the latest and greatest stuff Eclipse has?

2. Is it a set of plugins / components that are known to 'work together'?

3. Is it a co-ordinated marketing exercise?

4. Is it a snap-shot in time of what we have?

5. Is it something else?

There is nothing wrong with components doing their own release and coming
together 1+2 times a year (release plus SRs). In this case the latest and
greatest are in the SR0, SR1 & SR2. We could also approach this from a
two-stream perspective. Latest and greatest is in the Milestones, and the
SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't
think we should mix & match approaches.

I'm sure with 71 projects in the release train, we'll arrive at 71 different
meanings for the train.

Doug, in the case of CDT, could you consider M4 & M7 your 'releases' (after
a few rounds of RCs of course)? What version of the platform do you want for
your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you
expect / need marketing support for both releases? Do you expect both
releases to be of the same quality (will vendors build on both)?

Just a few more questions to hopefully help drive the discussion :-)

Cheers,

Ian

On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko <***@sonatype.com>
wrote:

I agree, one year is way too long. I am not even sure 6 months is often
enough. We had three m2e releases between Juno and Kepler, and I
consider m2e mature, (relatively) low-activity project. At the same
time, I never use R builds myself, I always use M-builds as primary
development environment for my $DAY_JOB. I don't suggest we do
full-blown release every 6 weeks, but maybe there is a way to elevate
perceived status of M builds such that users are more comfortable using
them.

--
Regards,
Igor

On 2013-07-02 11:30 PM, Doug Schaefer wrote:

Hey gang,

We have a discussion going in the CDT community and we are currently
planning out how to achieve a 6 month release cycle. The feeling is that
we need to get new features out faster to our users. The year long wait
we currently have is making releases sluggish and I fear it's slowing
down growth in our community. A 6 month cycle should infuse us with a
little more energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our
larger Eclipse community thought it might be a good idea for other
projects at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and
everything, I thought we should bring that to a greater audience and see
what other projects thought and whether it's something we should bring
to the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream
during the year, but bringing things together more often might be a help
to many others. But I'd like to hear your thoughts on that.

Doug.

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Dennis Hübner

2013-07-03 06:57:28 UTC

> All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and its out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away.

Finally a good idea!
I think this is exactly what projects and users want.
Being up-to-date makes aggregation repositories (look at maven central) valuable.

Best regards,
Dennis Hübner

Xtext Commiter / Build Engineer

Mobile: +49 (0) 151 / 17 39 67 07
Telefon: +49 (0) 431 / 990 268 70
Fax: +49 (0) 431 / 990 268 72

itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

Matthias Sohn

2013-07-03 07:22:37 UTC

On Wed, Jul 3, 2013 at 8:57 AM, Dennis HÃŒbner <***@itemis.de>wrote:

>
>
> All projects contribute the latest finished release they have,
> dependencies are reconciled, some cross-testing happens and itâs out. Every
> month, there is a repo with versions of all participating projects that are
> known to work together. Users are happy because they only need to check for
> updates from the aggregate repository that delivers new stuff to them
> frequently. Projects are happy because they can set schedules that make
> sense for their needs and if they miss one deadline, the next opportunity
> is not that far away.
>
>
> Finally a good idea!
> I think this is exactly what projects and users want.
> Being up-to-date makes aggregation repositories (look at maven
> central) valuable.
>

I like this proposal. IMO releasing often is a good thing.

Personally I most often use an M-build of the platform mixed with a recent
nightly
of those projects I am contributing to in order to experience what's coming
in.
At $DAYJOB we are releasing every 2 weeks.

So far we (JGit/EGit) did a release every 3 months shipping a major release
with SR0
and minor releases with SR1, SR2 and an additional one in Dec which doesn't
match
a release train delivery. If we would get the chance to release more often
I'd like to
participate in that, though I am not sure if we would be able to create a
new release
every month so e.g. during vacation time it may happen that we would not
ship a new
version.

--
Matthias

Henrik Rentz-Reichert

2013-07-03 07:33:57 UTC

some more considerations:

If we accelerate the release cycle this would also put an extra burden on the Eclipse legal staff, PMO and EMO (IP log approvals,
release reviews...)
Also, in my experience I need to start this process several weeks prior to the planned release.
A frozen IP log though means that I can't integrate 3rd party contributions any more into the upcoming release.

Thoughts?

Am 03.07.2013 09:22, schrieb Matthias Sohn:
> On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner <***@itemis.de <mailto:***@itemis.de>> wrote:
>
>
>
>> All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and
>> it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users
>> are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them
>> frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one
>> deadline, the next opportunity is not that far away.
>
> Finally a good idea!
> I think this is exactly what projects and users want.
> Being up-to-date makes aggregation repositories (look at maven central) valuable.
>
>
> I like this proposal. IMO releasing often is a good thing.
>
> Personally I most often use an M-build of the platform mixed with a recent nightly
> of those projects I am contributing to in order to experience what's coming in.
> At $DAYJOB we are releasing every 2 weeks.
>
> So far we (JGit/EGit) did a release every 3 months shipping a major release with SR0
> and minor releases with SR1, SR2 and an additional one in Dec which doesn't match
> a release train delivery. If we would get the chance to release more often I'd like to
> participate in that, though I am not sure if we would be able to create a new release
> every month so e.g. during vacation time it may happen that we would not ship a new
> version.
>
> --
> Matthias
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Mickael Istria

2013-07-03 08:26:54 UTC

IMO, we now have tools (Hudson) to guarantee a good quality for
integration build and putting us on the way to rolling release and
continuous delivery.
For SWTBot, I have to admit that making a release is just a "marketing"
effort in order to make some blog posts and tweets, because of its good
test suite, any snapshot which has tests working is better than the last
release. It's actually a continuous delivery on the snapshots, and I've
already recommended people to use snapshots many times because it's
better than previous release and I don't have time to spend on the
release right now. Basically, almost every snapshot could become a
release when you can trust your test suite.

Allowing project to have rolling-release/continuous-delivery was
something Andrew already mentioned on the CBI mailing-list, and I think
it's a good way to go for some projects. It's all the more true when
projects don't have a schedule or a roadmap because they're
community-driven, and change when community wants it to change.

When it comes to "release train", we should understand that as a quality
label which is given once a year: being part of release train means that
the version of your project you submit does conform to release train
requirements/level of quality. It should not (and AFAI Understand, it
does not) enforce a schedule for any project: a project that wants 3
releases in one year can do it, and project that did not have a release
in previous year can resubmit an older version to 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>

Pascal Rapicault

2013-07-03 09:06:20 UTC

Or it means that the workload on the IP team is spread more regularly throughout the year.

From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Henrik Rentz-Reichert
Sent: July-03-13 3:34 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

some more considerations:

If we accelerate the release cycle this would also put an extra burden on the Eclipse legal staff, PMO and EMO (IP log approvals, release reviews...)
Also, in my experience I need to start this process several weeks prior to the planned release.
A frozen IP log though means that I can't integrate 3rd party contributions any more into the upcoming release.

Thoughts?
Am 03.07.2013 09:22, schrieb Matthias Sohn:
On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner <***@itemis.de<mailto:***@itemis.de>> wrote:

All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away.

Finally a good idea!
I think this is exactly what projects and users want.
Being up-to-date makes aggregation repositories (look at maven central) valuable.

I like this proposal. IMO releasing often is a good thing.

Personally I most often use an M-build of the platform mixed with a recent nightly
of those projects I am contributing to in order to experience what's coming in.
At $DAYJOB we are releasing every 2 weeks.

So far we (JGit/EGit) did a release every 3 months shipping a major release with SR0
and minor releases with SR1, SR2 and an additional one in Dec which doesn't match
a release train delivery. If we would get the chance to release more often I'd like to
participate in that, though I am not sure if we would be able to create a new release
every month so e.g. during vacation time it may happen that we would not ship a new
version.

--
Matthias

_______________________________________________

cross-project-issues-dev mailing list

cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Gunnar Wagenknecht

2013-07-03 12:56:40 UTC

Hi,

Am 03.07.2013 um 00:33 schrieb Henrik Rentz-Reichert <***@protos.de>:

> some more considerations:
>
> If we accelerate the release cycle this would also put an extra burden on the Eclipse legal staff, PMO and EMO (IP log approvals, release reviews...)
> Also, in my experience I need to start this process several weeks prior to the planned release.
> A frozen IP log though means that I can't integrate 3rd party contributions any more into the upcoming release.
>
> Thoughts?

I wouldn't call it "burden" but "challenges". EMO (aka. Wayne) is already doing a great job of automating and streamlining as much of this as possible. We shouldn't plan our releases based on the process but optimize our process to allow for more frequent releases.

+1 to the general idea.

Big +1 to the idea of an "always current" aggregation repo that I can go to and fetch updates from. For me as a user it would be really nice to not track all projects individually.

The annual release still makes sense, though. It could become a stable baseline for LTS.

-Gunnar

--
Gunnar Wagenknecht
***@wagenknecht.org

Konstantin Komissarchik

2013-07-03 16:02:47 UTC

Glad to see interest in my frequent aggregation proposal. To answer some of
the questions that were raised...

1. Monthly releases sounds rather too frequent. Doesn't leave a lot of room
for milestones or IP team to do their work.

Projects would release at whatever pace makes sense to them, set their own
schedules and leave room for IP team to do their work. Some would continue
to release yearly, some would be on a six month cycle, some would release
even more frequently. The aggregation stream would only accept a finished
release.

In fact, given enough automation, the aggregation can become continuous.
Suppose that instead of the current system where projects edit stuff in Git,
there is a portal where projects contribute their release. Verification runs
automatically, if it fails, the contribution is rejected. No more missing
about.html files! The tool can also be available on "verify only" basis for
projects wishing to check their release candidates.

2. What happens if there is a dependency conflict? For instance, if GEF
pushes a new release, but the contributed GMF release still depends on the
old version.

We would very likely need to allow multiple versions in the repository for
frequent aggregation to work. Perhaps only the latest version is
categorized.

3. Should the aggregated repository be verified?

Yes. The primary value of the aggregated repository is that there is a
version of each component that can be installed together. If we don't verify
at aggregation time, we will lose that feature. However, with multiple
versions being present, the verification would need to be different. Instead
of verifying if everything can be installed together, it should verify if a
solution exists such that at least one version of each component can be
installed with everything else.

4. What about LTS and others who want more stability. Do we still need the
current release train for that?

Not really. Let's call what I've described the latest stream. Periodically,
the latest stream can be branched to create a stable stream of a given
vintage. Projects can still contribute to the stable stream, but the rules
are different (stricter). On the opposite end, we could also have a dev
stream, where projects can contribute their latest milestone builds,
integration builds, etc.

5. What would I build against?

Projects should be tracking the release plans of their dependencies and
build directly against the repositories published by their dependencies.
Building against any aggregation stream is risky since you never know which
version you are building against and you lose ability to reproduce your
build.

Thanks,

- Konstantin

Ed Willink

2013-07-03 08:55:29 UTC

Hi

On 03/07/2013 08:22, Matthias Sohn wrote:
> I like this proposal. IMO releasing often is a good thing.
But...

For projects with simple dependencies this should work.

However for complex dependencies, occasional stakes in the ground are
necessary.

Consider Xtext applications.

A) Eclipse (itemis) produces the Xtext (compile-time) and run-time
B) Eclipse/third party uses Xtext at compile-time to produce an XYZZY
editor and tooling depending on the Xtext run-time
C) Users install the XYZZY tooling

The flexibility of Xtext and DI means that there are backward and
forward dependencies between A and B since B was auto-generated against
an earlier A but runs on a new A. In practice this means that the Xtext
run-time API is very hard to evolve and the users may be forced to use
the Eclipse release on which the XYZZY editor was generated by B.

As the release cycle gets faster, it will get harder for users to find a
common platform for third party tools unless all important tools follow
the faster release cycle very promptly. No chance.

One could argue that such tight coupling between auto-generated code and
run-time is undesirable, but I just use Xtext as an example. I suspect
that there are many other projects where auto-generation presents
similar challenges.

So, Yes, let's have a half-yearly Intermediate Release, but please,
still just one Major release per year. Let planned API breakage occur
only prior to the last milestone of the Major release.

Regards

Ed Willink

Krzysztof Daniel

2013-07-03 09:44:10 UTC

For Eclipse as a product it is definitely good to have releases more
often. It will lower the entry barrier (patches could find a way in the
release in less then a year), and will attract new contributors.

BUT at the same time there is Eclipse as a platform, with API
compatibility, with service releases and specific change management
policies, which is totally different from the Eclipse-As-A-Product.

So, maybe the key point is that there is a need for two lines:
- release train, kept as it is currently
- rolling release - it is a product. rather for users then for
developers. New API and features can be withdrawn.

--
Krzysztof Daniel <***@redhat.com>
Red Hat

Ed Merks

2013-07-03 10:10:51 UTC

Releasing more often sounds like a good thing in principle and of course
projects are free to do so as they wish. One major concern I'd have
about the release train itself releasing more often is the long ramp
down cycle appearing twice as often per year. Of course the M/RC phase
would need to be shorted, but then the question is, why is it currently
so long? I expect the answer if to provide quality and stability, so
would that inevitably suffer as a result? That would be a bad thing...

Another question we must ask is what's best for the consumers/adopters?
On the one hand, I imagine for projects with very active feature
development, many of their consumers do want the latest and greatest as
often as possible. On the other hand, I also imagine that a great many
commercial adopters see quality and stability as their primary criteria
for adoption and hence see more value in SR1 and SR2 releases of a
stable base that's focused primarily on quality improvements compared to
all the new feature development, which is almost inevitably associated
with lower quality.

On 03/07/2013 11:44 AM, Krzysztof Daniel wrote:
> For Eclipse as a product it is definitely good to have releases more
> often. It will lower the entry barrier (patches could find a way in the
> release in less then a year), and will attract new contributors.
>
> BUT at the same time there is Eclipse as a platform, with API
> compatibility, with service releases and specific change management
> policies, which is totally different from the Eclipse-As-A-Product.
>
> So, maybe the key point is that there is a need for two lines:
> - release train, kept as it is currently
> - rolling release - it is a product. rather for users then for
> developers. New API and features can be withdrawn.
>
>
>

Pascal Rapicault

2013-07-03 09:31:23 UTC

I like the approach of everybody contributing their latest release to a new kind of repo.
However I'm wondering what happens when the dependencies are not aligned. For example GEF ships a new version but GMF ranges don't allow for it. Does the repo contain two versions of GEF or is GMF not included?

Now if we step back, the issue I'm describing is caused by the fact that the release repo is validated (validated means all the IUs in the repo can be installed together, to the exception of a couple IUs) in order to reduce the number of install time dependency resolution errors. However I'm thinking that now that p2 has the remediation mechanism , the necessity to have a validated repo is lessened since at install time p2 will figure out the right set of things to install (as well as things to uninstall and update), and in the case of a check for updates it will only propose the versions that can work together.

The advantage of shipping a non validated repo is that it reduces the burden of integration since the process of creating the repo is just a mirroring one.

All that said, I think that in addition to this new repo, there would still be value in creating a release repo where the content is validated and more stable.

Finally another thing to consider is which repo would users build against?

From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Dennis Hübner
Sent: July-03-13 2:57 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away.

Finally a good idea!
I think this is exactly what projects and users want.
Being up-to-date makes aggregation repositories (look at maven central) valuable.

Best regards,
Dennis Hübner

Xtext Commiter / Build Engineer

Mobile: +49 (0) 151 / 17 39 67 07
Telefon: +49 (0) 431 / 990 268 70
Fax: +49 (0) 431 / 990 268 72

itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

Ed Willink

2013-07-03 09:39:53 UTC

<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi<br>
<br>
P2's remediation is very impressive but unfortunately it is
dreadfully slooow.<br>
<br>
If the repo is not validated, every user is going to have to have a
tea break while P2 fixes things up.<br>
<br>
And if the repo is unvalidated, there will be a lot of fixing up. I
would be amazed if P2 could sort out the anarchy.<br>
<br>
So the users will wait a long time, get given an irritating please
confirm this magic solution that excludes your favourite product
dialog.<br>
<br>
Eclipse will become a laughing stock.<br>
<br>
    Regards<br>
<br>
        Ed Willink<br>
<br>
<div class="moz-cite-prefix">On 03/07/2013 10:31, Pascal Rapicault
wrote:<br>
</div>
<blockquote
cite="mid:***@eusaamb103.ericsson.se"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style></style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I
like the approach of everybody contributing their latest
release to a new kind of repo.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">However
I’m wondering what happens when the dependencies are not
aligned. For example GEF ships a new version but GMF ranges
don’t allow for it. Does the repo contain two versions of
GEF or is GMF not included? <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Now
if we step back, the issue I’m describing is caused by the
fact that the release repo is validated (validated means all
the IUs in the repo can be installed together, to the
exception of a couple IUs) in order to reduce the number of
install time dependency resolution errors. However I’m
thinking that now that p2 has the remediation mechanism ,
the necessity to have a validated repo is lessened since at
install time p2 will figure out the right set of things to
install (as well as things to uninstall and update), and in
the case of a check for updates it will only propose the
versions that can work together.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The
advantage of shipping a non validated repo is that it
reduces the burden of integration since the process of
creating the repo is just a mirroring one.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">All
that said, I think that in addition to this new repo, there
would still be value in creating a release repo where the
content is validated and more stable.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Finally
another thing to consider is which repo would users build
against?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">
<a class="moz-txt-link-abbreviated" href="mailto:cross-project-issues-dev-***@eclipse.org">cross-project-issues-dev-***@eclipse.org</a>
[<a class="moz-txt-link-freetext" href="mailto:cross-project-issues-dev-***@eclipse.org">mailto:cross-project-issues-dev-***@eclipse.org</a>]
<b>On Behalf Of </b>Dennis Hübner<br>
<b>Sent:</b> July-03-13 2:57 AM<br>
<b>To:</b> Cross project issues<br>
<b>Subject:</b> Re: [cross-project-issues-dev] 6 month
release cycle<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span class="apple-style-span"><span
style="font-size:11.5pt;font-family:"Calibri","sans-serif";color:#1F497D">All
projects contribute the latest finished release they
have, dependencies are reconciled, some cross-testing
happens and it’s out. Every month, there is a repo with
versions of all participating projects that are known to
work together. Users are happy because they only need to
check for updates from the aggregate repository that
delivers new stuff to them frequently. Projects are
happy because they can set schedules that make sense for
their needs and if they miss one deadline, the next
opportunity is not that far away.</span></span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Finally a good idea!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I think this is exactly what projects and
users want.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Being up-to-date makes aggregation
repositories (look at maven central) valuable.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black">Dennis
Hübner<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black">Xtext
Commiter / Build Engineer<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black"><br>
<br>
Mobile: +49 (0) 151 / 17 39 67 07<br>
Telefon: +49 (0) 431 / 990 268 70<br>
Fax: +49 (0) 431 / 990 268 72<br>
<br>
itemis AG<br>
Niederlassung Kiel<br>
Am Germaniahafen 1<br>
24143 Kiel<br>
<a moz-do-not-send="true"
href="http://www.itemis.de/">http://www.itemis.de/</a><br>
<br>
Rechtlicher Hinweis:<br>
<br>
Amtsgericht Dortmund, HRB 20621<br>
<br>
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus,
Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus<br>
<br>
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan
Grollmann, Michael Neuhaus<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cross-project-issues-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cross-project-issues-***@eclipse.org">cross-project-issues-***@eclipse.org</a>
<a class="moz-txt-link-freetext" href="https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev">https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<p class="" avgcert""="" color="#000000" align="left">No virus
found in this message.<br>
Checked by AVG - <a moz-do-not-send="true"
href="http://www.avg.com">www.avg.com</a><br>
Version: 2013.0.3345 / Virus Database: 3204/6458 - Release Date:
07/02/13</p>
</blockquote>
<br>
</body>
</html>

Pascal Rapicault

2013-07-03 10:19:33 UTC

What you need to realize is that whether the repo is validated or not, the remediation will still happen when the user try to install something (or install a new version) that is incompatible with what is already installed. For example with this hypothetical scenario:

- Imagine the user has the platform and GMF installed with a tight dependency on the platform. When the user decides to install the new version of the platform, then the installed version of GMF is no longer suitable, so the remediation will kick in. This will happen whether the p2 repo the user is installing from is validated or not. This is simply rooted in the fact that the user only wants to install one particular component without any desire to understand the dependencies.

The only case where the user would not see any remediation is the check for updates. This is because in Kepler we've improved the logic to look for the "highest applicable version" of each IU rather than systematically proposing the highest version.

I would assume that if we were to really provide frequent updates, then users would use the check for updates.

Now on the details of remediation and p2 resolver.
I agree that the remediation can be slow, and this is dependent on the number of repos you have enabled. Then there is the uncompressible time it takes to resolve dependencies and figure out the solutions and for this whether the repos are validated or not does not matter. The p2 resolver has been built to deal with inconsistent repository content , and it has been proven to scale by participating in dependency resolver competitions. So to answer your question, you can give a mess of dependency and p2 will still figure out something.

From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Ed Willink
Sent: July-03-13 5:40 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

Hi

P2's remediation is very impressive but unfortunately it is dreadfully slooow.

If the repo is not validated, every user is going to have to have a tea break while P2 fixes things up.

And if the repo is unvalidated, there will be a lot of fixing up. I would be amazed if P2 could sort out the anarchy.

So the users will wait a long time, get given an irritating please confirm this magic solution that excludes your favourite product dialog.

Eclipse will become a laughing stock.

Regards

Ed Willink
On 03/07/2013 10:31, Pascal Rapicault wrote:
I like the approach of everybody contributing their latest release to a new kind of repo.
However I'm wondering what happens when the dependencies are not aligned. For example GEF ships a new version but GMF ranges don't allow for it. Does the repo contain two versions of GEF or is GMF not included?

Now if we step back, the issue I'm describing is caused by the fact that the release repo is validated (validated means all the IUs in the repo can be installed together, to the exception of a couple IUs) in order to reduce the number of install time dependency resolution errors. However I'm thinking that now that p2 has the remediation mechanism , the necessity to have a validated repo is lessened since at install time p2 will figure out the right set of things to install (as well as things to uninstall and update), and in the case of a check for updates it will only propose the versions that can work together.

The advantage of shipping a non validated repo is that it reduces the burden of integration since the process of creating the repo is just a mirroring one.

All that said, I think that in addition to this new repo, there would still be value in creating a release repo where the content is validated and more stable.

Finally another thing to consider is which repo would users build against?

From: cross-project-issues-dev-***@eclipse.org<mailto:cross-project-issues-dev-***@eclipse.org> [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Dennis Hübner
Sent: July-03-13 2:57 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away.

Finally a good idea!
I think this is exactly what projects and users want.
Being up-to-date makes aggregation repositories (look at maven central) valuable.

Best regards,
Dennis Hübner

Xtext Commiter / Build Engineer

Mobile: +49 (0) 151 / 17 39 67 07
Telefon: +49 (0) 431 / 990 268 70
Fax: +49 (0) 431 / 990 268 72

itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

_______________________________________________

cross-project-issues-dev mailing list

cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2013.0.3345 / Virus Database: 3204/6458 - Release Date: 07/02/13

Doug Schaefer

2013-07-02 21:12:53 UTC

We're still debating what to do with the SR-2. The proposal was an early conservative one that was aimed to appease the community that doesn't want to live on the bleeding edge. Egit, you pretty much have to live on the bleeding edge since it's still pushing some basic features that everyone needs.

But I could see us forgoing SR-2 altogether at some point and release the Dec CDT release at SR-2 time.

I just think releasing random lineups every 4 months as somewhat happens now with those projects doesn't give you that focus on producing a known line-up that just works (and as we all know, we have had issues with Egit just landing randomly in a release cycle). SR testing is much lighter than release testing from my experience.

From: Ian Bull <***@eclipsesource.com<mailto:***@eclipsesource.com>>
Reply-To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>
Date: Tuesday, 2 July, 2013 5:03 PM
To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>
Subject: Re: [cross-project-issues-dev] 6 month release cycle

The schedule you propose is interesting Doug. Two things stand out -- Your december release only has a one SR. (There is no 8.3.2). The second thing is that you plan on maintaining your June (Kepler) contribution in Feb (Kepler SR2). This is fine, but this is the opposite of what others have done. EGit (and Mylyn too, I think) have released new versions with the SRs. I'm not going judge what's better, but I don't like the fact that they are different.

For example, the February 2014 will potentially have the latest and greatest EGit and a maintenance release of CDT after a new release was just announced. Combine that with the milestone stream that will undoubtedly be moving forward and our users will be hit with a confusing set of available sites from which to find their software. Also, what version of the CDT will be available in the MarketPlace next February?

I'm not picking on anybody here. I think this demonstrates that we need to do something regarding multiple releases per year, and I'm doing my best do understand the different constraints we have.

Cheers,
Ian

On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer <***@qnx.com<mailto:***@qnx.com>> wrote:
Thanks Ian, to answer your questions:

We do expect both releases to be the same quality and vendors will build on both, especially those vendors who need and are likely contributing the new features.

We would build the mid-term release on the June platform. Although, we would love it if the platform released on the same cadence since a lot of what we need requires changes to both (project/build, debug/launch). Not to mention any serious contribution to cleaning up the Eclipse Platform UI to improve look and workflows that would benefit everyone, but that's a whole other set of issues.

Both releases require their own ramp down so I'm not sure the M's would line up with the train properly. But I haven't looked at that yet.

We do acknowledge that we need to spin the Eclipse C/C++ IDE package every six months as well to ensure our objective of getting users the new features faster is met. And the marketing along with that would certainly help get the word out that a new release is available.

From: Ian Bull <***@eclipsesource.com<mailto:***@eclipsesource.com>>
Reply-To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>
Date: Tuesday, 2 July, 2013 4:08 PM
To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>

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

One of the things we need to understand is what do we want from a release train?

1. Is it simply a release of the latest and greatest stuff Eclipse has?
2. Is it a set of plugins / components that are known to 'work together'?
3. Is it a co-ordinated marketing exercise?
4. Is it a snap-shot in time of what we have?
5. Is it something else?

There is nothing wrong with components doing their own release and coming together 1+2 times a year (release plus SRs). In this case the latest and greatest are in the SR0, SR1 & SR2. We could also approach this from a two-stream perspective. Latest and greatest is in the Milestones, and the SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't think we should mix & match approaches.

I'm sure with 71 projects in the release train, we'll arrive at 71 different meanings for the train.

Doug, in the case of CDT, could you consider M4 & M7 your 'releases' (after a few rounds of RCs of course)? What version of the platform do you want for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you expect / need marketing support for both releases? Do you expect both releases to be of the same quality (will vendors build on both)?

Just a few more questions to hopefully help drive the discussion :-)

Cheers,
Ian

On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko <***@sonatype.com<mailto:***@sonatype.com>> wrote:
I agree, one year is way too long. I am not even sure 6 months is often
enough. We had three m2e releases between Juno and Kepler, and I
consider m2e mature, (relatively) low-activity project. At the same
time, I never use R builds myself, I always use M-builds as primary
development environment for my $DAY_JOB. I don't suggest we do
full-blown release every 6 weeks, but maybe there is a way to elevate
perceived status of M builds such that users are more comfortable using
them.

--
Regards,
Igor

On 2013-07-02 11:30 PM, Doug Schaefer wrote:
Hey gang,

We have a discussion going in the CDT community and we are currently
planning out how to achieve a 6 month release cycle. The feeling is that
we need to get new features out faster to our users. The year long wait
we currently have is making releases sluggish and I fear it's slowing
down growth in our community. A 6 month cycle should infuse us with a
little more energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our
larger Eclipse community thought it might be a good idea for other
projects at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and
everything, I thought we should bring that to a greater audience and see
what other projects thought and whether it's something we should bring
to the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream
during the year, but bringing things together more often might be a help
to many others. But I'd like to hear your thoughts on that.

Doug.

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Doug Schaefer

2013-07-03 15:33:02 UTC

I wonder, for those companies that want stability, should they focus on
the LTS program where old releases are maintained for long periods of time.

I'm of the opinion that the entire stack needs new feature development, at
least on the IDE side. We are falling behind the competition and my
thinking and hope is that releasing more often would help energize the
community.

On 13-07-03 6:10 AM, "Ed Merks" <***@gmail.com> wrote:

>Releasing more often sounds like a good thing in principle and of course
>projects are free to do so as they wish. One major concern I'd have
>about the release train itself releasing more often is the long ramp
>down cycle appearing twice as often per year. Of course the M/RC phase
>would need to be shorted, but then the question is, why is it currently
>so long? I expect the answer if to provide quality and stability, so
>would that inevitably suffer as a result? That would be a bad thing...
>
>Another question we must ask is what's best for the consumers/adopters?
>On the one hand, I imagine for projects with very active feature
>development, many of their consumers do want the latest and greatest as
>often as possible. On the other hand, I also imagine that a great many
>commercial adopters see quality and stability as their primary criteria
>for adoption and hence see more value in SR1 and SR2 releases of a
>stable base that's focused primarily on quality improvements compared to
>all the new feature development, which is almost inevitably associated
>with lower quality.
>
>
>
>On 03/07/2013 11:44 AM, Krzysztof Daniel wrote:
>> For Eclipse as a product it is definitely good to have releases more
>> often. It will lower the entry barrier (patches could find a way in the
>> release in less then a year), and will attract new contributors.
>>
>> BUT at the same time there is Eclipse as a platform, with API
>> compatibility, with service releases and specific change management
>> policies, which is totally different from the Eclipse-As-A-Product.
>>
>> So, maybe the key point is that there is a need for two lines:
>> - release train, kept as it is currently
>> - rolling release - it is a product. rather for users then for
>> developers. New API and features can be withdrawn.
>>
>>
>>
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-***@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Mike Milinkovich

2013-07-03 15:44:35 UTC

> I wonder, for those companies that want stability, should they focus on
the LTS
> program where old releases are maintained for long periods of time.

The LTS program is in no way intended to be a replacement for the
simultaneous release.

Doug Schaefer

2013-07-03 15:59:03 UTC

I'm not certain I implied "replacement".

It's the same problem if certain people want changes past SR-2 of any
given release. They find their own answers which unfortunately currently
involves forking. And I assumed, maybe mistakenly, that LTS would help
address those needs.

But yes, this problem becomes bigger with more frequent releases. There
would be less incentive to even do an SR-2 unless there is pull and
contribution by the community to make it happen.

On the flip side, we need to evaluate the benefits of more frequent
releases to see if it's worth it.

On 13-07-03 11:44 AM, "Mike Milinkovich" <***@eclipse.org>
wrote:

>
>> I wonder, for those companies that want stability, should they focus on
>the LTS
>> program where old releases are maintained for long periods of time.
>
>The LTS program is in no way intended to be a replacement for the
>simultaneous release.
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-***@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Mike Milinkovich

2013-07-03 16:53:31 UTC

> On the flip side, we need to evaluate the benefits of more frequent
releases to
> see if it's worth it.

Completely agree. My assumption is that some projects will want to ship more
often, and some will not. We have a large community, and one size rarely
fits all. A strategy that can accommodate differing requirements will be
necessary.

Jesse McConnell

2013-07-03 17:15:11 UTC

Just wondering here...

but since LTS has the a goal of having a set of set points in time (the
existing releases) that is maintained into the future, doesn't it make
sense to have LTS be the primary stakeholder for the
entire simultaneous release concept (maybe they are?)

and then if, as Doug is calling for here, there was interest in a more fast
moving, ideally generally bug free but sometimes glitchy IDE experience
then folks can download and update their editor based on that stream? And
have a durable update repository that isn't getting smoked, renamed, or
what have you that people can just use for years on end. A bit like how
ubuntu lets you have your stable and unstable streams that you can keep
updated from

As for version resolution...I thought one of the points of osgi was to
allow multiple runtime versions of stuff to coexist so from a repository
perspective, let them update whatever they want and downstream projects
that trust their upstreams can have open version ranges and those that
don't can take a more deliberate approach.

I am aware I am probably trivializing much of the osgi experience there,
but really...from a users perspective of Eclipse (which I am speaking from)
I would like to just be able to flip a switch in the IDE and have it notify
me of updates, download in the background and either update automagically
or restart the IDE as needed and not care about adding p2 update repo this
for that thing or download Milestone X or Y or whatever...

cheers,
jesse

--
jesse mcconnell
***@gmail.com

On Wed, Jul 3, 2013 at 11:53 AM, Mike Milinkovich <
***@eclipse.org> wrote:

>
> > On the flip side, we need to evaluate the benefits of more frequent
> releases to
> > see if it's worth it.
>
> Completely agree. My assumption is that some projects will want to ship
> more
> often, and some will not. We have a large community, and one size rarely
> fits all. A strategy that can accommodate differing requirements will be
> necessary.
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

Mike Milinkovich

2013-07-03 17:23:04 UTC

> but since LTS has the a goal of having a set of set points in time (the existing
> releases) that is maintained into the future, doesn't it make sense to have LTS
> be the primary stakeholder for the entire simultaneous release concept (maybe
> they are?)

The Planning Council is currently responsible for defining and running the simultaneous release process.

LTS currently relies upon the existence of a simultaneous release as its starting point. The LTS working group would be a very poor replacement for the Planning Council in running the simultaneous release. For example, one of the major features of the Planning Council is that it has representation on it from each of the PMCs. The LTS working group steering committee does not.

Jesse McConnell

2013-07-03 17:30:41 UTC

> LTS currently relies upon the existence of a simultaneous release as its
> starting point. The LTS working group would be a very poor replacement for
> the Planning Council in running the simultaneous release. For example, one
> of the major features of the Planning Council is that it has representation
> on it from each of the PMCs. The LTS working group steering committee does
> not.
>
>
ok, fair enough...but if the LTS has been investing so much time and effort
into building a process for being able to release updates
to simultaneous releases, will they assume that burden from the Planning
Council eventually? Will that effort be rolled back into the simultaneous
release process that the Planning Council currently takes care of?

maybe a slight off topic, if so my apologies

jesse

>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

Ed Willink

2013-07-03 17:50:55 UTC

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Jesse<br>
<br>
The true nature of the LTS has been very poorly disseminated with
the result that everyone is very confused. At EclipseCon France I
think I succeeded in getting to the bottom of my mis-expectations.<br>
<br>
a) The LTS will not provide any further releases. i.e. no SR3, SR4,
SR5 etc.<br>
b) The LTS provides no publicly accessible repositories for fixes<br>
c) The original committers have no commit rights for LTS activities<br>
(NB this is right: maintaining code with paranoid stability requires
a very different mind-set to developing code).<br>
<br>
Rather<br>
<br>
a) The LTS coordinates maintenance teams to provide legacy fixes<br>
b) All fixes are publicly available via Bugzilla<br>
c) LTS builds will be proprietary and just a pick and mix of those
bug fixes that are important to the company doing the build<br>
<br>
For comparison.<br>
<br>
Any company is able to create a proprietary Eclipse release today
and charge customers for it. This is exactly what will happen in
LTS. The difference/improvement is that those companies interested
in having in-house LTS releases pool their efforts to fix legacy
bugs and make those fixes available individually.<br>
<br>
Regards<br>
<br>
Ed Willink<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/07/2013 18:30, Jesse McConnell
wrote:<br>
</div>
<blockquote
cite="mid:CAPHPUs+9H=46wwtsc4OqHAKc2MzhH7m+WsvEUF6N+***@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
LTS currently relies upon the existence of a simultaneous
release as its starting point. The LTS working group would
be a very poor replacement for the Planning Council in
running the simultaneous release. For example, one of the
major features of the Planning Council is that it has
representation on it from each of the PMCs. The LTS
working group steering committee does not.<br>
<div class="HOEnZb">
<div class="h5"><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div style="">ok, fair enough...but if the LTS has been
investing so much time and effort into building a process
for being able to release updates
to simultaneous releases, will they assume that burden
from the Planning Council eventually? Will that effort be
rolled back into the simultaneous release process that the
Planning Council currently takes care of?</div>
<div style=""><br>
</div>
<div style="">maybe a slight off topic, if so my apologies</div>
<div style=""><br>
</div>
<div style="">jesse</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">
<br>
_______________________________________________<br>
cross-project-issues-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cross-project-issues-***@eclipse.org">cross-project-issues-***@eclipse.org</a><br>
<a moz-do-not-send="true"
href="https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev"
target="_blank">https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cross-project-issues-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cross-project-issues-***@eclipse.org">cross-project-issues-***@eclipse.org</a>
<a class="moz-txt-link-freetext" href="https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev">https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<p class="" avgcert""="" color="#000000" align="left">No virus
found in this message.<br>
Checked by AVG - <a moz-do-not-send="true"
href="http://www.avg.com">www.avg.com</a><br>
Version: 2013.0.3345 / Virus Database: 3204/6461 - Release Date:
07/03/13</p>
</blockquote>
<br>
</body>
</html>

Mike Milinkovich

2013-07-03 17:55:47 UTC

> ok, fair enough...but if the LTS has been investing so much time and effort into
> building a process for being able to release updates to simultaneous releases,
> will they assume that burden from the Planning Council eventually?

No, not that I am aware of. As far as I am concerned, LTS is solving quite a different problem.

> Will that effort be rolled back into the simultaneous release process that the
> Planning Council currently takes care of?

At this point in time, the LTS working group is still very much in start-up mode. They're still figuring out how to do the builds and manage the processes.

My advice is that any variant of the thought that somehow LTS will allow change to the simultaneous release process is wrong for at least the next year or two. I won't say never, but I certainly don't see it within any reasonable planning horizon.

> maybe a slight off topic, if so my apologies

No problem at all.

For the record, I _like_ the idea of trying to accelerate our releases to encourage more innovation and participation. But there are lots of moving parts, requirements, and expectations which need to be satisfied. And very limited resources to do them. As but one example, our entire community lean heavily on the time and personal commitment of David Williams and Markus Knauer. Asking them to do more does not seem reasonable. Perhaps this conversation will spur others to step forward to help.

Doug Schaefer

2013-07-03 16:28:56 UTC

How often do the Eclipse packages get build and tested and what appears on
the Eclipse download page?

On 13-07-03 12:02 PM, "Konstantin Komissarchik"
<***@oracle.com> wrote:

>Glad to see interest in my frequent aggregation proposal. To answer some
>of
>the questions that were raised...
>
>1. Monthly releases sounds rather too frequent. Doesn't leave a lot of
>room
>for milestones or IP team to do their work.
>
>Projects would release at whatever pace makes sense to them, set their own
>schedules and leave room for IP team to do their work. Some would continue
>to release yearly, some would be on a six month cycle, some would release
>even more frequently. The aggregation stream would only accept a finished
>release.
>
>In fact, given enough automation, the aggregation can become continuous.
>Suppose that instead of the current system where projects edit stuff in
>Git,
>there is a portal where projects contribute their release. Verification
>runs
>automatically, if it fails, the contribution is rejected. No more missing
>about.html files! The tool can also be available on "verify only" basis
>for
>projects wishing to check their release candidates.
>
>2. What happens if there is a dependency conflict? For instance, if GEF
>pushes a new release, but the contributed GMF release still depends on the
>old version.
>
>We would very likely need to allow multiple versions in the repository for
>frequent aggregation to work. Perhaps only the latest version is
>categorized.
>
>3. Should the aggregated repository be verified?
>
>Yes. The primary value of the aggregated repository is that there is a
>version of each component that can be installed together. If we don't
>verify
>at aggregation time, we will lose that feature. However, with multiple
>versions being present, the verification would need to be different.
>Instead
>of verifying if everything can be installed together, it should verify if
>a
>solution exists such that at least one version of each component can be
>installed with everything else.
>
>4. What about LTS and others who want more stability. Do we still need the
>current release train for that?
>
>Not really. Let's call what I've described the latest stream.
>Periodically,
>the latest stream can be branched to create a stable stream of a given
>vintage. Projects can still contribute to the stable stream, but the rules
>are different (stricter). On the opposite end, we could also have a dev
>stream, where projects can contribute their latest milestone builds,
>integration builds, etc.
>
>5. What would I build against?
>
>Projects should be tracking the release plans of their dependencies and
>build directly against the repositories published by their dependencies.
>Building against any aggregation stream is risky since you never know
>which
>version you are building against and you lose ability to reproduce your
>build.
>
>Thanks,
>
>- Konstantin
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-***@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Konstantin Komissarchik

2013-07-03 19:48:09 UTC

Successful aggregation would trigger packages build. Different packages
should be able to build in parallel. The new repo and packages are pushed
out on the download site at the end of the monthly cycle.

- Konstantin

-----Original Message-----
From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Doug
Schaefer
Sent: Wednesday, July 03, 2013 9:29 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

How often do the Eclipse packages get build and tested and what appears on
the Eclipse download page?

On 13-07-03 12:02 PM, "Konstantin Komissarchik"
<***@oracle.com> wrote:

>Glad to see interest in my frequent aggregation proposal. To answer
>some of the questions that were raised...
>
>1. Monthly releases sounds rather too frequent. Doesn't leave a lot of
>room for milestones or IP team to do their work.
>
>Projects would release at whatever pace makes sense to them, set their
>own schedules and leave room for IP team to do their work. Some would
>continue to release yearly, some would be on a six month cycle, some
>would release even more frequently. The aggregation stream would only
>accept a finished release.
>
>In fact, given enough automation, the aggregation can become continuous.
>Suppose that instead of the current system where projects edit stuff in
>Git, there is a portal where projects contribute their release.
>Verification runs automatically, if it fails, the contribution is
>rejected. No more missing about.html files! The tool can also be
>available on "verify only" basis for projects wishing to check their
>release candidates.
>
>2. What happens if there is a dependency conflict? For instance, if GEF
>pushes a new release, but the contributed GMF release still depends on
>the old version.
>
>We would very likely need to allow multiple versions in the repository
>for frequent aggregation to work. Perhaps only the latest version is
>categorized.
>
>3. Should the aggregated repository be verified?
>
>Yes. The primary value of the aggregated repository is that there is a
>version of each component that can be installed together. If we don't
>verify at aggregation time, we will lose that feature. However, with
>multiple versions being present, the verification would need to be
>different.
>Instead
>of verifying if everything can be installed together, it should verify
>if a solution exists such that at least one version of each component
>can be installed with everything else.
>
>4. What about LTS and others who want more stability. Do we still need
>the current release train for that?
>
>Not really. Let's call what I've described the latest stream.
>Periodically,
>the latest stream can be branched to create a stable stream of a given
>vintage. Projects can still contribute to the stable stream, but the
>rules are different (stricter). On the opposite end, we could also have
>a dev stream, where projects can contribute their latest milestone
>builds, integration builds, etc.
>
>5. What would I build against?
>
>Projects should be tracking the release plans of their dependencies and
>build directly against the repositories published by their dependencies.
>Building against any aggregation stream is risky since you never know
>which version you are building against and you lose ability to
>reproduce your build.
>
>Thanks,
>
>- Konstantin
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-***@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Stephan Herrmann

2013-07-03 17:48:36 UTC

> Ed Merks<***@gmail.com> wrote
> Another question we must ask is what's best for the consumers/adopters?
> ... On the other hand, I also imagine that a great many
> commercial adopters see quality and stability as their primary criteria
> for adoption and hence see more value in SR1 and SR2 releases of a
> stable base that's focused primarily on quality improvements compared to
> all the new feature development, which is almost inevitably associated
> with lower quality.

I strongly second this point: for people around me SR2 is the most valuable
release. That's the release they feel to be stable enough for production.
The quality of any SR2 is only possible by fixing bugs against R and SR1
and introducing *No-New-Bugs*, to the degree humanly possible.
Any admitting new features into SR1/2 compromises this quality.
If we stop building real SR1/2 we throw away an essential asset.

I'd expect that any projects that don't use a maintenance branch along the
R-SR1-SR2 stream, should simply contribute their R content to the SR1/2
aggregations.

If on top of that, we have the energy to create releases more frequently: fine,
but for a stabilized SR2 I believe the 1-year cycle is actually good.

my 2c,
Stephan

Doug Schaefer

2013-07-03 20:38:17 UTC

Agree on David and Markus's time. These guys make the releases happen and
are heavily under appreciated and over stressed.

But it is quite scary we're relying on individuals performing manual tasks
to get the releases out. I hope that we can automate more of what they do.
The beauty of Maven/Tycho/Hudson is that you can automate everything from
source to download pages. We talk of the big red button, it would be great
if that's all it was.

D

On 13-07-03 1:55 PM, "Mike Milinkovich" <***@eclipse.org>
wrote:

>
>> ok, fair enough...but if the LTS has been investing so much time and
>>effort into
>> building a process for being able to release updates to simultaneous
>>releases,
>> will they assume that burden from the Planning Council eventually?
>
>No, not that I am aware of. As far as I am concerned, LTS is solving
>quite a different problem.
>
>> Will that effort be rolled back into the simultaneous release process
>>that the
>> Planning Council currently takes care of?
>
>At this point in time, the LTS working group is still very much in
>start-up mode. They're still figuring out how to do the builds and manage
>the processes.
>
>My advice is that any variant of the thought that somehow LTS will allow
>change to the simultaneous release process is wrong for at least the next
>year or two. I won't say never, but I certainly don't see it within any
>reasonable planning horizon.
>
>> maybe a slight off topic, if so my apologies
>
>No problem at all.
>
>For the record, I _like_ the idea of trying to accelerate our releases to
>encourage more innovation and participation. But there are lots of moving
>parts, requirements, and expectations which need to be satisfied. And
>very limited resources to do them. As but one example, our entire
>community lean heavily on the time and personal commitment of David
>Williams and Markus Knauer. Asking them to do more does not seem
>reasonable. Perhaps this conversation will spur others to step forward to
>help.
>
>
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-***@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Jesse McConnell

2013-07-03 20:50:26 UTC

> But it is quite scary we're relying on individuals performing manual tasks
> to get the releases out. I hope that we can automate more of what they do.
> The beauty of Maven/Tycho/Hudson is that you can automate everything from
> source to download pages. We talk of the big red button, it would be great
> if that's all it was.
>
>
Agreed, which was the lionshare of intent behind my questions regarding LTS
assuming some of that role :)

cheers,
jesse

> D
>
> On 13-07-03 1:55 PM, "Mike Milinkovich" <***@eclipse.org>
> wrote:
>
> >
> >> ok, fair enough...but if the LTS has been investing so much time and
> >>effort into
> >> building a process for being able to release updates to simultaneous
> >>releases,
> >> will they assume that burden from the Planning Council eventually?
> >
> >No, not that I am aware of. As far as I am concerned, LTS is solving
> >quite a different problem.
> >
> >> Will that effort be rolled back into the simultaneous release process
> >>that the
> >> Planning Council currently takes care of?
> >
> >At this point in time, the LTS working group is still very much in
> >start-up mode. They're still figuring out how to do the builds and manage
> >the processes.
> >
> >My advice is that any variant of the thought that somehow LTS will allow
> >change to the simultaneous release process is wrong for at least the next
> >year or two. I won't say never, but I certainly don't see it within any
> >reasonable planning horizon.
> >
> >> maybe a slight off topic, if so my apologies
> >
> >No problem at all.
> >
> >For the record, I _like_ the idea of trying to accelerate our releases to
> >encourage more innovation and participation. But there are lots of moving
> >parts, requirements, and expectations which need to be satisfied. And
> >very limited resources to do them. As but one example, our entire
> >community lean heavily on the time and personal commitment of David
> >Williams and Markus Knauer. Asking them to do more does not seem
> >reasonable. Perhaps this conversation will spur others to step forward to
> >help.
> >
> >
> >
> >_______________________________________________
> >cross-project-issues-dev mailing list
> >cross-project-issues-***@eclipse.org
> >https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

Pascal Rapicault

2013-07-03 21:03:05 UTC

This was also the reason why I was suggesting that those new repos were not validated so we did not have to take on somebody else's time and it could be a simple mirror repo. I've been doing a similar work internally at Ericsson and automating most of it, but the handling of the b3 aggregation file is sometimes not that trivial (nothing against the tool but rather the dependencies of the IUs).

As for the packages, I would say that these don't need to be released every time since they require alignment between all the components.

The other thing that I'm wondering is whether we need a release date for this new repo. After all, why not just add project as they become available?

-----Original Message-----
From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Doug Schaefer
Sent: July-03-13 4:38 PM
To: ***@eclipse.org; Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

Agree on David and Markus's time. These guys make the releases happen and are heavily under appreciated and over stressed.

But it is quite scary we're relying on individuals performing manual tasks to get the releases out. I hope that we can automate more of what they do.
The beauty of Maven/Tycho/Hudson is that you can automate everything from source to download pages. We talk of the big red button, it would be great if that's all it was.

D

On 13-07-03 1:55 PM, "Mike Milinkovich" <***@eclipse.org>
wrote:

>
>> ok, fair enough...but if the LTS has been investing so much time and
>>effort into building a process for being able to release updates to
>>simultaneous releases, will they assume that burden from the Planning
>>Council eventually?
>
>No, not that I am aware of. As far as I am concerned, LTS is solving
>quite a different problem.
>
>> Will that effort be rolled back into the simultaneous release process
>>that the Planning Council currently takes care of?
>
>At this point in time, the LTS working group is still very much in
>start-up mode. They're still figuring out how to do the builds and
>manage the processes.
>
>My advice is that any variant of the thought that somehow LTS will
>allow change to the simultaneous release process is wrong for at least
>the next year or two. I won't say never, but I certainly don't see it
>within any reasonable planning horizon.
>
>> maybe a slight off topic, if so my apologies
>
>No problem at all.
>
>For the record, I _like_ the idea of trying to accelerate our releases
>to encourage more innovation and participation. But there are lots of
>moving parts, requirements, and expectations which need to be
>satisfied. And very limited resources to do them. As but one example,
>our entire community lean heavily on the time and personal commitment
>of David Williams and Markus Knauer. Asking them to do more does not
>seem reasonable. Perhaps this conversation will spur others to step
>forward to help.
>
>
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-***@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Ian Bull

2013-07-03 21:42:36 UTC

This is exactly the type of conversation we need to be having. Thanks
Konstantin for the out-of-box thinking and everyone else for great ideas /
feedback. I think no matter what we do, we still need 'service releases' or
multiple streams, but there is nothing here that precludes that.

While I do think most of this could be automated -- including the creation
of the packages -- we need to question if this will inevitably reduce
quality. If packages are just a random collection of everyones latest
stuff, automatically built on a monthly basis, we can't give much (if
any) guarantee about the quality of those integrations. The original
proposal included 'testing the release', but I don't think the package
maintainers can be expected to test each package each month on each
platform.

This type of release also means we can't ramp-down as a group. As soon as
some teams start to stabilize their integrations, someone else
will undoubtedly release something new.

Maybe we can address these issues by having a few of these monthly builds
get promoted as 'Package Releases'.

This is a great time to be having this conversation. Thank-you Doug for
starting it! The planning council is not meeting this month, but I'll
summarize the issues and bring them forward in August (although there are
several PC members who have already commented). In the mean-time, please
keep this conversation going.

Cheers,
Ian

On Wed, Jul 3, 2013 at 2:03 PM, Pascal Rapicault <
***@ericsson.com> wrote:

> This was also the reason why I was suggesting that those new repos were
> not validated so we did not have to take on somebody else's time and it
> could be a simple mirror repo. I've been doing a similar work internally at
> Ericsson and automating most of it, but the handling of the b3 aggregation
> file is sometimes not that trivial (nothing against the tool but rather the
> dependencies of the IUs).
>
> As for the packages, I would say that these don't need to be released
> every time since they require alignment between all the components.
>
> The other thing that I'm wondering is whether we need a release date for
> this new repo. After all, why not just add project as they become available?
>
> -----Original Message-----
> From: cross-project-issues-dev-***@eclipse.org [mailto:
> cross-project-issues-dev-***@eclipse.org] On Behalf Of Doug Schaefer
> Sent: July-03-13 4:38 PM
> To: ***@eclipse.org; Cross project issues
> Subject: Re: [cross-project-issues-dev] 6 month release cycle
>
> Agree on David and Markus's time. These guys make the releases happen and
> are heavily under appreciated and over stressed.
>
> But it is quite scary we're relying on individuals performing manual tasks
> to get the releases out. I hope that we can automate more of what they do.
> The beauty of Maven/Tycho/Hudson is that you can automate everything from
> source to download pages. We talk of the big red button, it would be great
> if that's all it was.
>
> D
>
> On 13-07-03 1:55 PM, "Mike Milinkovich" <***@eclipse.org>
> wrote:
>
> >
> >> ok, fair enough...but if the LTS has been investing so much time and
> >>effort into building a process for being able to release updates to
> >>simultaneous releases, will they assume that burden from the Planning
> >>Council eventually?
> >
> >No, not that I am aware of. As far as I am concerned, LTS is solving
> >quite a different problem.
> >
> >> Will that effort be rolled back into the simultaneous release process
> >>that the Planning Council currently takes care of?
> >
> >At this point in time, the LTS working group is still very much in
> >start-up mode. They're still figuring out how to do the builds and
> >manage the processes.
> >
> >My advice is that any variant of the thought that somehow LTS will
> >allow change to the simultaneous release process is wrong for at least
> >the next year or two. I won't say never, but I certainly don't see it
> >within any reasonable planning horizon.
> >
> >> maybe a slight off topic, if so my apologies
> >
> >No problem at all.
> >
> >For the record, I _like_ the idea of trying to accelerate our releases
> >to encourage more innovation and participation. But there are lots of
> >moving parts, requirements, and expectations which need to be
> >satisfied. And very limited resources to do them. As but one example,
> >our entire community lean heavily on the time and personal commitment
> >of David Williams and Markus Knauer. Asking them to do more does not
> >seem reasonable. Perhaps this conversation will spur others to step
> >forward to help.
> >
> >
> >
> >_______________________________________________
> >cross-project-issues-dev mailing list
> >cross-project-issues-***@eclipse.org
> >https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Mike Milinkovich

2013-07-03 22:11:20 UTC

Just out of curiousity, is there a reason why people keep mentioning
monthly, when there is a long-established 6-week cadence?

Maybe we can address these issues by having a few of these monthly builds
get promoted as 'Package Releases'.

Ian Bull

2013-07-03 22:19:50 UTC

Thanks a good question Mike. Obviously monthly was what Konstantin
originally suggested. I think it's good in that it's forcing us to re-think
some of our assumptions. In the end, if we choose 6 weeks, or 8 times per
year -- with careful consideration to Holidays, etc.. -- that's fine. But
if the use of the term monthly is helping us break some of our mental
road-blocks, than that's a good thing(tm).

Cheers,
Ian

On Wed, Jul 3, 2013 at 3:11 PM, Mike Milinkovich <
***@eclipse.org> wrote:

> ** **
>
> Just out of curiousity, is there a reason why people keep mentioning
> monthly, when there is a long-established 6-week cadence? ****
>
> ** **
>
> Maybe we can address these issues by having a few of these monthly builds
> get promoted as 'Package Releases'. ****
>

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Konstantin Komissarchik

2013-07-03 22:53:46 UTC

In the end game, the exact cadence of aggregation is inconsequential. We
could even start quarterly and ramp up to monthly, since a lot of the work
is still done manually. Once sufficient automation is achieved, aggregation
can happen continuously.

I would not be concerned with the overall quality dropping as the result of
frequent aggregation. Many of the projects are already accustomed to
building and testing with multiple versions of their dependencies, so unless
projects fail to track the release plans of their dependencies, there
shouldn't be too many issues. I actually expect the perceived quality to
rise, because a bug fix that slipped through can be fixed and delivered much
quicker than with the current approach.

- Konstantin

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Ian Bull
Sent: Wednesday, July 03, 2013 3:20 PM
To: Mike Milinkovich
Cc: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

Thanks a good question Mike. Obviously monthly was what Konstantin
originally suggested. I think it's good in that it's forcing us to re-think
some of our assumptions. In the end, if we choose 6 weeks, or 8 times per
year -- with careful consideration to Holidays, etc.. -- that's fine. But if
the use of the term monthly is helping us break some of our mental
road-blocks, than that's a good thing(tm).

Cheers,

Ian

On Wed, Jul 3, 2013 at 3:11 PM, Mike Milinkovich
<***@eclipse.org> wrote:

Just out of curiousity, is there a reason why people keep mentioning
monthly, when there is a long-established 6-week cadence?

Maybe we can address these issues by having a few of these monthly builds
get promoted as 'Package Releases'.

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Thomas Hallgren

2013-07-04 09:20:07 UTC

On 2013-07-03 23:42, Ian Bull wrote:
>
> While I do think most of this could be automated -- including the creation of the packages -- we need to question if
> this will inevitably reduce quality.

I think quality comes from extensive automated testing and then hands-on usage. A fully automated release process would
of course cover the first. So the question is really, do we want our users to do the hands-on testing for us? That in
turn, begs the question, aren't we doing that already? Assuming that many projects do, then a more frequent release
cycle will actually increase quality, not the opposite. And it shortens the bug-fixing cycle dramatically.

- thomas

Pascal Rapicault

2013-07-04 09:25:51 UTC

I would go even further, are the current packages really tested anyway?
There are probably a couple ppl opening them up to see if things are at the right place but I can't imagine that a heavy testing is done.

-----Original Message-----
From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Thomas Hallgren
Sent: July-04-13 5:20 AM
To: cross-project-issues-***@eclipse.org
Subject: Re: [cross-project-issues-dev] 6 month release cycle

On 2013-07-03 23:42, Ian Bull wrote:
>
> While I do think most of this could be automated -- including the
> creation of the packages -- we need to question if this will inevitably reduce quality.

I think quality comes from extensive automated testing and then hands-on usage. A fully automated release process would of course cover the first. So the question is really, do we want our users to do the hands-on testing for us? That in turn, begs the question, aren't we doing that already? Assuming that many projects do, then a more frequent release cycle will actually increase quality, not the opposite. And it shortens the bug-fixing cycle dramatically.

- thomas

Ed Willink

2013-07-04 09:36:18 UTC

Hi

Good point.

Perhaps a condition of participation in a Package would be contribution
of a very small smoke test plugin that demonstrates that the participant
has some plausible activity after installation. These could form the
basis of an automated package test that would uncover many missing
dependencies.

For instance for OCL, I already have tests that do a minimal amount of
editor liveness testing on an example project, which gives me some
confidence that Xtext is still there in a useable fashion.

Regards

Ed Willink

On 04/07/2013 10:25, Pascal Rapicault wrote:
> I would go even further, are the current packages really tested anyway?
> There are probably a couple ppl opening them up to see if things are at the right place but I can't imagine that a heavy testing is done.
>
> -----Original Message-----
> From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Thomas Hallgren
> Sent: July-04-13 5:20 AM
> To: cross-project-issues-***@eclipse.org
> Subject: Re: [cross-project-issues-dev] 6 month release cycle
>
> On 2013-07-03 23:42, Ian Bull wrote:
>> While I do think most of this could be automated -- including the
>> creation of the packages -- we need to question if this will inevitably reduce quality.
> I think quality comes from extensive automated testing and then hands-on usage. A fully automated release process would of course cover the first. So the question is really, do we want our users to do the hands-on testing for us? That in turn, begs the question, aren't we doing that already? Assuming that many projects do, then a more frequent release cycle will actually increase quality, not the opposite. And it shortens the bug-fixing cycle dramatically.
>
> - thomas
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3345 / Virus Database: 3204/6462 - Release Date: 07/03/13
>
>

Alexey Panchenko

2013-07-04 09:52:08 UTC

Ideally, all the project tests should be executed - using dependencies from
the simultaneous release repository.

Also, some checks of the compiled classes should be made (e.g. load them
all?), to verify that dependencies in the repository are compatible with
those used at compile time.

Regards,
Alex

On Thu, Jul 4, 2013 at 11:36 AM, Ed Willink <***@willink.me.uk> wrote:

> Hi
>
> Good point.
>
> Perhaps a condition of participation in a Package would be contribution of
> a very small smoke test plugin that demonstrates that the participant has
> some plausible activity after installation. These could form the basis of
> an automated package test that would uncover many missing dependencies.
>
> For instance for OCL, I already have tests that do a minimal amount of
> editor liveness testing on an example project, which gives me some
> confidence that Xtext is still there in a useable fashion.
>
> Regards
>
> Ed Willink
>
>
>
> On 04/07/2013 10:25, Pascal Rapicault wrote:
>
>> I would go even further, are the current packages really tested anyway?
>> There are probably a couple ppl opening them up to see if things are at
>> the right place but I can't imagine that a heavy testing is done.
>>
>> -----Original Message-----
>> From: cross-project-issues-dev-*****@eclipse.org<cross-project-issues-dev-***@eclipse.org>[mailto:
>> cross-project-issues-**dev-***@eclipse.org<cross-project-issues-dev-***@eclipse.org>]
>> On Behalf Of Thomas Hallgren
>> Sent: July-04-13 5:20 AM
>> To: cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
>> Subject: Re: [cross-project-issues-dev] 6 month release cycle
>>
>> On 2013-07-03 23:42, Ian Bull wrote:
>>
>>> While I do think most of this could be automated -- including the
>>> creation of the packages -- we need to question if this will inevitably
>>> reduce quality.
>>>
>> I think quality comes from extensive automated testing and then hands-on
>> usage. A fully automated release process would of course cover the first.
>> So the question is really, do we want our users to do the hands-on testing
>> for us? That in turn, begs the question, aren't we doing that already?
>> Assuming that many projects do, then a more frequent release cycle will
>> actually increase quality, not the opposite. And it shortens the bug-fixing
>> cycle dramatically.
>>
>> - thomas
>>
>> ______________________________**_________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>> ______________________________**_________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>
>>
>> -----
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2013.0.3345 / Virus Database: 3204/6462 - Release Date: 07/03/13
>>
>>
>>
> ______________________________**_________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@**eclipse.org<cross-project-issues-***@eclipse.org>
> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>

Mickael Istria

2013-07-04 10:11:46 UTC

On 07/04/2013 11:52 AM, Alexey Panchenko wrote:
> Ideally, all the project tests should be executed - using dependencies
> from the simultaneous release repository.
Projects are free to execute their tests on output of aggregated repo.
The process is technically accessible to any plugin developer:
* Take a target Eclipse (for example M7 with everything installed)
* Install your tests in this target Eclipse
* Use Eclipse test application to run automatically your tests on this
platform (./eclipse -application org.eclipse.test.uitestapplication ....)

IMO, it's the responsability of the project to run those tests, not
another step for the aggregation process. This could be a new
requirement to signoff before the simultaneous release (By M7 with
current yearly approach): "Run project tests on a full execution
environment".
--
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>

Pascal Rapicault

2013-07-04 10:34:27 UTC

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.
What I'm more concerned about is the running the tests of the lower level project in the presence in an install that contains the higher level ones. For example run the platform tests with egit and wtp installed.

From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Mickael Istria
Sent: July-04-13 6:12 AM
To: cross-project-issues-***@eclipse.org
Subject: Re: [cross-project-issues-dev] 6 month release cycle

On 07/04/2013 11:52 AM, Alexey Panchenko wrote:
Ideally, all the project tests should be executed - using dependencies from the simultaneous release repository.
Projects are free to execute their tests on output of aggregated repo. The process is technically accessible to any plugin developer:
* Take a target Eclipse (for example M7 with everything installed)
* Install your tests in this target Eclipse
* Use Eclipse test application to run automatically your tests on this platform (./eclipse -application org.eclipse.test.uitestapplication ....)

IMO, it's the responsability of the project to run those tests, not another step for the aggregation process. This could be a new requirement to signoff before the simultaneous release (By M7 with current yearly approach): "Run project tests on a full execution environment".
--
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>

Mickael Istria

2013-07-04 10:43:22 UTC

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>

Igor Fedorenko

2013-07-04 11:15:01 UTC

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

Denis Roy

2013-07-04 13:41:37 UTC

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

Ed Willink

2013-07-04 10:26:32 UTC

Hi

On 04/07/2013 10:52, Alexey Panchenko wrote:
> Ideally, all the project tests should be executed - using dependencies
> from the simultaneous release repository.

NO. Most project tests are to do with project functionality and so
should be guaranteed passes on an aggregation. Dependencies on other
projects should tested by the ptojects own build. The aggregation tests
need only focus on overall integration whereby P2 compromises what is
available leading to a completely missing bundle. If every project test
ran, the aggregation builds would take forever.
>
> Also, some checks of the compiled classes should be made (e.g. load
> them all?), to verify that dependencies in the repository are
> compatible with those used at compile time.
>
That's what the smoke test should do. Activate enough classes from
enough places to demonstrate no CNFEs.

Regards

Ed Willink

Pascal Rapicault

2013-07-04 10:31:52 UTC

>The aggregation tests need only focus on overall integration whereby P2 compromises what is available leading to a completely missing bundle.
p2 will never decide to *not* install a bundle just to get the rest to install... Do you have a scenario where this happen?
The remediation is about updating or uninstalling the elements that have been explicitely installed and it is *not* about tweaking the ranges that are in the metadata.

-----Original Message-----
From: cross-project-issues-dev-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Ed Willink
Sent: July-04-13 6:27 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

Hi

On 04/07/2013 10:52, Alexey Panchenko wrote:
> Ideally, all the project tests should be executed - using dependencies
> from the simultaneous release repository.

NO. Most project tests are to do with project functionality and so should be guaranteed passes on an aggregation. Dependencies on other projects should tested by the ptojects own build. The aggregation tests need only focus on overall integration whereby P2 compromises what is available leading to a completely missing bundle. If every project test ran, the aggregation builds would take forever.
>
> Also, some checks of the compiled classes should be made (e.g. load
> them all?), to verify that dependencies in the repository are
> compatible with those used at compile time.
>
That's what the smoke test should do. Activate enough classes from enough places to demonstrate no CNFEs.

Regards

Ed Willink

Doug Schaefer

2013-07-04 17:56:30 UTC

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

John Arthorne

2013-07-08 18:37:01 UTC

There has been some great discussion here, and some similar ideas to what
were discussed at the Planning Council F2F earlier this year [1]. Many
Eclipse projects are already doing 3-6 or even more releases a year, so
ideas about how to bring those together and get them out to end-users are
worth talking about. My current view is that we are already slowly
evolving from the "one feature release a year" to three release windows a
year (June, September, February). Some projects use those release windows
for maintenance, others use them for new "feature releases". This makes
sense as our projects are very diverse and the needs of different
projects' consumer communities differ. We discussed this briefly in last
week's Eclipse Project PMC and we currently think the 1+2 rhythm currently
works well for the Platform project, but there is nothing stopping other
projects from adopting a more frequent feature release cadence. Maybe we
need to acknowledge this reality and change the names of the
September/February releases to indicate they are not purely service
releases (and yes, Spring/Summer/Fall are not the right names either).

As for the specific idea of a December release, I admit I'm not wild on
it. The last couple of weeks of December is really a poor time to be
shipping software, both from perspective of people being on holidays, and
from a marketing perspective it's hard to get anyone's attention at that
time of year. Perhaps a bit more achievable is moving the September
release to end of October, to make it a consistent pattern of release
windows every four months. That also lines up nicely around EclipseCon
Europe which is a big marketing and education opportunity if you're doing
a release at that time of year. Again, not every project would need to use
these windows for feature releases. A project could make every second
window a feature release and use the in-between ones for maintenance. Or 2
feature releases + 1 maintenance release, etc. Again this is something
projects are already moving towards and it is mainly a matter of
socializing and outreach about what the Sept/Feb releases are doing. The
next natural step from 3 release windows a year would be quarterly
releases but this is a bigger step for projects and the community to make.

Konstantin's thought experiment about continuous aggregation is also
really interesting. The key problem here is workload - our current
aggregation is too error prone, unrepeatable, and time-consuming to add
even more aggregations right now. It currently seems to take several full
days of someone's time to nurse an aggregation through to successful
completion. Part of this can probably be removed through better tooling
and automation, but some of it may be the natural cost of getting so many
millions of lines of fast moving open source code lined up, built, and
tested. I think we need to improve infrastructure+process before we can
increase how often we release aggregated content.

The other question for the continuous aggregation idea is to ask who is
the target audience for it. If the goal is to get new features into the
hands of users more quickly, then I think using the current nearly-monthly
milestone aggregation is the better path. This gets new features out even
faster, and also means that users get exposure to features early enough
that projects can incorporate feedback before it is too late. The
Chrome/Firefox Beta channel concept is very popular with developers - they
are eager to get their hands on new stuff and are often willing to
sacrifice a bit on quality to get it. The Eclipse community is much
smaller but I still think there would be interest if we get the word out
and set the right expectations. Personally I am never using anything older
than the last milestone and overall stability is quite good.

On the other hand if the target audience for continuous aggregation is
commercial adopters, I think it is much less valuable. What commercial
adopters really value is the schedule alignment, and whether there is an
aggregate repository and EPP packages or not is a relatively minor
concern. Anyone building against Eclipse would likely not want to target a
repository that is shifting every month in unpredictable ways - they
generally want to control the timing of adoption by consuming from the
individual repositories of single project releases.

Anyway, that was a bit more verbose and rambling than I intended, but
that's my current input to the discussion...

John

[1]
http://wiki.eclipse.org/Planning_Council/March_24_2013#Release_train_rhythm

From: Doug Schaefer <***@qnx.com>
To: "cross-project-issues-***@eclipse.org"
<cross-project-issues-***@eclipse.org>,
Date: 07/02/2013 03:31 PM
Subject: [cross-project-issues-dev] 6 month release cycle
Sent by: cross-project-issues-dev-***@eclipse.org

Hey gang,

We have a discussion going in the CDT community and we are currently
planning out how to achieve a 6 month release cycle. The feeling is that
we need to get new features out faster to our users. The year long wait we
currently have is making releases sluggish and I fear it's slowing down
growth in our community. A 6 month cycle should infuse us with a little
more energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our
larger Eclipse community thought it might be a good idea for other
projects at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and
everything, I thought we should bring that to a greater audience and see
what other projects thought and whether it's something we should bring to
the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream during
the year, but bringing things together more often might be a help to many
others. But I'd like to hear your thoughts on that.

Doug._______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Konstantin Komissarchik

2013-07-08 19:49:44 UTC

> Konstantin's thought experiment about continuous aggregation is also
really interesting.

> The key problem here is workload - our current aggregation is too error
prone, unrepeatable,

> and time-consuming to add even more aggregations right now. It currently
seems to take

> several full days of someone's time to nurse an aggregation through to
successful completion.

There is no question in my mind that with a bit of automation, continuous
aggregation can be a hands-off operation, taking less effort than what's
being expended today. There are two problems with what we are doing today:

1. New contributions are piled on, aggregation happens, problems are found
and need to be sorted out manually. Meanwhile, aggregation is broken and
more contributions pile on. The solution is to remove direct access to
aggregation metadata and process one contribution at a time. When a
contribution request is made, aggregation is performed. If it fails, the
contribution is rejected and the contributing project gets to figure out
what's wrong without affecting anyone else.

2. Content of contributed repositories changes and some needed repositories
are deleted. The result is inability to reproduce aggregation. The solution
is policy (projects must not contribute mutating repositories to
aggregation) and enforcement (mirroring of contributed repositories). The
mirrors can be purged after a certain period when reproducing aggregation
older than a certain amount of time is no longer necessary.

> The other question for the continuous aggregation idea is to ask who is
the target audience

> for it. If the goal is to get new features into the hands of users more
quickly, then I think using

> the current nearly-monthly milestone aggregation is the better path.

Continuous aggregation doesn't have an audience by itself. You can use
continuous aggregation for everything from five year old maintenance stream
to a nightly development stream. When continuous aggregation is applied to
the latest releases, a key audience is a typical Eclipse user who wants the
latest, but doesn't want to mess with problems associated with running
development builds (milestones). Running with milestones is more common for
developers working on Eclipse plugins than for the broader set of Eclipse
users, since plugin developers already have to track those emerging
milestone as their development target.

- Konstantin

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of John
Arthorne
Sent: Monday, July 08, 2013 11:37 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

There has been some great discussion here, and some similar ideas to what
were discussed at the Planning Council F2F earlier this year [1]. Many
Eclipse projects are already doing 3-6 or even more releases a year, so
ideas about how to bring those together and get them out to end-users are
worth talking about. My current view is that we are already slowly evolving
from the "one feature release a year" to three release windows a year (June,
September, February). Some projects use those release windows for
maintenance, others use them for new "feature releases". This makes sense as
our projects are very diverse and the needs of different projects' consumer
communities differ. We discussed this briefly in last week's Eclipse Project
PMC and we currently think the 1+2 rhythm currently works well for the
Platform project, but there is nothing stopping other projects from adopting
a more frequent feature release cadence. Maybe we need to acknowledge this
reality and change the names of the September/February releases to indicate
they are not purely service releases (and yes, Spring/Summer/Fall are not
the right names either).

As for the specific idea of a December release, I admit I'm not wild on it.
The last couple of weeks of December is really a poor time to be shipping
software, both from perspective of people being on holidays, and from a
marketing perspective it's hard to get anyone's attention at that time of
year. Perhaps a bit more achievable is moving the September release to end
of October, to make it a consistent pattern of release windows every four
months. That also lines up nicely around EclipseCon Europe which is a big
marketing and education opportunity if you're doing a release at that time
of year. Again, not every project would need to use these windows for
feature releases. A project could make every second window a feature release
and use the in-between ones for maintenance. Or 2 feature releases + 1
maintenance release, etc. Again this is something projects are already
moving towards and it is mainly a matter of socializing and outreach about
what the Sept/Feb releases are doing. The next natural step from 3 release
windows a year would be quarterly releases but this is a bigger step for
projects and the community to make.

Konstantin's thought experiment about continuous aggregation is also really
interesting. The key problem here is workload - our current aggregation is
too error prone, unrepeatable, and time-consuming to add even more
aggregations right now. It currently seems to take several full days of
someone's time to nurse an aggregation through to successful completion.
Part of this can probably be removed through better tooling and automation,
but some of it may be the natural cost of getting so many millions of lines
of fast moving open source code lined up, built, and tested. I think we need
to improve infrastructure+process before we can increase how often we
release aggregated content.

The other question for the continuous aggregation idea is to ask who is the
target audience for it. If the goal is to get new features into the hands
of users more quickly, then I think using the current nearly-monthly
milestone aggregation is the better path. This gets new features out even
faster, and also means that users get exposure to features early enough that
projects can incorporate feedback before it is too late. The Chrome/Firefox
Beta channel concept is very popular with developers - they are eager to get
their hands on new stuff and are often willing to sacrifice a bit on quality
to get it. The Eclipse community is much smaller but I still think there
would be interest if we get the word out and set the right expectations.
Personally I am never using anything older than the last milestone and
overall stability is quite good.

On the other hand if the target audience for continuous aggregation is
commercial adopters, I think it is much less valuable. What commercial
adopters really value is the schedule alignment, and whether there is an
aggregate repository and EPP packages or not is a relatively minor concern.
Anyone building against Eclipse would likely not want to target a repository
that is shifting every month in unpredictable ways - they generally want to
control the timing of adoption by consuming from the individual repositories
of single project releases.

Anyway, that was a bit more verbose and rambling than I intended, but that's
my current input to the discussion...

John

[1]
<http://wiki.eclipse.org/Planning_Council/March_24_2013#Release_train_rhythm
>
http://wiki.eclipse.org/Planning_Council/March_24_2013#Release_train_rhythm

From: Doug Schaefer <***@qnx.com>
To: "cross-project-issues-***@eclipse.org"
<cross-project-issues-***@eclipse.org>,
Date: 07/02/2013 03:31 PM
Subject: [cross-project-issues-dev] 6 month release cycle
Sent by: cross-project-issues-dev-***@eclipse.org

_____

Hey gang,

We have a discussion going in the CDT community and we are currently
planning out how to achieve a 6 month release cycle. The feeling is that we
need to get new features out faster to our users. The year long wait we
currently have is making releases sluggish and I fear it's slowing down
growth in our community. A 6 month cycle should infuse us with a little more
energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our
larger Eclipse community thought it might be a good idea for other projects
at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and
everything, I thought we should bring that to a greater audience and see
what other projects thought and whether it's something we should bring to
the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream during
the year, but bringing things together more often might be a help to many
others. But I'd like to hear your thoughts on that.

Doug._______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Mickael Istria

2013-07-09 09:41:21 UTC

On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote:
>
> 1. New contributions are piled on, aggregation happens, problems are
> found and need to be sorted out manually. Meanwhile, aggregation is
> broken and more contributions pile on. The solution is to remove
> direct access to aggregation metadata and process one contribution at
> a time. When a contribution request is made, aggregation is performed.
> If it fails, the contribution is rejected and the contributing project
> gets to figure out what's wrong without affecting anyone else.
>

Seems like using Gerrit to process contributions into aggregator would
help. However, it means that someone has to review and merge this
contributions manually; but if this Gerrit review also triggers a
Jenkins build that validates the aggregation (without publishing it), it
wouldn't be too difficult to maintain as it would spot some errors early
and automatically.

> 2. Content of contributed repositories changes and some needed
> repositories are deleted. The result is inability to reproduce
> aggregation. The solution is policy (projects must not contribute
> mutating repositories to aggregation) and enforcement (mirroring of
> contributed repositories). The mirrors can be purged after a certain
> period when reproducing aggregation older than a certain amount of
> time is no longer necessary.
>

This is closely related to this discussion:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=331385 . I agree that
projects should be forced provide a stable URL with stable content to
aggregator. It should be a requirement of the release train.
If we use Gerrit and reviews to contribute to aggregator, it's would be
a criterion for vetoing a contribution.

--
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>

Dennis Hübner

2013-07-09 09:59:31 UTC

Am 09.07.2013 um 11:41 schrieb Mickael Istria:

> On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote:
>>
>> 1. New contributions are piled on, aggregation happens, problems are found and need to be sorted out manually. Meanwhile, aggregation is broken and more contributions pile on. The solution is to remove direct access to aggregation metadata and process one contribution at a time. When a contribution request is made, aggregation is performed. If it fails, the contribution is rejected and the contributing project gets to figure out whats wrong without affecting anyone else.
>
> Seems like using Gerrit to process contributions into aggregator would help. However, it means that someone has to review and merge this contributions manually; but if this Gerrit review also triggers a Jenkins build that validates the aggregation (without publishing it), it wouldn't be too difficult to maintain as it would spot some errors early and automatically.

A lot of failed builds were caused by missing (suddenly deleted/disappeared) artifacts not by incoming model changes.
So autovalidation by Jenkins will probably prevent maintainers to submit a patch which fixes, but depends on the broken master state.
So IMHO gerrit would not eliminate the problem in the whole, but can probably make the maintenance not that easy

Best regards,
Dennis Hübner

Xtext Commiter / Build Engineer

Mobile: +49 (0) 151 / 17 39 67 07
Telefon: +49 (0) 431 / 990 268 70
Fax: +49 (0) 431 / 990 268 72

itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

Mickael Istria

2013-07-09 10:20:46 UTC

On 07/09/2013 11:59 AM, Dennis Hübner wrote:
> A lot of failed builds were caused by missing (suddenly
> deleted/disappeared) artifacts not by incoming model changes.
> So autovalidation by Jenkins will probably prevent maintainers to
> submit a patch which fixes, but depends on the broken master state.
> So IMHO gerrit would not eliminate the problem in the whole, but can
> probably make the maintenance not that easy
That's right, but the value of code review is mainly in educating
(mid-term/long-term benefit). Currently, it seems like (some) people
push stuff to aggregator without understanding that this needs to be
stable content. Having a code review phase saying: "I'm ok to merge this
in aggregator if you confirm the submission conforms to Simultaneous
Release requirements and that it is a stable URL that won't disappear"
would probably help, on medium to long term, to avoid bad contributions
to aggregator and then to make build more stable.
When I was a younger contributor to Eclipse, i did contribute some stuff
to the release train which broke some builds. It happened because I did
not understand enough the requirements and workflow of the aggregation.
I guess it's the case for some other contributors. Code review would
have prevented me from breaking build.

Time to review such a patch: a few minutes.
Time to notice a build is broken + to route error to the right
contributor + to disable the contribution + to rebuild: a few hours.
--
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>

Konstantin Komissarchik

2013-07-09 15:32:23 UTC

> A lot of failed builds were caused by missing (suddenly
deleted/disappeared) artifacts

> not by incoming model changes.

> So autovalidation by Jenkins will probably prevent maintainers to submit a
patch which

> fixes, but depends on the broken master state.

Item #2 from my writeup (mirroring of contributions) would ensure
aggregation cannot be affected by deleted or changed repositories.

Auto validation does not prevent a fix from being contributed if somehow
aggregation does break. By definition, a broken base state plus a good fix
results in passing aggregation. Auto validation does prevent unrelated
contributions from going through in a broken base state, but thats a good
thing, since the broken base state needs to be addressed first.

- Konstantin

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Dennis
Hübner
Sent: Tuesday, July 09, 2013 3:00 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

Am 09.07.2013 um 11:41 schrieb Mickael Istria:

On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote:

1. New contributions are piled on, aggregation happens, problems are found
and need to be sorted out manually. Meanwhile, aggregation is broken and
more contributions pile on. The solution is to remove direct access to
aggregation metadata and process one contribution at a time. When a
contribution request is made, aggregation is performed. If it fails, the
contribution is rejected and the contributing project gets to figure out
whats wrong without affecting anyone else.

Seems like using Gerrit to process contributions into aggregator would help.
However, it means that someone has to review and merge this contributions
manually; but if this Gerrit review also triggers a Jenkins build that
validates the aggregation (without publishing it), it wouldn't be too
difficult to maintain as it would spot some errors early and automatically.

A lot of failed builds were caused by missing (suddenly deleted/disappeared)
artifacts not by incoming model changes.

So autovalidation by Jenkins will probably prevent maintainers to submit a
patch which fixes, but depends on the broken master state.

So IMHO gerrit would not eliminate the problem in the whole, but can
probably make the maintenance not that easy

Best regards,

Dennis Hübner

Xtext Commiter / Build Engineer

Mobile: +49 (0) 151 / 17 39 67 07
Telefon: +49 (0) 431 / 990 268 70
Fax: +49 (0) 431 / 990 268 72

itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

Konstantin Komissarchik

2013-07-09 15:24:21 UTC

I don't see why manual Gerrit reviews would be desirable. Since the only
goal here is to ensure that aggregation doesn't break, a successful
aggregation pass is enough to prove that the contribution is good.

- Konstantin

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Mickael
Istria
Sent: Tuesday, July 09, 2013 2:41 AM
To: cross-project-issues-***@eclipse.org
Subject: Re: [cross-project-issues-dev] 6 month release cycle

On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote:

1. New contributions are piled on, aggregation happens, problems are found
and need to be sorted out manually. Meanwhile, aggregation is broken and
more contributions pile on. The solution is to remove direct access to
aggregation metadata and process one contribution at a time. When a
contribution request is made, aggregation is performed. If it fails, the
contribution is rejected and the contributing project gets to figure out
what's wrong without affecting anyone else.

Seems like using Gerrit to process contributions into aggregator would help.
However, it means that someone has to review and merge this contributions
manually; but if this Gerrit review also triggers a Jenkins build that
validates the aggregation (without publishing it), it wouldn't be too
difficult to maintain as it would spot some errors early and automatically.

2. Content of contributed repositories changes and some needed repositories
are deleted. The result is inability to reproduce aggregation. The solution
is policy (projects must not contribute mutating repositories to
aggregation) and enforcement (mirroring of contributed repositories). The
mirrors can be purged after a certain period when reproducing aggregation
older than a certain amount of time is no longer necessary.

This is closely related to this discussion:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=331385 . I agree that projects
should be forced provide a stable URL with stable content to aggregator. It
should be a requirement of the release train.
If we use Gerrit and reviews to contribute to aggregator, it's would be a
criterion for vetoing a contribution.

--
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>

Mickael Istria

2013-07-09 15:43:26 UTC

On 07/09/2013 05:24 PM, Konstantin Komissarchik wrote:
>
> I don't see why manual Gerrit reviews would be desirable. Since the
> only goal here is to ensure that aggregation doesn't break, a
> successful aggregation pass is enough to prove that the contribution
> is good.
>
A successful aggregation pass is enough to ensure build works once. The
Jenkins Gerrit plugin would provide that.
A human review would help to ensure that the contribution is good
(sustainable URL, stable content, conformance to guidelines).

Code review would decrease the amount of failed aggregation builds
(because bad URLs would have more difficulties to get in) and would make
contributors more aware of what is expected from them.
Code review FTW!
http://www.benlinders.com/2013/the-economics-of-software-quality/ and
http://www.benlinders.com/wp-content/uploads/Business-Benefits-Reviews-Ben-Linders.pdf
--
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>

Konstantin Komissarchik

2013-07-09 15:44:56 UTC

You missed the second half of my writeup.

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Mickael
Istria
Sent: Tuesday, July 09, 2013 8:43 AM
To: cross-project-issues-***@eclipse.org
Subject: Re: [cross-project-issues-dev] 6 month release cycle

On 07/09/2013 05:24 PM, Konstantin Komissarchik wrote:

I don't see why manual Gerrit reviews would be desirable. Since the only
goal here is to ensure that aggregation doesn't break, a successful
aggregation pass is enough to prove that the contribution is good.

A successful aggregation pass is enough to ensure build works once. The
Jenkins Gerrit plugin would provide that.
A human review would help to ensure that the contribution is good
(sustainable URL, stable content, conformance to guidelines).

Code review would decrease the amount of failed aggregation builds (because
bad URLs would have more difficulties to get in) and would make contributors
more aware of what is expected from them.
Code review FTW!
http://www.benlinders.com/2013/the-economics-of-software-quality/ and
http://www.benlinders.com/wp-content/uploads/Business-Benefits-Reviews-Ben-L
inders.pdf

--
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>

Krzysztof Daniel

2013-07-08 21:01:08 UTC

On Mon, 2013-07-08 at 14:37 -0400, John Arthorne wrote:
> [...] we currently think the 1+2 rhythm currently works well for the
> Platform project, [...]

Being an occasional contributor, I can't disagree more.

There is a yearly gap between providing a patch and getting it released.

It means that some projects (like CDT) will ship without a fix for an
annoying issue (and at least one Fedora will be shipped with a bug).

For me it is a wasted time, because the patch could have been verified
in the field (if commiters hadn't had time). And corrected if necessary.

With CBI, it is easy to do an in-house build on demand. This is an
opportunity (inhouse bugfixes may be contributed back) and a threat(it
is easier respin builds than contribute a fix) at the same time.

Not to mention that waiting a year to get a patch released is
*extremely* demotivating. It is almost a show stopper. Eclipse needs
contributors.

I consider "frequent releases" to be a prerequisite to "being open for
contributors".

--
Krzysztof Daniel <***@redhat.com>
Red Hat

Greg Watson

2013-07-16 14:13:40 UTC

While I support more frequent release cycles (PTP release more frequently so it would suit us well), I'd like to also suggest that projects also have more control over the packages available on the download site. In particular, we'd like to be able to update our package with a new build when we bring out a bug fix release so that new users don't need to update the package as soon as they download it. If you're interested in discussing this more, I've opened bug 412864 on this issue.

Greg

On Jul 2, 2013, at 3:30 PM, Doug Schaefer <***@qnx.com> wrote:

> Hey gang,
>
> We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope.
>
> I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too.
>
> Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO.
>
> I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that.
>
> Doug.
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Doug Schaefer

2013-07-16 15:06:34 UTC

+1 We're going to run into this with CDT. We will want to update the package every 6 months as well.

From: Greg Watson <***@computer.org<mailto:***@computer.org>>
Reply-To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>
Date: Tuesday, 16 July, 2013 4:13 PM
To: Cross project issues <cross-project-issues-***@eclipse.org<mailto:cross-project-issues-***@eclipse.org>>
Subject: Re: [cross-project-issues-dev] 6 month release cycle

While I support more frequent release cycles (PTP release more frequently so it would suit us well), I'd like to also suggest that projects also have more control over the packages available on the download site. In particular, we'd like to be able to update our package with a new build when we bring out a bug fix release so that new users don't need to update the package as soon as they download it. If you're interested in discussing this more, I've opened bug 412864 on this issue.

Greg

On Jul 2, 2013, at 3:30 PM, Doug Schaefer <***@qnx.com<mailto:***@qnx.com>> wrote:

Hey gang,

We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that.

Doug.

Ian Skerrett

2013-07-16 18:20:42 UTC

The download page is driven by the output of the EPP project which builds
the packages from the release train repo. A lot of this is automated so I
would suggest any change to the release cycle will also need to include how
we update this workflow.

Ian

From: cross-project-issues-dev-***@eclipse.org
[mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Doug
Schaefer
Sent: July-16-13 11:07 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

+1 We're going to run into this with CDT. We will want to update the package
every 6 months as well.

From: Greg Watson <***@computer.org <mailto:***@computer.org> >
Reply-To: Cross project issues <cross-project-issues-***@eclipse.org
<mailto:cross-project-issues-***@eclipse.org> >
Date: Tuesday, 16 July, 2013 4:13 PM
To: Cross project issues <cross-project-issues-***@eclipse.org
<mailto:cross-project-issues-***@eclipse.org> >
Subject: Re: [cross-project-issues-dev] 6 month release cycle

While I support more frequent release cycles (PTP release more frequently so
it would suit us well), I'd like to also suggest that projects also have
more control over the packages available on the download site. In
particular, we'd like to be able to update our package with a new build when
we bring out a bug fix release so that new users don't need to update the
package as soon as they download it. If you're interested in discussing this
more, I've opened bug 412864 on this issue.

Greg

On Jul 2, 2013, at 3:30 PM, Doug Schaefer <***@qnx.com
<mailto:***@qnx.com> > wrote:

Hey gang,

We have a discussion going in the CDT community and we are currently
planning out how to achieve a 6 month release cycle. The feeling is that we
need to get new features out faster to our users. The year long wait we
currently have is making releases sluggish and I fear it's slowing down
growth in our community. A 6 month cycle should infuse us with a little more
energy, so goes the hope.

I mentioned CDT's plans on twitter and a number of senior members of our
larger Eclipse community thought it might be a good idea for other projects
at Eclipse and maybe for the train itself. And I think so too.

Instead of continuing that discussion on twitter, which is fun and
everything, I thought we should bring that to a greater audience and see
what other projects thought and whether it's something we should bring to
the Planning Council and the rest of the EMO.

I know there are a number of projects already releasing off stream during
the year, but bringing things together more often might be a help to many
others. But I'd like to hear your thoughts on that.

Doug.

Mickael Istria

2013-07-16 18:25:07 UTC

On 07/16/2013 08:20 PM, Ian Skerrett wrote:
>
> The download page is driven by the output of the EPP project which
> builds the packages from the release train repo. A lot of this is
> automated so I would suggest any change to the release cycle will also
> need to include how we update this workflow.
>

Is there any technical or workflow-related reason that would prevent EPP
package from being released more often than release train is ?
--
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>

Pascal Rapicault

2013-07-16 18:43:10 UTC

The fact that all the bundles composing packages are included in the release repo and that the ius for the epp are also there.

On 2013-07-16, at 8:25 PM, Mickael Istria <***@redhat.com> wrote:

> On 07/16/2013 08:20 PM, Ian Skerrett wrote:
>> The download page is driven by the output of the EPP project which builds the packages from the release train repo. A lot of this is automated so I would suggest any change to the release cycle will also need to include how we update this workflow.
>
> Is there any technical or workflow-related reason that would prevent EPP package from being released more often than release train is ?
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Mickael Istria

2013-07-16 19:21:28 UTC

On 07/16/2013 08:43 PM, Pascal Rapicault wrote:
> The fact that all the bundles composing packages are included in the
> release repo and that the ius for the epp are also there.
Ok. I thought that EPP was only a consumer of the release train and that
those flavours of the IDE could be built anytime on top of the repo.
--
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>

72 Replies
1 View
Permalink to this page
Disable enhanced parsing

Thread Navigation

Doug Schaefer 2013-07-02 19:30:47 UTC

Konstantin Komissarchik 2013-07-02 19:39:26 UTC

Doug Schaefer 2013-07-02 19:47:00 UTC

[cross-project-issues-de= ] on behalf of Konstantin Komissarchik [konstantin.kom= ] 1970-01-01 00:00:00 UTC

Igor Fedorenko 2013-07-02 19:49:43 UTC

Doug Schaefer 2013-07-02 19:56:11 UTC

Igor Fedorenko 2013-07-02 20:17:08 UTC

Ian Bull 2013-07-02 20:08:32 UTC

Doug Schaefer 2013-07-02 20:27:51 UTC

Doug Schaefer 2013-07-02 20:28:15 UTC

Ian Bull 2013-07-02 21:03:44 UTC

Konstantin Komissarchik 2013-07-02 21:27:12 UTC

Dennis Hübner 2013-07-03 06:57:28 UTC

Matthias Sohn 2013-07-03 07:22:37 UTC

Henrik Rentz-Reichert 2013-07-03 07:33:57 UTC

Mickael Istria 2013-07-03 08:26:54 UTC

Pascal Rapicault 2013-07-03 09:06:20 UTC

Gunnar Wagenknecht 2013-07-03 12:56:40 UTC

Konstantin Komissarchik 2013-07-03 16:02:47 UTC

Ed Willink 2013-07-03 08:55:29 UTC

Krzysztof Daniel 2013-07-03 09:44:10 UTC

Ed Merks 2013-07-03 10:10:51 UTC

Pascal Rapicault 2013-07-03 09:31:23 UTC

Ed Willink 2013-07-03 09:39:53 UTC

Pascal Rapicault 2013-07-03 10:19:33 UTC

Doug Schaefer 2013-07-02 21:12:53 UTC

Doug Schaefer 2013-07-03 15:33:02 UTC

Mike Milinkovich 2013-07-03 15:44:35 UTC

Doug Schaefer 2013-07-03 15:59:03 UTC

Mike Milinkovich 2013-07-03 16:53:31 UTC

Jesse McConnell 2013-07-03 17:15:11 UTC

Mike Milinkovich 2013-07-03 17:23:04 UTC

Jesse McConnell 2013-07-03 17:30:41 UTC

Ed Willink 2013-07-03 17:50:55 UTC

Mike Milinkovich 2013-07-03 17:55:47 UTC

Doug Schaefer 2013-07-03 16:28:56 UTC

Konstantin Komissarchik 2013-07-03 19:48:09 UTC

Stephan Herrmann 2013-07-03 17:48:36 UTC

Doug Schaefer 2013-07-03 20:38:17 UTC

Jesse McConnell 2013-07-03 20:50:26 UTC

Pascal Rapicault 2013-07-03 21:03:05 UTC

Ian Bull 2013-07-03 21:42:36 UTC

Mike Milinkovich 2013-07-03 22:11:20 UTC

Ian Bull 2013-07-03 22:19:50 UTC

Konstantin Komissarchik 2013-07-03 22:53:46 UTC

Thomas Hallgren 2013-07-04 09:20:07 UTC

Pascal Rapicault 2013-07-04 09:25:51 UTC

Ed Willink 2013-07-04 09:36:18 UTC

Alexey Panchenko 2013-07-04 09:52:08 UTC

Mickael Istria 2013-07-04 10:11:46 UTC

Pascal Rapicault 2013-07-04 10:34:27 UTC

Mickael Istria 2013-07-04 10:43:22 UTC

Igor Fedorenko 2013-07-04 11:15:01 UTC

Denis Roy 2013-07-04 13:41:37 UTC

Ed Willink 2013-07-04 10:26:32 UTC

Pascal Rapicault 2013-07-04 10:31:52 UTC

Doug Schaefer 2013-07-04 17:56:30 UTC

John Arthorne 2013-07-08 18:37:01 UTC

Konstantin Komissarchik 2013-07-08 19:49:44 UTC

Mickael Istria 2013-07-09 09:41:21 UTC

Dennis Hübner 2013-07-09 09:59:31 UTC

Mickael Istria 2013-07-09 10:20:46 UTC

Konstantin Komissarchik 2013-07-09 15:32:23 UTC

Konstantin Komissarchik 2013-07-09 15:24:21 UTC

Mickael Istria 2013-07-09 15:43:26 UTC

Konstantin Komissarchik 2013-07-09 15:44:56 UTC

Krzysztof Daniel 2013-07-08 21:01:08 UTC

Greg Watson 2013-07-16 14:13:40 UTC

Doug Schaefer 2013-07-16 15:06:34 UTC

Ian Skerrett 2013-07-16 18:20:42 UTC

Mickael Istria 2013-07-16 18:25:07 UTC

Pascal Rapicault 2013-07-16 18:43:10 UTC

Mickael Istria 2013-07-16 19:21:28 UTC

about - legalese

Loading...