rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: First Release
Date Wed, 01 Jun 2011 10:50:13 GMT
On 01/06/2011 11:36, Ate Douma wrote:
> Great stuff so far guys!

+1000

(appols for not doing the Wookie integration yet, it's still sitting in 
a half finsihed state on my hard drive - hoping to find the time to 
finish it soon, but don't let it block this release).

Ross

> 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
>>>
>>
>


Mime
View raw message