On 6/6/11 6:37 PM, "Ate Douma" <[email protected]> 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 <[email protected]> >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" <[email protected]> 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" <[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/ >> >> iQEcBAEBAgAGBQJN7TvsAAoJEEfVXEODPFIDPNoH/RPd4AhgrFspghbF7PBaUgwe >> +2c8JbV+NaF+eUgQkgZ1xWKRrEVhVevoaX9Yh2RumSzJfonYDThZjoQBGXY2ssbJ >> pgUWxZ/vvriKZYC6wPojqmJl9Bil1MThmIuaIsvmb43ftj+IIkrOMOKNT6TQsoYU >> wJIDj8IlkmDQsDMSxtG1y+7Qbrzvyt/xQDVcVqKCntbL5ZUTp+aMck4ONReOwtQE >> mV+FV3cHxWdLq585DFaXcaf0ijjk6CBf3cx6i6BywyHHd87Xh8/EeF9CIH2ocwDP >> 4XKZTD/PbV+j6lzEoRYQvDvU71CeCHhPQ50kCgdJ3s5qvgMdcaohJegU0NoxF5U= >> =dBN2 >> -----END PGP SIGNATURE----- >>
