Re: [cross-project-issues-dev] Status and outlook for Indigo RC3

[David M Williams <david_williams@xxxxxxxxxx>]

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