You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Franklin, Matthew B." <mf...@mitre.org> on 2011/05/26 23:32:58 UTC
First Release
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:
* Finish outstanding issues or pull them out of scope for release
* Issue verification & closure (testing)
* License marking verification
* Dependency verification
* IP verification
* Wire up nexus for artifact release
* Hold a community vote
* Hold an IPMC vote
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.
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.
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).
Thoughts?
-Matt
Re: First Release
Posted by Ate Douma <at...@douma.nu>.
On 05/26/2011 11:32 PM, Franklin, Matthew B. wrote:
> * Dependency verification
We have a specific concern here with regard to our Shindig *-SNAPSHOT dependency...
We should not and cannot release while depending on a SNAPSHOT, the
maven-release-plugin AFAIK also will not allow that.
Looking at dev@shindig I don't see any indication of an upcoming (beta) release,
so we'll need to decide how to deal with this.
I think we have about two options here:
a) revert back to latest Shiding 2.0.2 release if feasible
a) ask Shindig if they can and will do a (beta) release any time soon
Note: a Shindig 3.0.0-beta1 tag exists but was never pushed/published to maven
repository. If a Shindig trunk (beta) release cannot be expected soon and
falling back to Shindig 2.0.2 isn't an option either (I haven't tested),
possibly we could request the Shindig team to just push/publish this 3.0.0-beta1
instead. That is, if that one would work for us.
Ate
Re: First Release
Posted by Ross Gardler <rg...@apache.org>.
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
>>>
>>
>
Re: First Release
Posted by "Zhenhua (Gerald) Guo" <je...@gmail.com>.
Sounds good.
I have committed code to fix gadget deletion bug. Need others to test
it. If it turns out to be fixed without incurring more bugs, just
close it.
Gerald
On Wed, Jun 1, 2011 at 10:43 AM, Franklin, Matthew B.
<mf...@mitre.org> wrote:
> I have created JIRA issues for all of the tasks that Ate laid out that
> were assignable. The remaining (see below) are community discussions that
> need to take place:
>
> * Discuss and decide what to release, e.g. just a source or also a
> binary (demo)?
>
> * Appoint a release manager
>
> We also have two issues still in progress:
>
> * Delete Widgets
>
> * User Prefs
>
> I would like to set a deadline of Friday for issue completion, assuming
> the community agrees. If the issues are not completed by then, we can add
> javascript that alerts that the feature is not implemented and return
> statements so that we don't have to roll back any code.
>
> This deadline will allow us to complete release tasks next week so that we
> can hit the 15th release date.
>
> -Matt
>
>
>
> On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>
>>On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi Ate, which comments?
>>
>>For instance:
>> http://markmail.org/message/7dfxwgryq7hp334l
>>and
>> http://markmail.org/message/vn2227zm2loxojkq
>>
>>(same thread)
>>
>>>
>>>
>>> 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-----
>>
>
>
RE: Need some apache+maven advise Re: First Release
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>I also noticed the request from Jesse on the Shindig dev@ list about a possible
>new beta2 release. Not seeing any responses to that, but I'd expect that'll
>won't happen overnight anyway. And it'll take days/weeks before they would
>have
>such a release prepared, voted and finally released...
>So, I'm not sure we can/want to wait on that, really.
>I haven't tried to downgrade Shindig to the latest release version, but how
>much
>do we actually need/depend on from Shindig 3.0 to get our 0.1 release
>working?
>If this is a blocker, we might simply be required to wait until a Shindig
>3.0-beta2 comes available before we can do our own release, which would be
>a pity :(
>So, can anyone investigate or explain how much we already are tied to Shindig
>3.0+?
Our dependency on Shindig 3.0 is for the common container JavaScript code they've been working on recently which is what we're currently using to generate our iframes and iframe url's for OpenSocial gadgets. The common container supports other functions as well but right now we're not really using any of them. If we were to downgrade to the last 2.0 release we'd need to add support somewhere (maybe in the OpenSocialWidgetRenderer) to generate the iframe url's and also support somewhere (maybe in our client side JS) to generate the iframes themselves and set their location to the generated url.
I think it would be pretty straight forward to do (especially right now since we aren't setting user preferences in the gadget rendering url's), but we'd probably want to revert back to 3.0 right after our 0.1 release so we could continue to build on the common container base (and hope that the Shindig beta2 release would be ready by the time we're ready to do a 0.2 release of Rave).
>
>Thanks,
>
>Ate
Re: Need some apache+maven advise Re: First Release
Posted by Ate Douma <at...@douma.nu>.
On 06/07/2011 12:37 AM, Ate Douma wrote:
> Hi all,
>
> I'm currently at the BerlinBuzzWords conference with an internet
> connection at my hotel so bad I barely manage to read email through
> webmail, nevermind trying to run svn up...
> However I'll try to get in sync tomorrow while at the conference and
> see if I can come up with an easy solution for a binary/demo package
> build.
> AFAIK this should be relatively easy to automate using cargo:package,
> possibly combined with a maven assembly configuration.
>
Just a quick update:
Running mvn cargo:configure && mvn cargo:package from the rave-portal project
produces an *almost* ready to be used demo package (under target/package)
which we could package, with the obligatory README, NOTICE etc. files.
We also need to customize/modify the bin/catalina.sh to allocate more initial
memory because the default memory settings causing a PermGenSpace OOM error
immediately after startup :)
So, I think we could add a separate "dist" profile wich executes the above goals
and thereafter use a maven assembly configuration to produce the final
downloadable distrubtion archive with the needed other files added/modified.
I'll try to work on something later this evening or tomorrow evening (when I'm
back in the Netherlands). Right now my time is too limited.
I also noticed the request from Jesse on the Shindig dev@ list about a possible
new beta2 release. Not seeing any responses to that, but I'd expect that'll
won't happen overnight anyway. And it'll take days/weeks before they would have
such a release prepared, voted and finally released...
So, I'm not sure we can/want to wait on that, really.
I haven't tried to downgrade Shindig to the latest release version, but how much
do we actually need/depend on from Shindig 3.0 to get our 0.1 release working?
If this is a blocker, we might simply be required to wait until a Shindig
3.0-beta2 comes available before we can do our own release, which would be a pity :(
So, can anyone investigate or explain how much we already are tied to Shindig 3.0+?
Thanks,
Ate
Re: Need some apache+maven advise Re: First Release
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 6/6/11 6:37 PM, "Ate Douma" <at...@douma.nu> wrote:
>Hi all,
>
>I'm currently at the BerlinBuzzWords conference with an internet
>connection at my hotel so bad I barely manage to read email through
>webmail, nevermind trying to run svn up...
>However I'll try to get in sync tomorrow while at the conference and
>see if I can come up with an easy solution for a binary/demo package
>build.
>AFAIK this should be relatively easy to automate using cargo:package,
>possibly combined with a maven assembly configuration.
>
>More comments below.
>
>Regards,
>
>Ate
>
>On Mon, Jun 6, 2011 at 10:43 PM, Marlon Pierce <mp...@cs.indiana.edu>
>wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Definitely questions for Ate or another mentor/champion.
>>
>>
>> Marlon
>>
>>
>> On 6/6/11 2:50 PM, Franklin, Matthew B. wrote:
>>>
>>> On 6/1/11 2:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>>>
>>> I don't have strong opinions on source versus binary releases at this
>>> point, but I am wondering how they work. For a source release, would
>>>we
>>> bundle up a tar/zip and put it on an Apache mirror or just tag it in
>>>SVN?
>>> For a binary release, would we just put up a WAR or would we package
>>> tomcat+rave+shindig-snapshot? What other steps are
>>>required/recommended
>>> (zip/md5/pgp)?
>>>
>>>> I like the idea of packaging tomcat with the two war files so that
>>>>you can
>>>> just execute the tomcat start script. If we think this is a good
>>>>idea,
>>>> can we wire this into a maven goal like release? Could we also add
>>>> anything required to push the release to the correct location on
>>>> people.apache.org? The more we can automate the better. It would be
>>>>nice
>>>> to have a release guide that said something like:
>>>
>>>> 1) checkout the source
>>>> 2) execute mvn stage
>>>> 3) vote
>>>> 4) execute mvn release
>
>I doesn't work exactly like the above, for one: mvn release will
>deploy the artifacts to a temporary *staging* repository, which we
>then vote upon.
My commands above were meant to reflect a desire to automate the whole
process, from build to pushing to the staging repository, to scp for the
demo to the staging area of people.apache.org. I am pretty inexperienced
with maven and didn't realize there was actually a mvn release goal :)
Even if it is a shell script, it seems to me that the more we can automate
and the less complicated we can make the release guide, the better off we
are. Reading over the example you produced, it seems that bean validation
has a lot of room to automate most of their release process. In the end,
it will just mean less time spent producing releases.
>In addition, if we produce a binary/demo artifact it probably won't be
>(easily) also be "released" to a maven repository (nor should it be
>IMO), so we should provide it as a separate download on a temporarily
>(informal) location, e.g. somewhere on people.apache.org.
>
>Once the vote is accepted (both by the Rave PMC and thereafter by the
>IPMC), we thereafter only need to "publish" the (Nexus) staging
>repository which then will be pushed/merged towards Maven central.
>Furthermore we then can/have to manually move the binary/demo download
>to the official incubator dist download area, send out the
>announcement and be done.
>
>If however the release is voted down, the staging repository will have
>to be "dropped" and the temporary binary/demo download removed, and we
>have to start working towards a fixed and acceptable 0.2 release (the
>0.1 version no longer can be "reused" once tagged and produced).
Got it. Thanks.
>
>>>
>>>> :)
>>>
>>>
>>>
>>> Having said that, I favor going through the full release steps for both
>>> the binary and source. This is early but it will make sure we
>>>understand
>>> the process when things are further along.
>>>
>>>> What about javadoc?
>What about it?
>I assume you mean producing -javadoc jars which can then be
>loaded/used from an IDE?
>Or would you like to have the javadoc published online?
>
>For the -javadoc jar generation, please be aware we currently are only
>building .war files, so AFAIK IDE's won't see/use these as proper
>"jar" dependencies for which to load/download related -javadoc jars.
>And, I think the -javadoc generation for war projects, although done
>automatically, actually is kind of screwed up (but I need to check
>again with the latest maven plugins).
>
>Publishing the javadoc online is not something I'm familiar with yet
>how to integrate and do with the new Apache CMS, but probably doable.
>I'd expect someone simply has to check in the generated javadoc in the
>proper format and location?
>
>>>
>>>
>>>
>>> Marlon
>>>
>>>
>>> On 6/1/11 10:43 AM, Franklin, Matthew B. wrote:
>>>>>> I have created JIRA issues for all of the tasks that Ate laid out
>>>>>>that
>>>>>> were assignable. The remaining (see below) are community
>>>>>>discussions
>>>>>> that
>>>>>> need to take place:
>>>>>>
>>>>>> * Discuss and decide what to release, e.g. just a source or also a
>>>>>> binary (demo)?
>>>>>>
>>>>>> * Appoint a release manager
>>>>>>
>>>>>> We also have two issues still in progress:
>>>>>>
>>>>>> * Delete Widgets
>>>>>>
>>>>>> * User Prefs
>>>>>>
>>>>>> I would like to set a deadline of Friday for issue completion,
>>>>>>assuming
>>>>>> the community agrees. If the issues are not completed by then, we
>>>>>>can
>>>>>> add
>>>>>> javascript that alerts that the feature is not implemented and
>>>>>>return
>>>>>> statements so that we don't have to roll back any code.
>>>>>>
>>>>>> This deadline will allow us to complete release tasks next week so
>>>>>>that
>>>>>> we
>>>>>> can hit the 15th release date.
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>>>>
>>>>>>> On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>>>>>> Hi Ate, which comments?
>>>>>>>>
>>>>>>>> For instance:
>>>>>>>> http://markmail.org/message/7dfxwgryq7hp334l
>>>>>>>> and
>>>>>>>> http://markmail.org/message/vn2227zm2loxojkq
>>>>>>>>
>>>>>>>> (same thread)
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> 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/
>>
>> iQEcBAEBAgAGBQJN7TvsAAoJEEfVXEODPFIDPNoH/RPd4AhgrFspghbF7PBaUgwe
>> +2c8JbV+NaF+eUgQkgZ1xWKRrEVhVevoaX9Yh2RumSzJfonYDThZjoQBGXY2ssbJ
>> pgUWxZ/vvriKZYC6wPojqmJl9Bil1MThmIuaIsvmb43ftj+IIkrOMOKNT6TQsoYU
>> wJIDj8IlkmDQsDMSxtG1y+7Qbrzvyt/xQDVcVqKCntbL5ZUTp+aMck4ONReOwtQE
>> mV+FV3cHxWdLq585DFaXcaf0ijjk6CBf3cx6i6BywyHHd87Xh8/EeF9CIH2ocwDP
>> 4XKZTD/PbV+j6lzEoRYQvDvU71CeCHhPQ50kCgdJ3s5qvgMdcaohJegU0NoxF5U=
>> =dBN2
>> -----END PGP SIGNATURE-----
>>
Re: Need some apache+maven advise Re: First Release
Posted by Ate Douma <at...@douma.nu>.
Hi all,
I'm currently at the BerlinBuzzWords conference with an internet
connection at my hotel so bad I barely manage to read email through
webmail, nevermind trying to run svn up...
However I'll try to get in sync tomorrow while at the conference and
see if I can come up with an easy solution for a binary/demo package
build.
AFAIK this should be relatively easy to automate using cargo:package,
possibly combined with a maven assembly configuration.
More comments below.
Regards,
Ate
On Mon, Jun 6, 2011 at 10:43 PM, Marlon Pierce <mp...@cs.indiana.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Definitely questions for Ate or another mentor/champion.
>
>
> Marlon
>
>
> On 6/6/11 2:50 PM, Franklin, Matthew B. wrote:
>>
>> On 6/1/11 2:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>>
>> I don't have strong opinions on source versus binary releases at this
>> point, but I am wondering how they work. For a source release, would we
>> bundle up a tar/zip and put it on an Apache mirror or just tag it in SVN?
>> For a binary release, would we just put up a WAR or would we package
>> tomcat+rave+shindig-snapshot? What other steps are required/recommended
>> (zip/md5/pgp)?
>>
>>> I like the idea of packaging tomcat with the two war files so that you can
>>> just execute the tomcat start script. If we think this is a good idea,
>>> can we wire this into a maven goal like release? Could we also add
>>> anything required to push the release to the correct location on
>>> people.apache.org? The more we can automate the better. It would be nice
>>> to have a release guide that said something like:
>>
>>> 1) checkout the source
>>> 2) execute mvn stage
>>> 3) vote
>>> 4) execute mvn release
I doesn't work exactly like the above, for one: mvn release will
deploy the artifacts to a temporary *staging* repository, which we
then vote upon.
In addition, if we produce a binary/demo artifact it probably won't be
(easily) also be "released" to a maven repository (nor should it be
IMO), so we should provide it as a separate download on a temporarily
(informal) location, e.g. somewhere on people.apache.org.
Once the vote is accepted (both by the Rave PMC and thereafter by the
IPMC), we thereafter only need to "publish" the (Nexus) staging
repository which then will be pushed/merged towards Maven central.
Furthermore we then can/have to manually move the binary/demo download
to the official incubator dist download area, send out the
announcement and be done.
If however the release is voted down, the staging repository will have
to be "dropped" and the temporary binary/demo download removed, and we
have to start working towards a fixed and acceptable 0.2 release (the
0.1 version no longer can be "reused" once tagged and produced).
>>
>>> :)
>>
>>
>>
>> Having said that, I favor going through the full release steps for both
>> the binary and source. This is early but it will make sure we understand
>> the process when things are further along.
>>
>>> What about javadoc?
What about it?
I assume you mean producing -javadoc jars which can then be
loaded/used from an IDE?
Or would you like to have the javadoc published online?
For the -javadoc jar generation, please be aware we currently are only
building .war files, so AFAIK IDE's won't see/use these as proper
"jar" dependencies for which to load/download related -javadoc jars.
And, I think the -javadoc generation for war projects, although done
automatically, actually is kind of screwed up (but I need to check
again with the latest maven plugins).
Publishing the javadoc online is not something I'm familiar with yet
how to integrate and do with the new Apache CMS, but probably doable.
I'd expect someone simply has to check in the generated javadoc in the
proper format and location?
>>
>>
>>
>> Marlon
>>
>>
>> On 6/1/11 10:43 AM, Franklin, Matthew B. wrote:
>>>>> I have created JIRA issues for all of the tasks that Ate laid out that
>>>>> were assignable. The remaining (see below) are community discussions
>>>>> that
>>>>> need to take place:
>>>>>
>>>>> * Discuss and decide what to release, e.g. just a source or also a
>>>>> binary (demo)?
>>>>>
>>>>> * Appoint a release manager
>>>>>
>>>>> We also have two issues still in progress:
>>>>>
>>>>> * Delete Widgets
>>>>>
>>>>> * User Prefs
>>>>>
>>>>> I would like to set a deadline of Friday for issue completion, assuming
>>>>> the community agrees. If the issues are not completed by then, we can
>>>>> add
>>>>> javascript that alerts that the feature is not implemented and return
>>>>> statements so that we don't have to roll back any code.
>>>>>
>>>>> This deadline will allow us to complete release tasks next week so that
>>>>> we
>>>>> can hit the 15th release date.
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>>
>>>>> On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>>>
>>>>>> On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>>>>> Hi Ate, which comments?
>>>>>>>
>>>>>>> For instance:
>>>>>>> http://markmail.org/message/7dfxwgryq7hp334l
>>>>>>> and
>>>>>>> http://markmail.org/message/vn2227zm2loxojkq
>>>>>>>
>>>>>>> (same thread)
>>>>>>>
>>>>>
>>>>>
>>>>> 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/
>
> iQEcBAEBAgAGBQJN7TvsAAoJEEfVXEODPFIDPNoH/RPd4AhgrFspghbF7PBaUgwe
> +2c8JbV+NaF+eUgQkgZ1xWKRrEVhVevoaX9Yh2RumSzJfonYDThZjoQBGXY2ssbJ
> pgUWxZ/vvriKZYC6wPojqmJl9Bil1MThmIuaIsvmb43ftj+IIkrOMOKNT6TQsoYU
> wJIDj8IlkmDQsDMSxtG1y+7Qbrzvyt/xQDVcVqKCntbL5ZUTp+aMck4ONReOwtQE
> mV+FV3cHxWdLq585DFaXcaf0ijjk6CBf3cx6i6BywyHHd87Xh8/EeF9CIH2ocwDP
> 4XKZTD/PbV+j6lzEoRYQvDvU71CeCHhPQ50kCgdJ3s5qvgMdcaohJegU0NoxF5U=
> =dBN2
> -----END PGP SIGNATURE-----
>
Re: Need some apache+maven advise Re: First Release
Posted by Ross Gardler <rg...@apache.org>.
On 06/06/2011 21:43, Marlon Pierce wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Definitely questions for Ate or another mentor/champion.
Sorry, I'm not a Maven person so will avoid this one (really I'm only
replying to let you know I'm still here despite having gone silent).
Ross
>
>
> Marlon
>
>
> On 6/6/11 2:50 PM, Franklin, Matthew B. wrote:
>>
>> On 6/1/11 2:36 PM, "Marlon Pierce"<mp...@cs.indiana.edu> wrote:
>>
>> I don't have strong opinions on source versus binary releases at this
>> point, but I am wondering how they work. For a source release, would we
>> bundle up a tar/zip and put it on an Apache mirror or just tag it in SVN?
>> For a binary release, would we just put up a WAR or would we package
>> tomcat+rave+shindig-snapshot? What other steps are required/recommended
>> (zip/md5/pgp)?
>>
>>> I like the idea of packaging tomcat with the two war files so that you can
>>> just execute the tomcat start script. If we think this is a good idea,
>>> can we wire this into a maven goal like release? Could we also add
>>> anything required to push the release to the correct location on
>>> people.apache.org? The more we can automate the better. It would be nice
>>> to have a release guide that said something like:
>>
>>> 1) checkout the source
>>> 2) execute mvn stage
>>> 3) vote
>>> 4) execute mvn release
>>
>>> :)
>>
>>
>>
>> Having said that, I favor going through the full release steps for both
>> the binary and source. This is early but it will make sure we understand
>> the process when things are further along.
>>
>>> What about javadoc?
>>
>>
>>
>> Marlon
>>
>>
>> On 6/1/11 10:43 AM, Franklin, Matthew B. wrote:
>>>>> I have created JIRA issues for all of the tasks that Ate laid out that
>>>>> were assignable. The remaining (see below) are community discussions
>>>>> that
>>>>> need to take place:
>>>>>
>>>>> * Discuss and decide what to release, e.g. just a source or also a
>>>>> binary (demo)?
>>>>>
>>>>> * Appoint a release manager
>>>>>
>>>>> We also have two issues still in progress:
>>>>>
>>>>> * Delete Widgets
>>>>>
>>>>> * User Prefs
>>>>>
>>>>> I would like to set a deadline of Friday for issue completion, assuming
>>>>> the community agrees. If the issues are not completed by then, we can
>>>>> add
>>>>> javascript that alerts that the feature is not implemented and return
>>>>> statements so that we don't have to roll back any code.
>>>>>
>>>>> This deadline will allow us to complete release tasks next week so that
>>>>> we
>>>>> can hit the 15th release date.
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>>
>>>>> On 6/1/11 9:12 AM, "Ate Douma"<at...@douma.nu> wrote:
>>>>>
>>>>>> On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>>>>> Hi Ate, which comments?
>>>>>>>
>>>>>>> For instance:
>>>>>>> http://markmail.org/message/7dfxwgryq7hp334l
>>>>>>> and
>>>>>>> http://markmail.org/message/vn2227zm2loxojkq
>>>>>>>
>>>>>>> (same thread)
>>>>>>>
>>>>>
>>>>>
>>>>> 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/
>
> iQEcBAEBAgAGBQJN7TvsAAoJEEfVXEODPFIDPNoH/RPd4AhgrFspghbF7PBaUgwe
> +2c8JbV+NaF+eUgQkgZ1xWKRrEVhVevoaX9Yh2RumSzJfonYDThZjoQBGXY2ssbJ
> pgUWxZ/vvriKZYC6wPojqmJl9Bil1MThmIuaIsvmb43ftj+IIkrOMOKNT6TQsoYU
> wJIDj8IlkmDQsDMSxtG1y+7Qbrzvyt/xQDVcVqKCntbL5ZUTp+aMck4ONReOwtQE
> mV+FV3cHxWdLq585DFaXcaf0ijjk6CBf3cx6i6BywyHHd87Xh8/EeF9CIH2ocwDP
> 4XKZTD/PbV+j6lzEoRYQvDvU71CeCHhPQ50kCgdJ3s5qvgMdcaohJegU0NoxF5U=
> =dBN2
> -----END PGP SIGNATURE-----
Need some apache+maven advise Re: First Release
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Definitely questions for Ate or another mentor/champion.
Marlon
On 6/6/11 2:50 PM, Franklin, Matthew B. wrote:
>
> On 6/1/11 2:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>
> I don't have strong opinions on source versus binary releases at this
> point, but I am wondering how they work. For a source release, would we
> bundle up a tar/zip and put it on an Apache mirror or just tag it in SVN?
> For a binary release, would we just put up a WAR or would we package
> tomcat+rave+shindig-snapshot? What other steps are required/recommended
> (zip/md5/pgp)?
>
>> I like the idea of packaging tomcat with the two war files so that you can
>> just execute the tomcat start script. If we think this is a good idea,
>> can we wire this into a maven goal like release? Could we also add
>> anything required to push the release to the correct location on
>> people.apache.org? The more we can automate the better. It would be nice
>> to have a release guide that said something like:
>
>> 1) checkout the source
>> 2) execute mvn stage
>> 3) vote
>> 4) execute mvn release
>
>> :)
>
>
>
> Having said that, I favor going through the full release steps for both
> the binary and source. This is early but it will make sure we understand
> the process when things are further along.
>
>> What about javadoc?
>
>
>
> Marlon
>
>
> On 6/1/11 10:43 AM, Franklin, Matthew B. wrote:
>>>> I have created JIRA issues for all of the tasks that Ate laid out that
>>>> were assignable. The remaining (see below) are community discussions
>>>> that
>>>> need to take place:
>>>>
>>>> * Discuss and decide what to release, e.g. just a source or also a
>>>> binary (demo)?
>>>>
>>>> * Appoint a release manager
>>>>
>>>> We also have two issues still in progress:
>>>>
>>>> * Delete Widgets
>>>>
>>>> * User Prefs
>>>>
>>>> I would like to set a deadline of Friday for issue completion, assuming
>>>> the community agrees. If the issues are not completed by then, we can
>>>> add
>>>> javascript that alerts that the feature is not implemented and return
>>>> statements so that we don't have to roll back any code.
>>>>
>>>> This deadline will allow us to complete release tasks next week so that
>>>> we
>>>> can hit the 15th release date.
>>>>
>>>> -Matt
>>>>
>>>>
>>>>
>>>> On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>>
>>>>> On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>>>> Hi Ate, which comments?
>>>>>>
>>>>>> For instance:
>>>>>> http://markmail.org/message/7dfxwgryq7hp334l
>>>>>> and
>>>>>> http://markmail.org/message/vn2227zm2loxojkq
>>>>>>
>>>>>> (same thread)
>>>>>>
>>>>
>>>>
>>>> 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/
iQEcBAEBAgAGBQJN7TvsAAoJEEfVXEODPFIDPNoH/RPd4AhgrFspghbF7PBaUgwe
+2c8JbV+NaF+eUgQkgZ1xWKRrEVhVevoaX9Yh2RumSzJfonYDThZjoQBGXY2ssbJ
pgUWxZ/vvriKZYC6wPojqmJl9Bil1MThmIuaIsvmb43ftj+IIkrOMOKNT6TQsoYU
wJIDj8IlkmDQsDMSxtG1y+7Qbrzvyt/xQDVcVqKCntbL5ZUTp+aMck4ONReOwtQE
mV+FV3cHxWdLq585DFaXcaf0ijjk6CBf3cx6i6BywyHHd87Xh8/EeF9CIH2ocwDP
4XKZTD/PbV+j6lzEoRYQvDvU71CeCHhPQ50kCgdJ3s5qvgMdcaohJegU0NoxF5U=
=dBN2
-----END PGP SIGNATURE-----
Re: First Release
Posted by Scott Wilson <sc...@gmail.com>.
On 6 Jun 2011, at 19:50, Franklin, Matthew B. wrote:
>
> On 6/1/11 2:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I don't have strong opinions on source versus binary releases at this
>> point, but I am wondering how they work. For a source release, would we
>> bundle up a tar/zip and put it on an Apache mirror or just tag it in SVN?
>> For a binary release, would we just put up a WAR or would we package
>> tomcat+rave+shindig-snapshot? What other steps are required/recommended
>> (zip/md5/pgp)?
>
> I like the idea of packaging tomcat with the two war files so that you can
> just execute the tomcat start script. If we think this is a good idea,
> can we wire this into a maven goal like release? Could we also add
> anything required to push the release to the correct location on
> people.apache.org? The more we can automate the better. It would be nice
> to have a release guide that said something like:
>
> 1) checkout the source
> 2) execute mvn stage
> 3) vote
> 4) execute mvn release
>
> :)
>
For Wookie we created a "standalone" download with embedded Derby DB and Jetty app server as well as the WAR and src versions. Apache Solr does something similar.
>>
>>
>> Having said that, I favor going through the full release steps for both
>> the binary and source. This is early but it will make sure we understand
>> the process when things are further along.
+1
Making the release process as simple and as automated as possible will encourage more frequent releases.
>
> What about javadoc?
>
>>
>>
>> Marlon
>>
>>
>> On 6/1/11 10:43 AM, Franklin, Matthew B. wrote:
>>> I have created JIRA issues for all of the tasks that Ate laid out that
>>> were assignable. The remaining (see below) are community discussions
>>> that
>>> need to take place:
>>>
>>> * Discuss and decide what to release, e.g. just a source or also a
>>> binary (demo)?
>>>
>>> * Appoint a release manager
>>>
>>> We also have two issues still in progress:
>>>
>>> * Delete Widgets
>>>
>>> * User Prefs
>>>
>>> I would like to set a deadline of Friday for issue completion, assuming
>>> the community agrees. If the issues are not completed by then, we can
>>> add
>>> javascript that alerts that the feature is not implemented and return
>>> statements so that we don't have to roll back any code.
>>>
>>> This deadline will allow us to complete release tasks next week so that
>>> we
>>> can hit the 15th release date.
>>>
>>> -Matt
>>>
>>>
>>>
>>> On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>>>
>>>> On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>>> Hi Ate, which comments?
>>>>>
>>>>> For instance:
>>>>> http://markmail.org/message/7dfxwgryq7hp334l
>>>>> and
>>>>> http://markmail.org/message/vn2227zm2loxojkq
>>>>>
>>>>> (same thread)
>>>>>
>>>
>>>
>>> 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/
>>
>> iQEcBAEBAgAGBQJN5oaYAAoJEEfVXEODPFIDxToH/jDiRGX7har1psVhb82TuSPd
>> A2SkXHCcn45Cg8yWiEDRo1yt3/230PcGTBhAkK5zauvIw200j47t6aCRLVPKL/EN
>> uDvPAXGQ9V9bLupeODVLzpNsXiFEZVwW8XMIg7xtOIuqYqM86aOXqyplqzaxYZuW
>> +3zyZ5/r1IprUJldwIeUvMxyDJ3zmZTbm25SFmBDSlnBmYriO2K5nXUtr9v8Mh5l
>> N3lL2qEq+ll5Zlh+5Ag2E4JnczLb1jzci4Pr98UUQTJgK3c3y3Y3EyO/jVTDYiul
>> wPEovMQg+0iQaQC3TtK7f/taVa3fgQ3aRJkNnvQYyzZyIJ9hGDbkzeeu7cdj4UE=
>> =v0Bs
>> -----END PGP SIGNATURE-----
>
Re: First Release
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 6/1/11 2:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I don't have strong opinions on source versus binary releases at this
>point, but I am wondering how they work. For a source release, would we
>bundle up a tar/zip and put it on an Apache mirror or just tag it in SVN?
> For a binary release, would we just put up a WAR or would we package
>tomcat+rave+shindig-snapshot? What other steps are required/recommended
>(zip/md5/pgp)?
I like the idea of packaging tomcat with the two war files so that you can
just execute the tomcat start script. If we think this is a good idea,
can we wire this into a maven goal like release? Could we also add
anything required to push the release to the correct location on
people.apache.org? The more we can automate the better. It would be nice
to have a release guide that said something like:
1) checkout the source
2) execute mvn stage
3) vote
4) execute mvn release
:)
>
>
>Having said that, I favor going through the full release steps for both
>the binary and source. This is early but it will make sure we understand
>the process when things are further along.
What about javadoc?
>
>
>Marlon
>
>
>On 6/1/11 10:43 AM, Franklin, Matthew B. wrote:
>> I have created JIRA issues for all of the tasks that Ate laid out that
>> were assignable. The remaining (see below) are community discussions
>>that
>> need to take place:
>>
>> * Discuss and decide what to release, e.g. just a source or also a
>> binary (demo)?
>>
>> * Appoint a release manager
>>
>> We also have two issues still in progress:
>>
>> * Delete Widgets
>>
>> * User Prefs
>>
>> I would like to set a deadline of Friday for issue completion, assuming
>> the community agrees. If the issues are not completed by then, we can
>>add
>> javascript that alerts that the feature is not implemented and return
>> statements so that we don't have to roll back any code.
>>
>> This deadline will allow us to complete release tasks next week so that
>>we
>> can hit the 15th release date.
>>
>> -Matt
>>
>>
>>
>> On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>>
>>> On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>> Hi Ate, which comments?
>>>>
>>>> For instance:
>>>> http://markmail.org/message/7dfxwgryq7hp334l
>>>> and
>>>> http://markmail.org/message/vn2227zm2loxojkq
>>>>
>>>> (same thread)
>>>>
>>
>>
>> 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/
>
>iQEcBAEBAgAGBQJN5oaYAAoJEEfVXEODPFIDxToH/jDiRGX7har1psVhb82TuSPd
>A2SkXHCcn45Cg8yWiEDRo1yt3/230PcGTBhAkK5zauvIw200j47t6aCRLVPKL/EN
>uDvPAXGQ9V9bLupeODVLzpNsXiFEZVwW8XMIg7xtOIuqYqM86aOXqyplqzaxYZuW
>+3zyZ5/r1IprUJldwIeUvMxyDJ3zmZTbm25SFmBDSlnBmYriO2K5nXUtr9v8Mh5l
>N3lL2qEq+ll5Zlh+5Ag2E4JnczLb1jzci4Pr98UUQTJgK3c3y3Y3EyO/jVTDYiul
>wPEovMQg+0iQaQC3TtK7f/taVa3fgQ3aRJkNnvQYyzZyIJ9hGDbkzeeu7cdj4UE=
>=v0Bs
>-----END PGP SIGNATURE-----
Re: First Release
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I don't have strong opinions on source versus binary releases at this point, but I am wondering how they work. For a source release, would we bundle up a tar/zip and put it on an Apache mirror or just tag it in SVN? For a binary release, would we just put up a WAR or would we package tomcat+rave+shindig-snapshot? What other steps are required/recommended (zip/md5/pgp)?
Having said that, I favor going through the full release steps for both the binary and source. This is early but it will make sure we understand the process when things are further along.
Marlon
On 6/1/11 10:43 AM, Franklin, Matthew B. wrote:
> I have created JIRA issues for all of the tasks that Ate laid out that
> were assignable. The remaining (see below) are community discussions that
> need to take place:
>
> * Discuss and decide what to release, e.g. just a source or also a
> binary (demo)?
>
> * Appoint a release manager
>
> We also have two issues still in progress:
>
> * Delete Widgets
>
> * User Prefs
>
> I would like to set a deadline of Friday for issue completion, assuming
> the community agrees. If the issues are not completed by then, we can add
> javascript that alerts that the feature is not implemented and return
> statements so that we don't have to roll back any code.
>
> This deadline will allow us to complete release tasks next week so that we
> can hit the 15th release date.
>
> -Matt
>
>
>
> On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>
>> On 06/01/2011 02:18 PM, Marlon Pierce wrote:
> Hi Ate, which comments?
>>>
>>> For instance:
>>> http://markmail.org/message/7dfxwgryq7hp334l
>>> and
>>> http://markmail.org/message/vn2227zm2loxojkq
>>>
>>> (same thread)
>>>
>
>
> 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/
iQEcBAEBAgAGBQJN5oaYAAoJEEfVXEODPFIDxToH/jDiRGX7har1psVhb82TuSPd
A2SkXHCcn45Cg8yWiEDRo1yt3/230PcGTBhAkK5zauvIw200j47t6aCRLVPKL/EN
uDvPAXGQ9V9bLupeODVLzpNsXiFEZVwW8XMIg7xtOIuqYqM86aOXqyplqzaxYZuW
+3zyZ5/r1IprUJldwIeUvMxyDJ3zmZTbm25SFmBDSlnBmYriO2K5nXUtr9v8Mh5l
N3lL2qEq+ll5Zlh+5Ag2E4JnczLb1jzci4Pr98UUQTJgK3c3y3Y3EyO/jVTDYiul
wPEovMQg+0iQaQC3TtK7f/taVa3fgQ3aRJkNnvQYyzZyIJ9hGDbkzeeu7cdj4UE=
=v0Bs
-----END PGP SIGNATURE-----
Re: First Release
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
I have created JIRA issues for all of the tasks that Ate laid out that
were assignable. The remaining (see below) are community discussions that
need to take place:
* Discuss and decide what to release, e.g. just a source or also a
binary (demo)?
* Appoint a release manager
We also have two issues still in progress:
* Delete Widgets
* User Prefs
I would like to set a deadline of Friday for issue completion, assuming
the community agrees. If the issues are not completed by then, we can add
javascript that alerts that the feature is not implemented and return
statements so that we don't have to roll back any code.
This deadline will allow us to complete release tasks next week so that we
can hit the 15th release date.
-Matt
On 6/1/11 9:12 AM, "Ate Douma" <at...@douma.nu> wrote:
>On 06/01/2011 02:18 PM, Marlon Pierce wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Ate, which comments?
>
>For instance:
> http://markmail.org/message/7dfxwgryq7hp334l
>and
> http://markmail.org/message/vn2227zm2loxojkq
>
>(same thread)
>
>>
>>
>> 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-----
>
Re: First Release
Posted by Ate Douma <at...@douma.nu>.
On 06/01/2011 02:18 PM, Marlon Pierce wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Ate, which comments?
For instance:
http://markmail.org/message/7dfxwgryq7hp334l
and
http://markmail.org/message/vn2227zm2loxojkq
(same thread)
>
>
> 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-----
Re: First Release
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----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-----
Re: First Release
Posted by Ate Douma <at...@douma.nu>.
Matt, all,
I've taken the liberty to test drive the current Rave trunk extensively this
morning and AFAIK all basic features and JIRA issues which were marked as
"Resolved" seems to work just fine to me.
I already did a brief review of the code and test-cases, and although I must
admit I didn't have the time to go and review every single bit and line of code,
it seems pretty good (and clean) to me. Definitely cool and good enough for our
first (incubating) release.
So I simply closed all resolved issues :)
Of course, if someone knows about or encounters issues with them which should be
fixed before the 0.1-INCUBATING release, just reopen them.
Otherwise I suggest creating a new issue which can be picked up again and fixed
after the release.
Great stuff so far guys!
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
>>
>
Re: First Release
Posted by Ate Douma <at...@douma.nu>.
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
>