rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <mpie...@cs.indiana.edu>
Subject Re: First Release
Date Wed, 01 Jun 2011 12:18:09 GMT
Hash: SHA1

Hi Ate, which comments?


> 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
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


View raw message