Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Status and outlook for Indigo RC3

Well, lets see if I can keep this brief :) ... no, no need for project B or aggregator to build again .... the aggregator just collects stuff. In an ideal world, Project B only uses API from Project A, and Project A is well-behaved enough not to make any breaking API or versioning changes this late ... then what ever is collected in step 5 is most recent, and correct. Of course, there is opportunity for those assumptions to go wrong ... but, that'd take a long answer :)






From:        Miles Parker <milesparker@xxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        05/31/2011 02:23 PM
Subject:        Re: [cross-project-issues-dev] Status and outlook for Indigo RC3
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx





As the "Universal Consumer", AMP is +1 on most of the below so that that could conceivably put us late +3 or even +4. But I don't anticipate any dependency issues unless these guys have surprises for me. ;)

Is my intuition correct that given the following circumstance:

1. Project B has dependency on Project A.
2. Project B Builds [+ perhaps modifies aggr build]
3. Indigo Aggregator Builds
4. Project A Builds [+ perhaps modifies aggr build]
5. Indigo Aggregator Builds

That unless changes in 4) actually break the Project B build / dependencies, there is no need for another Project B build -> Indigo Aggregator build to occur? My guess is "no", given that +k is project defined/negotiated...


On May 31, 2011, at 9:01 AM, Dennis Hübner wrote:

Am 31.05.11 17:41, schrieb Stéphane Bouchet:
Hi,

following your (long) instructions, i can say that Acceleo, EMF Compare and EEF will be late for RC3 +2.

we will do our best tomorrow morning ( European time, early RC3 + 3 for US ) to provide our last bits.

thanks for clarifying,


The same for TMF Xtext, M2T Xpand and EMFT MWE.
We will build tomorrow.

Best regards,
Dennis.



Le 31/05/2011 17:28, David M Williams a écrit :

I was going to wait to comment later in the day ... to see if servers
recover fairly well by the end of today ... but ... given Laurent's
note, and others questions I'm getting via IM ... thought I should
clarify some now.

First, we should strive to never have unsigned bundles as part of any of
our repositories at any time ... that is, at least, any repository
that's "declared" for anyone to install, even during development. If you
do, then a) there is still some security risk (the reason we sign in the
first place), and b) then the next time you provide an update, you need
to make sure all your qualifiers increase ... or, your newly signed
bundles will not be picked up by some users or adopters that rely on the
version changing to signify a change in content (which, is the reason
for all the versioning rules and 4 part version number requirement in
the first place) ... and "signed or not signed" is a change in content.
So, usually best to "go with old stuff" until you can sign again.

In addition ... what everyone is waiting to hear about ... at this
point, I still think our RC3 end dates are achievable. Obviously many
will be "late" (past their +N day) and I might have to stay up later
than usual on Wednesday night :) but I do think it is possible to "make
the date" and following our "heck or high water" process, that is our
current plan. Of course, some projects may decide just to go with their
RC2 results as their contribution towards Indigo RC3, and roll-forward
their RC3 contribution into their RC4 contribution next week, but that's
up to each project. At this point, I'd like to follow the usual rules:
if you contribute past your +N day, just let everyone know here on this
list after you have contributed; and, by Wednesday afternoon, if your
contribution is/will be past "EOD" (5 PM Eastern) to let us know, here
on this list, that you'd like a respin to pick up your "late"
contribution. We will all be plenty sympathetic. If you just stay with
your RC2 content for RC3 I don't think you need to notify everyone here,
but that's up to you ... in some cases (such as if you are low in the
food chain) it might be better to do so.

Naturally, we'll adapt and adjust plans as we observe more about how the
servers, etc., recover, but my guess is we will recover enough to have a
useful RC3. This will (or, has) pushed out more risk to RC4 than we'd
like ... more than usual ... but, that's how we do it. And ... rest
assured ... we've done it before ... that is, we've had catastrophic
failures in previous years during "the end game" and still shipped on
time. In fact, I think it was just two years ago, we had "complete disk
failure" and even had to wait for a replacement to arrive!?

But, I can't help close on a whimsical observation ... we committers
first sucked up all the bandwidth ... that problem was solved ... then
we sucked up all the disk space ... that problem was solved ... and now
we've moved on to consuming power supplies! We sure keep our webmasters
busy! :) Much thanks for them to working tirelessly to help us recover
and keep on track.

And, thanks to all you committers and "release engineers" for working
through these difficult, last minute problems. I know its stressful.

As always, keep the questions coming, let us know how its going ... and
I'll do the same.

Thanks,








From: Laurent Goubet
<laurent.goubet@xxxxxxx>
To: Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date: 05/31/2011 09:55 AM
Subject: [cross-project-issues-dev] server status and the RC3 build
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------



Hi,

With the current issues on the server, what is expected from the
different teams as regards to the RC3 builds? Should we build our bits
"as we can" (disabling signing is part of it) and promote an unsigned
"RC3" build to the Indigo aggregator? Should we skip the RC3 build and
hope that we'll be able to build in time for next week's RC4?

When I try to build EMF Compare, I simply get a cryptic

Caused by: java.lang.LinkageError: loader (instance of
hudson/remoting/RemoteClassLoader): attempted duplicate class definition
for name: "hudson/model/Result

(see

https://hudson.eclipse.org/hudson/view/Modeling/job/emf-compare-1.2.0/79/console)

Is this part of the potential issues we can expect with the current
server problems?

Laurent Goubet
Obeo
[attachment "laurent_goubet.vcf" deleted by David M
Williams/Raleigh/IBM] _______________________________________________
cross-project-issues-dev mailing list

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



_______________________________________________
cross-project-issues-dev mailing list

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


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



--
Dennis Hübner

Softwareentwickler

Mobil:   0151 173 96 707

http://www.itemis.de/

itemis AG
Am Germaniahafen 1
24143 Kiel

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

_______________________________________________
cross-project-issues-dev mailing list

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


Back to the top