[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cross-project-issues-dev] How can we better communicate the final date for builds and end activities?
- From: David M Williams <david_williams@xxxxxxxxxx>
- Date: Mon, 22 Jun 2009 04:49:18 -0400
- Delivered-to: firstname.lastname@example.org
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
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
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
- <features id="org.eclipse.uml2tools.sdk" version="0.9.0.v200906190654"
+ <features id="org.eclipse.uml2tools.sdk" version="0.9.0.v200906031456"
- <features id="org.eclipse.emf.mint.sdk" version="0.8.0.v200906161513"
+ <features id="org.eclipse.emf.mint.sdk" version="0.8.0.v200906110922"
- <repositories location="
+ <repositories location="
- <features id="org.eclipse.php.sdk"
+ <features id="org.eclipse.php.sdk"
+ <category href="email@example.com"/>
+ <category href="firstname.lastname@example.org"/>