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 qua
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
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 t
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 f
> 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
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-boun...@eclipse.org
> 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
Hi Jesse
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.
a) The LTS will not provide any further releases. i.e.
> 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
Our ISP has located the problem (a DDoS) and our site seems to be happy
once again.
Denis
On 07/03/2013 12:07 PM, Roland Grunberg wrote:
I am experiencing very slow response times / hangs accessing
http://bugs.eclipse.org/
Is it me or is bugzilla down?
Jan
I seem to be experiencing the s
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
Compiled 2013-07-03T12:07
build.eclipse.org
-> Usage exceeding 1GB for: Hudson master jobs and workspace (2013-07-03T10:00)
32.7G ep4-unit-lin64
9.5G emf-emfstore-integration-tycho
3.7G emf-emfclient-maintenance
2.5G Xtext-nightly-HEAD
2.2G emf-emfclient-integration
2.0G
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
Our ISP is currently experiencing an issue with bandwidth -- eclipse.org
currently can't push more than about 20Mbps (instead of our usual 200)
We'll keep you posted.
Denis
On 07/03/2013 11:55 AM, Sievers, Jan wrote:
I am experiencing very slow response times / hangs accessing
http://bugs.ec
> I am experiencing very slow response times / hangs accessing
>
> http://bugs.eclipse.org/
>
> Is it me or is bugzilla down?
>
> Jan
I seem to be experiencing the same.
--
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issu
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 am experiencing very slow response times / hangs accessing
http://bugs.eclipse.org/
Is it me or is bugzilla down?
Jan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-projec
> 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
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 use
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
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
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 inclu
Or it means that the workload on the IP team is spread more regularly
throughout the year.
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Henrik
Rentz-Reichert
Sent: July-03-13 3:34 AM
To: Cross project issues
Subject: Re: [
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
36 matches
Mail list logo
