-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ate, which comments?
Marlon > NB: getting the issues closed by itself won't be enough. > Besides the tasks Matt already indicated before, I added several comments > earlier which IMO in addition need to be taken care of. > I haven't seen any further comments on this yet, are there any takers...? > > Regards, > > Ate > > On 05/27/2011 01:15 PM, Ate Douma wrote: >> 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 >>> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN5i4BAAoJEEfVXEODPFIDOXcIAJwAtb7dK2Fksq2dx9PA1XsU 2yRDlAGZKwkUGjR7ScZMgH49qK7guCGmDi66dZA3nlDFmccqEsQ1j/SuLnaMr/ij NYRFGmrtFJaRd4HpdoyppVDVXTmoOL4WTOAw+44Fk+hCiianBATVEqJm1XA7ac3q L4SFADHUnLBM1+Hfjta6L6rsneaOVToRsRtTZl/8Y/AlQPbZgVQhaN0rpG3mwqTL AEEDV4gxUvheWU4MnC85HvUDEF8sXqG3vyjUko82lkeyJK696xh/2f9z8AhV8uDx LsS5+W+88yL0OOfRFc1gmiGGe/S9nOarDbbAfziZvfU7F6+jWX8+SNqKFsCmuvg= =383x -----END PGP SIGNATURE-----
