rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject RE: Need some apache+maven advise Re: First Release
Date Tue, 07 Jun 2011 01:31:43 GMT
Based on the general@incubator activity re OOo we know you are still here.....and have your
hands full :)



Sent with Good (www.good.com)


 -----Original Message-----
From: 	Ross Gardler [mailto:rgardler@apache.org]
Sent:	Monday, June 06, 2011 07:46 PM Eastern Standard Time
To:	rave-dev@incubator.apache.org
Subject:	Re: Need some apache+maven advise Re: First Release

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"<mpierce@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"<ate@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-----

Mime
View raw message