[cross-project-issues-dev] How can we better communicate the final date

[David M Williams <david_williams@xxxxxxxxxx>]

There's been a few cases where people have change things, on their own 
update sites, and then also in their .build file for Galileo. 

These changes to the .build files are not being pulled into Galileo 
Discovery site, that deadline was last wednesday, and then stretched to 
Thursday at some specific requests. (I've pasted at the end of this note, 
the three changes and responsible projects). 

Some of these changes I know were motivated by last minute very bad bugs 
being found. But, some of them just appeared ... almost as though people 
didn't realize the deadline was past, and that I asked explicitly that the 
final build be left alone so that it would be reproducible, if required to 
rebuild. Now it is no longer reproducible. Just days after the freeze. I 
was hoping for about a month! 

So, I'd like to understand this better. Maybe some of you can explain it 
to me, and how to improve next year. And, if not, you can just take this 
as a mile scolding so you can learn to improve next year. :) 

1. Some have said it might be because the final build is called "RC5" 
instead of "R". Now, I would have thought this note in the document (
http://wiki.eclipse.org/Galileo) would have been enough: 

"Note: in the following table, RC5 on the 'Galileo' line does not mean 
this final build is a release 'candidate' ... it is still to be the 'final 
build' for this Release ..."

But maybe the abbreviation outweighs the prose. 

2. Some have suggested that since the Final Daze document mentioned 
"preparing your releases offline" until 6/22 that they actually had 6/22 
to build their final build. Guess most of us know, from experience, 
"preparing your releases" doesn't imply building, but just getting names 
right, pages edited, landing pages polished, etc. We'll clean up that 
document for next year to make it clearer to first-timers. 

3. I wonder too, if it is a "cultural" shift -- for those new to 
Simultaneous Release -- in a couple of ways: 
1) final means final. Many projects are used to "making their own 
decisions" and it is much harder to "fit in" to the schedules and needs of 
a larger, massive "project" from above. 
2) RC means RC! Each Release Candidate should be releasable. Period. Sure, 
you might want to produce 1, 2, or 4 small deltas, just to fix some bad 
things, or fix some documents, but your release should be very well tested 
before the first RC. No surprises after that. 
3) it not too unusual to do a patch feature to fix some bug that slipped 
by until too late to fix in a release. Not good, but I know many have done 
it in the past and at least 3 that are doing it for this release. Good 
news there is that it's totally up to you. Each project can decide when, 
how, how many, etc. All we ask is you also participate in SR1 and SR2 in a 
coordinated fashion. 

4. I sort of wonder if Projects need more help from their Mentors or PMCs? 
It appears, on the surface, many projects are operating in isolation ... 
part of what the Simultaneous Release is meant to solve, I guess. 

So, anyway, I really don't mean to vent and rant, and am responsible for 
many of the errors in miscommunication, but thought I'd write this out 
now, in the hope of motivating some of you to give feedback ... here on 
this list, or on 
http://wiki.eclipse.org/Planning_Council/Galileo_postmortem_PLs. 

I hope we all learn more and more each year, so the following year will be 
better, and easier. So, help me learn too and improve the process with 
your suggestions and insights. 

Thanks for your help, 

= = = = 

here's .build changes since the freeze (that won't be in Galileo Discover 
site). I would just revert the files to the RC5a versions, but I'd have no 
idea of the repositories they point to would still support that roll-back. 
I can't say there is a dire need for these three teams to roll-back, and I 
do not want to waste your time doing it when there is no need, but you 
might want to consider what it would take to roll-back, if you were asked 
to. 


MDT UML2TOOLS
-  <features id="org.eclipse.uml2tools.sdk" version="0.9.0.v200906190654" 
repo="//@repositories.0">
+  <features id="org.eclipse.uml2tools.sdk" version="0.9.0.v200906031456" 
repo="//@repositories.0">


EMFT MINT
-  <features id="org.eclipse.emf.mint.sdk" version="0.8.0.v200906161513" 
repo="//@repositories.0">
+  <features id="org.eclipse.emf.mint.sdk" version="0.8.0.v200906110922" 
repo="//@repositories.0">

-  <repositories location="
http://download.eclipse.org/modeling/emft/updates/releases/"; label="EMFT 
MINT releases"/>
+  <repositories location="
http://download.eclipse.org/modeling/emft/updates/milestones/"; label="EMFT 
MINT milestones"/>

 
PDT 
-  <features id="org.eclipse.php.sdk" 
version="2.1.0.v20090611-0930-51-84QACBIHRiLOmQMX7NJj5rCOd" 
repo="//@repositories.0">
+  <features id="org.eclipse.php.sdk" 
version="2.1.0.v20090611-0930-51-84QACBIHRiLOmQMX3XhJh39Od" 
repo="//@repositories.0">
+    <category href="galileo.build#//@categories.1"/>
+    <category href="galileo.build#//@categories.2"/>