[stp-dev] Galileo RC heartbeat

[Oisin Hurley <oisin.hurley@xxxxxxxxx>]

As you can see at http://wiki.eclipse.org/Galileo there are a
whole load of weekly RC builds coming up. This is a busy
time for all concerned.

I think we can agree that getting through this period without
having to do multiple tags, multiple builds etc etc unnecessarily
would be a good use of our collective time.

So here's a proposal, and I'm eager to get your feedback. It's
intended to take the pressure off everyone :)

1. If your project is 'done' as far as you are concerned for
Galileo (pending any sudden bugs being discovered), create
a branch named after the 'version' of your project.

e.g.

svn cp .../org.eclipse.stp.policy/trunk
           .../org.eclipse.stp.policy/branches/1.1.0

That branch is there iff you find that there are bugs or dependencies
that get discovered after the fact of ship, then you can fix them
on the branch and we can get a re-build out easily for consumers.

2. If you have made this branch then you should then create a
tag "3.5GA" to indicate this is your build (unless there's a situation
where a blocker bug arises, etc).

e.g.

svn cp .../org.eclipse.stp/policy/branches/1.1.0
           .../org.eclipse.stp/policy/tags/3.5GA

This is the tag that I'll use to make the final Galileo build.

3. If you are still in the process of getting things ready for Galileo,
then simply tag your trunk as per our usual convention "3.5RCx"

e.g.

svn cp .../org.eclipse.stp.policy/trunk
           .../org.eclipse.stp/policy/tags/3.5RC2


The outcome is that if you are ready to rock right now, you
just need to make the branch and the build tag and I won't
bother you about builds unless something breaks :)

If making a branch and a tag seems a bit 'heavy' - it's not
really, svn manages the storage in such a way that there is
no excess duplication. If it seems like too much work, let
it be known that if I have commit rights I can do the tagging
branching for your project, just put in a bugzilla for the STP
build component :)

If you reckon you don't need the branch, that's fair enough,
but I would ask you to humour me, just in case there is an
issue down the line where a change in a dependency means
that consumers need you to make some change/s workarounds
in a previous version of your software.

Well, let me know what you think.

Ok, some other Galileo items that are on the list. Here are
three items picked from the http://wiki.eclipse.org/Galileo
page:

1. "Each major project (as determined by participating PMCs) should
have an About dialog icon with descriptive text (e.g. provider name
= "Eclipse Modeling Project" and not simply Eclipse.org) and contribute
to the welcome page."

This is a 'should have' - but I'm interested to hear what you
guys think about having this icon in place, and contributing
to the welcome page.

2. "Projects must have an project plan in XML format."

Can you let me know, please, if you have this in place, and
send links.

3. "Must have new & noteworthy for each milestone. Must be something
readable and usable not just a static list of all the bugs, e.g. platform.
Corollary: individual new & noteworthy should be linked in to the collective
New & Noteworthy."

Ok, so I'm going to unilaterally tone this one down and say,
please can we have a round-up of what's new and noteworthy
for your project for the release review and the GA.

4. "Projects should leverage only published APIs of dependencies. As a
Release Review requirement, all deviations must be documented.
Additionally, rectification for the issues should be listed as part of a
migration plan, with bugs listed where APIs need to be provided by
dependent projects"

So - it looks like we have to document our deviations :)  I see where
the PC is coming from with this one, and my approach here would be
to do something along the lines of finding all of the imports of
internal packages in your code and just writing them down. The
migration plan piece is a 'should do'. There may be some kind of
magical PDE tooling that can do this, but I'm not aware of it at
the moment.

Finally, a reminder about Release Review. Here are the dates:

* Release review documentation due May 29
* IP Logs  due June 3
* Galileo review date is June 10.

Release review documentation is due END OF THIS WEEK!

 --oh