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
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 wrote:
> On 07/16/2013 08:20 PM, Ian Skerrett wrote:
>> The download page is driven by the output of the EPP project which b
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.
-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@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
ev
ss project issues
mailto:cross-project-issues-dev@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 ov
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
You missed the second half of my writeup.
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael
Istria
Sent: Tuesday, July 09, 2013 8:43 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] 6
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 pas
ipse.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
ilto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael
Istria
Sent: Tuesday, July 09, 2013 2:41 AM
To: cross-project-issues-dev@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
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.
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. Th
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 metadat
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
ady have to track those emerging
milestone as their development target.
- Konstantin
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John
Arthorne
Sent: Monday, July 08, 2013 11:37 AM
To: Cross project issues
Subject: R
ay, 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
To: "cross-project-issues-dev@eclipse.org"
,
Dat
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 s
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 l
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 prob
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
th
bject: 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
pr
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 repositor
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 ot
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:
omas Hallgren
>> Sent: July-04-13 5:20 AM
>> To:
>> cross-project-issues-dev@**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 aut
e.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas
Hallgren
Sent: July-04-13 5:20 AM
To: cross-project-issues-dev@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 auto
e.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas
Hallgren
Sent: July-04-13 5:20 AM
To: cross-project-issues-dev@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 b
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 rele
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-th
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 u
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'.
___
cros
v-boun...@eclipse.org [mailto:
> cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer
> Sent: July-03-13 4:38 PM
> To: mike.milinkov...@eclipse.org; Cross project issues
> Subject: Re: [cross-project-issues-dev] 6 month release cycle
>
> Agree on David and Markus
PM
To: mike.milinkov...@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 indiv
> 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 b
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
[mailto:cross-project-issues-dev-boun...@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
> 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 i
> Ed Merks 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
> 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 represe
> 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
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
> 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
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"
wrote:
>Glad to see interest in my frequent aggregation proposal. To answer some
>of
>the questions that were raised...
>
>1. Monthly releases sou
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
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 t
> 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-pr
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
thinkin
Hi,
Am 03.07.2013 um 00:33 schrieb Henrik Rentz-Reichert :
> 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 proces
...@eclipse.org
[mailto:cross-project-issues-dev-boun...@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 r
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
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 re
Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month
release cycle
All
projects contribute the latest finished release
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 partic
: [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
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 (
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
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 m
On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner 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 toge
> 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
ity is not that far
away.
- Konstantin
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@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 cyc
rg>>
Date: Tuesday, 2 July, 2013 5:03 PM
To: Cross project issues
mailto:cross-project-issues-dev@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. (T
x 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
> Reply-To: Cross project issues
> Date: Tuesday, 2 July, 201
, 2 July, 2013 4:08 PM
To: Cross project issues
mailto:cross-project-issues-dev@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
_
>> From: cross-project-issues-dev-boun...@eclipse.org
>>[cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor
>>Fedorenko [ifedore...@sonatype.com]
>> Sent: Tuesday, July 02, 2013 3:49 PM
>> To: cross-project-issues-dev@eclipse.org
>> Sub
ssues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko
[ifedore...@sonatype.com]
Sent: Tuesday, July 02, 2013 3:49 PM
To: cross-project-issues-dev@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
e
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 t
-project-issues-dev@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 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 f
chik [konstantin.komissarc...@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-beari
two
"minor".
- Konstantin
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug
Schaefer
Sent: Tuesday, July 02, 2013 12:31 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] 6
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 d
71 matches
Mail list logo
