Hi Matt,
First of all, I very much enjoy the effort and energy you are
driving
this forward!
The task list for a release you summarized below already is very
complete I
think, but of course the devil is and will be in the details :)
More comments below.
On 05/26/2011 11:32 PM, Franklin, Matthew B. wrote:
Assuming we are still going for a June 15th release date
(approximate), I
wanted to make sure the community is in agreement with what will
be
in
scope. The following are the release notes prepared from JIRA. Any
issues that are not yet resolved are noted with a -- prefix
Release Notes - Rave - Version 0.1-INCUBATING
** Technical task
* [RAVE-14] - Create basic object model to support rendering of
widgets
* [RAVE-15] - Implement basic JPA persistence layer
* [RAVE-16] - Create basic page rendering
* [RAVE-17] - Implement OpenSocial/Shindig Common Container
* [RAVE-18] - Implement basic user logon features
* [RAVE-19] - Add gadget container-side hooks
--* [RAVE-20] - Implement container/shindig auth
--* [RAVE-27] - Implement User Prefs
** Story
--* [RAVE-12] - Render OpenSocial Gadgets on Page in iFrames
--* [RAVE-30] - Render W3C widgets on Page in iFrames
* [RAVE-32] - Create basic widget repository
* [RAVE-33] - Create the ability to move widgets on a page
We nee our mentors to help us through this process, but I *think*
we
need
the following before release:
* Add a Release Management guide on the site
(see more about that below)
* Create a dedicated issue for managing/tracking the release tasks
* Discuss and decide what to release, e.g. just a source or also a
binary (demo)?
* Finish outstanding issues or pull them out of scope for release
* Issue verification& closure (testing)
* License marking verification
Basic check can be done automatically with mvn verify -P pedantic
(executing
maven-rat-plugin). I just did and found a few astray sources, which
I'll pick up
to fix shortly.
* Dependency verification
Very good point: this is a (very) often overlooked task in general
IMO (not just
for releases and not just for Incubator projects).
-> $mvn dependency:tree
* IP verification
* Wire up nexus for artifact release
Already done, e.g. we already can deploy SNAPSHOTS and AFAIK
staging/releasing
should thereby already be enabled too. Might need a check though.
* Appoint a release manager
* Create a release tag and make release candidate artifacts
available
(staging)
* Hold a community vote
* Hold an IPMC vote
And, if the release is accepted:
* Release the release artifacts
* Send out a release announcement
I plan on taking on the container/shindig auth piece next week,
Jesse is
currently working on user prefs, and Ross is working on
implementing
the
call to Wookie to get the iFrame URL for the given context. I
think
if we
don't have these issues completed by end of next week, we should
pull them
from the 0.1 release and move forward.
+1
We will need to get volunteers to test the various issues. As we
agreed
earlier, it is best if the person implementing the issue doesn't
test/close the issue.
I can allocate time next week to start testing some issues/features
next week.
Note: I'll be away to Berlin (http://berlinbuzzwords.de/ ) from 6/3
till 6/8,
but probably available some time during the evenings.
As for the IPMC& license tasks, I don't know what our first steps
are
supposed to be (although I am sure there is a guide I need to
read).
Main guide is here:
http://incubator.apache.org/guides/releasemanagement.html
That guide is draft (always I'm afraid) and rough around the edges,
broken links
etc., but in general it covers everything we should be concerned
of.
The license and IP verification isn't that difficult IMO,
especially
not as
(AFAIK) all we'll release is newly written source or has ASL
compatible
dependencies only. Primarily the license headers, NOTICE and
DISCLAIMER are of
most concern, *and* having these appropriately embedded in the
right
location in
the distributed archives and (maven) artifacts.
The IPMC requirements and voting procedures aren't difficult, we
just
need to
follow the guideline, and expect detailed scrutiny from IPMC
members
:)
Concerning the release procedure itself, a very good and important
advise from
the guideline is to describe and publish our own release process
management.
I've looked around a bit what other (Incubator) projects have for
this and found
in particular the documentation from the Bean Validation project
impressive:
http://incubator.apache.org/bval/cwiki/release-management.html
My advise is to write something similar (shameless copying
allowed),
and keep
refining it whenever we encounter an issue to handle so subsequent
releases will
become easier every time.
Thoughts?
-Matt
