rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: First Release
Date Mon, 06 Jun 2011 21:15:57 GMT

On 6 Jun 2011, at 19:50, Franklin, Matthew B. wrote:

> 
> On 6/1/11 2:36 PM, "Marlon Pierce" <mpierce@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" <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/
>> 
>> iQEcBAEBAgAGBQJN5oaYAAoJEEfVXEODPFIDxToH/jDiRGX7har1psVhb82TuSPd
>> A2SkXHCcn45Cg8yWiEDRo1yt3/230PcGTBhAkK5zauvIw200j47t6aCRLVPKL/EN
>> uDvPAXGQ9V9bLupeODVLzpNsXiFEZVwW8XMIg7xtOIuqYqM86aOXqyplqzaxYZuW
>> +3zyZ5/r1IprUJldwIeUvMxyDJ3zmZTbm25SFmBDSlnBmYriO2K5nXUtr9v8Mh5l
>> N3lL2qEq+ll5Zlh+5Ag2E4JnczLb1jzci4Pr98UUQTJgK3c3y3Y3EyO/jVTDYiul
>> wPEovMQg+0iQaQC3TtK7f/taVa3fgQ3aRJkNnvQYyzZyIJ9hGDbkzeeu7cdj4UE=
>> =v0Bs
>> -----END PGP SIGNATURE-----
> 


Mime
View raw message