On 6 Jun 2011, at 19:50, Franklin, Matthew B. wrote: > > On 6/1/11 2:36 PM, "Marlon Pierce" <[email protected]> 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" <[email protected]> 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----- >
