You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@eagle.apache.org by Julian Hyde <jh...@apache.org> on 2016/01/22 17:44:21 UTC
Release?
Hi eagle community,
How’s progress on the first Eagle release?
The Eagle project is progressing at an admirable rate in terms of features and community engagement. However, you’ve not yet made a release. Making a release is more tricky than you would imagine — and it’s usually due to licensing issues, not due to bugs or other code issues — so the first one takes a month or two. But making releases is a key part of learning the Apache way and demonstrating that you’re ready to graduate; and, it helps to build community.
Also remember that the project does not need to be “perfect”. Your first release will have lots of bugs in it. If it compiles and has a README, that is enough.
Julian
Re: Release?
Posted by Julian Hyde <jh...@apache.org>.
It’s worth reading through Calcite’s process, not that you need to follow it, but to find out what you don’t know.
https://calcite.apache.org/docs/howto.html#publishing-a-release-for-calcite-committers
Julian
> On Jan 22, 2016, at 2:15 PM, Prasad Mujumdar <pr...@apache.org> wrote:
>
> ah ok. Thanks! I wasn't aware of the release plugin. will try it out.
>
> thanks
> Prasad
>
>
> On Fri, Jan 22, 2016 at 2:08 PM, Julian Hyde <jh...@apache.org> wrote:
>
>> You should consider using the maven release plugin. A lot of those steps
>> you describe can be replaced with
>>
>> mvn -Papache release:prepare
>> mvn -Papache release:perform
>>
>> That said, that can wait until the second release. For the first release,
>> making source tarball (with the requisite LICENSE, NOTICE files, etc.) by
>> any means is acceptable!
>>
>> Julian
>>
>>
>>> On Jan 22, 2016, at 1:50 PM, Prasad Mujumdar <p3...@gmail.com>
>> wrote:
>>>
>>> Looks like the formatting is bit messed up. My apologies. Hopefully it
>>> will be better formatted on the wiki.
>>>
>>> thanks
>>> Prasad
>>>
>>>
>>> On Fri, Jan 22, 2016 at 1:48 PM, Prasad Mujumdar <pr...@apache.org>
>> wrote:
>>>
>>>>
>>>> @Julian, strong +1 to making release soon. Thanks for bring that up.
>>>> @Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based
>> on
>>>> my experience with other incubating project releases (as Julian
>> mentioned,
>>>> primarily based on Justin's feedback in past) there some work that still
>>>> needed. We EAGLE-115 to tracking that. I will try to prioritize getting
>> a
>>>> patch ready for that.
>>>>
>>>> Looks like we don't have a 'how to release' page that outlines the
>> release
>>>> steps. Here's a draft that I put together (using some of the existing
>>>> incubator project templates).
>>>> @Ed and @Arun, if one of you could give me access to the wiki, I can
>>>> upload the draft there so that community members can directly edit the
>> page.
>>>>
>>>>
>>>> *How to Release*
>>>>
>>>> This document describes the release process for Apache Eagle release
>> from
>>>> Incubator. This is a working progress document till we have a few
>> releases
>>>> and ironed out the process.
>>>>
>>>> *Release manager*
>>>>
>>>> Someone from the community should volunteer to become a release
>>>> manager(RM) and coordinate the release process. The release steps listed
>>>> below will mostly be carried out by the release manager. Ideally this
>>>> person should be a committer or PPMC member, however it should be fine
>> for
>>>> a contributor to take that responsibility with one of the committer or
>> PPMC
>>>> to mentor him/her to make the release.
>>>>
>>>> The Release Manager (RM) must go through the policy document to
>> understand
>>>> all the tasks and responsibilities of running a release. Frequently
>> asked
>>>> questions for making Apache releases are available on Releases FAQ
>>>> <http://www.apache.org/dev/release.html>page. Guide to Release
>> Management
>>>> During Incubation
>>>> <
>> http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager>
>> also
>>>> has good information on best practices for releasing artifacts from an
>>>> incubating Apache project.
>>>>
>>>>
>>>>
>>>> *Give a heads up*
>>>>
>>>> The RM should first create an umbrella issue to create the release and
>>>> then setup a timeline for release branch point. The community should
>> decide
>>>> on the cutoff point for the release branch on the release discussion
>>>> thread.
>>>>
>>>> To: dev@eagle.incubator.apache.org
>>>>
>>>> Subject: Work on $release release has started
>>>>
>>>>
>>>> Created a tracking jira (jira#) for the eagle $release and plan to
>> branch
>>>> tentatively on $date.
>>>>
>>>>
>>>>
>>>> What would you like to see included?
>>>>
>>>> Thanks,
>>>>
>>>> $RM
>>>>
>>>> *Sanitize JIRA*
>>>>
>>>> 1. Before a release is done, make sure that any issues that are
>>>> *fixed *have their fix version setup correctly. Run the following JIRA
>>>> query to see which resolved issues do not have their fix version set
>>>> up correctly:
>>>>
>>>> 2. project = eagle and resolution = fixed and fixVersion is empty
>>>> 3.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The result of the above query should be empty. If some issues do
>>>> show up in this query that have been fixed since the last release,
>>>> please bulk-edit them to set the fix version to '<releaseVersion>'.
>>>> 4. Move the unresolved jiras to the next release
>>>>
>>>> 5. project = eagle and fixVersion = <releaseVersion> and status not
>>>> in( resolved, done, Accepted, Closed)
>>>> 6.
>>>>
>>>>
>>>>
>>>> 7. You can also run the following query to make sure that the
>>>> issues fixed for the to-be-released version look accurate:
>>>>
>>>> 8. project = eagle and fixVersion = '<releaseVersion>'
>>>> 9.
>>>>
>>>>
>>>>
>>>> 10. Finally, check out the output of the *JIRA release note tool*
>>>> <
>> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectName=eagle>
>> to
>>>> see which JIRAs are included in the release, in order to do a sanity
>> check.
>>>>
>>>> *Creating Release Artifacts*
>>>>
>>>> *Communicate with the community*
>>>>
>>>> 1. Send an email to dev list to notify that you are about to
>>>> branch. Ask to hold off any commits until this is finished.
>>>> 2. Send another email after branching is done.
>>>>
>>>> *Preparing branches*
>>>>
>>>> 1. Create a release branch
>>>> 1. Clone fresh repository copy
>>>>
>>>> 2. git clone https://
>>>> git-wip-us.apache.org/repos/asf/incubator-eagle.git
>>>> cd eagle
>>>> 3.
>>>>
>>>>
>>>>
>>>> 4. Checkout master branch
>>>>
>>>> 5. git checkout master
>>>> 6.
>>>>
>>>>
>>>>
>>>> 7. Check that current HEAD points to commit on which you want to
>>>> base new release branch. Checkout particular commit if not.
>>>>
>>>> 8. git log # Check current branch history. HEAD should point to
>>>> commit that you want to be base for your release branch
>>>> git checkout <releaseBaseCommit> # Check out particular commit that
>>>> should be base for release branch if -^
>>>> 9.
>>>>
>>>>
>>>>
>>>> 10. Create new release branch with name "branch-$version"
>>>>
>>>> 11. git checkout -b branch-<releaseVersion>
>>>> 12.
>>>>
>>>>
>>>>
>>>> 13. Update CHANGELOG in the trunk to indicate the changes going
>>>> into the new version.
>>>> The change list can be swiped from the *JIRA release note tool*
>>>> <
>> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314720
>>>
>>>> (use the "text" format for the change log). See JIRA Cleanup above
>>>> to ensure that the release notes generated by this tool are what
>> you are
>>>> expecting.
>>>> 14. Remove -SNAPSHOT from the release branch and commit
>>>>
>>>> 15. find . -name pom.xml | xargs sed -i ""
>>>> -e "s/X.Y.0-SNAPSHOT/X.Y.0/" or mvn versions:set
>>>> -DnewVersion=X.Y.0 -DgenerateBackupPoms=false
>>>> git add .
>>>> git commit -m "EAGLE-XXXX: Removing -SNAPSHOT from X.Y release
>>>> branch"
>>>> 16.
>>>>
>>>>
>>>>
>>>> 17. Check your changes and push new branch to Apache repository
>>>>
>>>> 18. mvn *install*
>>>> git push origin branch-<releaseVersion>
>>>> 19.
>>>>
>>>>
>>>>
>>>> 20. Check that branch was correctly propagated to Apache
>> repository.
>>>> 2. Prepare the master for next release (<releaseVersion+1>)
>>>>
>>>> 3. git checkout master
>>>> find . -name pom.xml | xargs sed -i "" -e
>> "s/<releaseVersion>-SNAPSHOT/
>>>> <releaseVersion+1>-SNAPSHOT/" or mvn versions:set
>>>> -DnewVersion=1.3.0-SNAPSHOT -DgenerateBackupPoms=false
>>>> git add .
>>>> git commit -m "EAGLE-XXXX: Preparing for eagle <releaseVersion+1>
>>>> development"
>>>> git push origin master:master
>>>> 4.
>>>>
>>>>
>>>>
>>>> 5. Send an email announcing new branch
>>>> To: dev@eagle.incubator.apache.org
>>>> 6. Subject: New release branch <releaseVersion>
>>>> 7.
>>>> 8.
>>>> 9. I've just created new release branch for upcoming <releaseVersion>
>>>> incubating release.
>>>> 10. Please continue committing to master branch as usual.
>>>> 11. I'll cherry-pick commits to branch-<releaseVersion> on per needed
>>>> basis.
>>>> 12.
>>>> 13.
>>>> 14. Thanks,
>>>> 15. $RM
>>>>
>>>>
>>>> *Create release tar balls*
>>>>
>>>> 1. Check out release branch
>>>>
>>>> 2. git checkout branch-<ReleaseVersion>
>>>> 3.
>>>>
>>>>
>>>>
>>>> 4. Create tag on this commit to identify precise point where the
>>>> RC was generated and push this tag to main repository
>>>>
>>>> 5. git tag -a release-<ReleaseVersion> -m "Eagle <ReleaseVersion>
>>>> incubating release"
>>>> #Make sure compiles/tests run fine and rat check is fine
>>>> mvn clean install -DskipTests
>>>> mvn test
>>>> mvn verify -DskipTests (to do the rat check)
>>>> git push origin release-<ReleaseVersion>
>>>> 6.
>>>>
>>>>
>>>>
>>>> 7. If an rc1, rc2, etc is needed, delete that tag before creating a
>>>> new one:
>>>>
>>>> 8. git tag -d release-<releaseVersion>
>>>> git push origin :refs/tags/release-<releaseVersion>
>>>> 9.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 10. Create temporary directory where you'll be preparing all required
>>>> artifacts
>>>>
>>>> 11. mkdir -p /tmp/eagle-release-preparations
>>>> 12.
>>>>
>>>>
>>>>
>>>> 13. Create source artifact and move it to your temporary directory
>>>>
>>>> 14. git archive --format=tar
>> --prefix=apache-eagle-<releasVersion>-incubating-src/
>>>> HEAD | gzip > /tmp/eagle-release-preparations/apache-eagle-
>>>> <releaseVersion>-incubating-src.tar.gz
>>>> 15.
>>>>
>>>>
>>>>
>>>> *Sanity Check*
>>>> 1. Make sure the tar and the rc match
>>>>
>>>> 2. cd /tmp/eagle-release-preparations
>>>> tar -xvf apache-eagle-<releaseVersion>-incubating-src.tar.gz
>>>>
>>>> #Do a fresh clone of the tag
>>>> git clone https://
>>>> git-wip-us.apache.org/repos/asf/incubator-eagle.git
>>>> <http://git-wip-us.apache.org/repos/asf/incubator-sentry.git>
>>>> cd incubator-eagle/
>>>> git checkout tags/release-<releaseVersion>
>>>> cd ..
>>>> diff -r incubator-eagle
>> apache-eagle-<releaseVersion>-incubating-src
>>>> 3.
>>>>
>>>>
>>>>
>>>> 4. Make sure code compiles and tests pass on the untared src.
>>>>
>>>> 5. cd apache-eagle-<releaseVersion>-incubating-src
>>>> mvn clean install -DskipTests
>>>> mvn test
>>>> mvn verify -DskipTests (to do the rat check)
>>>> 6.
>>>>
>>>>
>>>>
>>>> *Create signatures and check sums *
>>>>
>>>> All artifacts must be signed and checksummed. In order to sign a
>>>> release you will need a PGP key. You should get your key signed by
>> a few
>>>> other people. You will also need to recv their keys from a public
>> key
>>>> server. See the Apache release signing
>>>> <https://www.apache.org/dev/release-signing> page for more
>>>> details. If you add your PGP key fingerprint to your Apache
>> profile, your
>>>> key should automatically be added to
>>>> https://people.apache.org/keys/group/eagle.asc
>>>> <https://people.apache.org/keys/group/sentry.asc>
>>>>
>>>> 1. Change your working directory to the temporal one
>>>>
>>>>
>>>>
>>>> cd /tmp/eagle-release-preparations
>>>>
>>>>
>>>>
>>>> 2. Sing each file with your key
>>>>
>>>>
>>>>
>>>> for file in *.tar.gz; do gpg --armor --output $file.asc
>> --detach-sig
>>>>
>>>> $file; done
>>>>
>>>>
>>>>
>>>> 3. You can immediately verify your signature
>>>>
>>>>
>>>>
>>>> for file in *.tar.gz; do gpg --verify $file.asc $file; done
>>>>
>>>>
>>>>
>>>> 4. Create md5 check sum
>>>>
>>>>
>>>>
>>>> for file in *.tar.gz; do md5sum $file > $file.md5; done
>>>>
>>>>
>>>>
>>>> 5. Create sha1 check sum
>>>>
>>>>
>>>>
>>>> for file in *.tar.gz; do sha1sum $file > $file.sha; done
>>>>
>>>>
>>>>
>>>> *Upload artifacts*
>>>>
>>>> Upload artifacts and all created check sums with signatures to
>>>> https://dist.apache.org/repos/dist/dev/incubator/eagle
>>>> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
>>>>
>>>> *Update KEYS file*
>>>>
>>>> If your PGP key is not yet in the project's KEYS file, you need to
>>>> first add that in. To do this, checkout the KEYS file and update
>> it using
>>>> the following commands:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> $ svn co
>> https://dist.apache.org/repos/dist/release/incubator/eagle
>>>> <https://dist.apache.org/repos/dist/release/incubator/sentry>
>>>> eagle-release
>>>>
>>>> $ cd eagle-release
>>>>
>>>> $ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >>
>>>> KEYS
>>>>
>>>> $ svn commit -m "Adding PGP public key to KEYS file" KEYS
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Once this file has been updated, you need to publish it in the
>>>> appropriate dist directory for the project on
>>>> http://www.apache.org/dist. To do this, you must copy the file as
>>>> follows:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> $ scp KEYS people.apache.
>>>> org:/www/www.apache.org/dist/incubator/eagle/KEYS
>>>> <http://org/www/www.apache.org/dist/incubator/sentry/KEYS>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This will take some time to propagate in which you can continue
>>>> with the other steps of the release process.
>>>>
>>>> Verifying a release candidate
>>>>
>>>> Following are the typical things we need to verify before voting on
>>>> a release candidate. And the release manager should verify them
>> too before
>>>> calling out a vote.
>>>> - Make sure RCs are hosted @
>>>> https://dist.apache.org/repos/dist/dev/incubator/eagle
>>>> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
>>>> - Should be in format apache-$project-$version-incubating.tar.gz
>>>> - Verify Signatures and hashes. You may have to import the
>>>> public key of the release manager to verify the signatures. (gpg
>>>> --recv-key <last8 of public key>)
>>>> - git tag matches the released bits (diff -rf)
>>>> - Can compile successfully from source
>>>> - Verify DISCLAIMER, NOTICE and LICENCE (year etc)
>>>> - All files have correct headers (Rat check should be clean -
>>>> mvn verify)
>>>> - Make sure there are no conflicting licenses (TODO: how)
>>>> - No jar files or the like in the release
>>>> -
>>>>
>>>> Running the vote
>>>>
>>>>
>>>> Voting has to be done on dev@eagle.incubator.apache.org
>>>> <de...@sentry.incubator.apache.org> list followed by
>>>> general@incubator.apache.org. You can close the vote after voting
>>>> period expires and you accumulate sufficient votes.
>>>>
>>>> Call for voting on dev list (PPMC)
>>>>
>>>> To: dev@eagle.incubator.apache.org
>>>>
>>>> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
>>>>
>>>> This is the incubator release of Apache Eagle, version
>>>> <releaseVersion>-incubating.
>>>>
>>>> It fixes the following issues: http://s.apache.org/VlU
>>>>
>>>>
>>>> Source files :
>>>> https://dist.apache.org/repos/dist/dev/incubator/eagle/eagle-
>>>> <releaseVersion>/
>>>>
>>>>
>>>> Tag to be voted on (rc#):
>>>>
>> https://git-wip-us.apache.org/repos/asf/incubator-eagle/?p=incubator-eagle.git;a=commit;h=
>>>> <commit-hash-of-the-tag>
>>>>
>>>> Eagle's KEYS containing the PGP key we used to sign the release:
>>>>
>>>> https://people.apache.org/keys/group/eagle.asc (or
>>>> http://www.apache.org/dist/incubator/eagle/KEYS for non
>> committers)
>>>>
>>>>
>>>> Note that this is a source only release and we are voting on the
>>>> source: tag=release-<releaseVersion>, SHA=<release_SHA> (You can
>> get the
>>>> hash of the tag by doing "git rev-list release-<releaseVersion> |
>> head -n
>>>> 1" )
>>>>
>>>>
>>>> Vote will be open for 72 hours.
>>>>
>>>>
>>>> [ ] +1 approve
>>>>
>>>> [ ] +0 no opinion
>>>>
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> $RM
>>>>
>>>> The vote has to be called first on the dev list. Upon receiving 3
>>>> +1s from the PPMC, reply to the voting thread and prefixing
>>>> *[RESULT]* to the subject line with the results.
>>>>
>>>> To: dev@eagle.incubator.apache.org
>>>>
>>>> Subject: [RESULT][VOTE] Release eagle incubating version
>>>> <releaseVersion>
>>>>
>>>>
>>>>
>>>> Voting is now closed and has passed with the following tally.
>>>>
>>>>
>>>> PPMC +1: <PPMC voters>
>>>>
>>>> Others +1: <other community members who voted>
>>>>
>>>>
>>>> A vote will now be called on general@incubator.apache.org.
>>>>
>>>>
>>>>
>>>> $RM
>>>>
>>>> Voting on @general
>>>>
>>>> The vote should be now called on general@incubator.apache.org
>>>> <ge...@incubator.apache.org.> for IPMC votes. Binding votes are
>>>> from IPMC member, and non-binding votes are from PPMC members.
>>>>
>>>> To: general@incubator.apache.org
>>>>
>>>> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
>>>>
>>>>
>>>>
>>>> This is the first incubator release of Apache Eagle, version
>>>>
>>>> <releaseVersion>-incubating.
>>>>
>>>>
>>>>
>>>> <Same as above...>
>>>>
>>>>
>>>> A vote on releasing this package has already passed in Apache Eagle
>>>>
>>>> PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...).
>>>>
>>>>
>>>> Vote will be open for 72 hours.
>>>>
>>>>
>>>> [ ] +1 approve
>>>>
>>>> [ ] +0 no opinion
>>>>
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>>
>>>> <RM>
>>>>
>>>>
>>>> [1] -
>>>>
>>>>
>>>>
>> http://markmail.org/search/?q=eagle%20vote%20release#query:eagle%20vote%20release+page:1+mid:sqrwevgsxakqatqk+state:results
>>>>
>>>> By convention, vote closing email is sent to
>>>> general@incubator.apache.org by replying to the voting thread and
>>>> prefixing *[RESULT]* to the subject line. This method keeps the
>>>> closing email in the same thread with the voting emails for better
>> record
>>>> keeping in the mail archive.
>>>>
>>>>
>>>>
>>>> Example close email:
>>>>
>>>> To: general@incubator.apache.org
>>>>
>>>> Subject: [RESULT][VOTE] Release Eagle incubating version
>>>> <releaseVersion>
>>>>
>>>>
>>>>
>>>> Voting is now closed and has passed with the following tally,
>>>>
>>>>
>>>> Binding +1s: <IPMC binding voter list>
>>>>
>>>> Non binding +1s: <PPMC voter list>
>>>>
>>>>
>>>> Thanks to everyone who voted! I'll continue with the rest of the
>>>> release process.
>>>>
>>>>
>>>>
>>>> $RM
>>>>
>>>> Rolling out the Release
>>>>
>>>>
>>>> Close JIRA version
>>>>
>>>> You need to close the release in JIRA so that everyone knows that
>>>> your version should not be used as "fixVersion" for new bugs. Go to
>>>> JIRA "Administer project" page and follow "Versions" in left menu.
>>>> Table with list of all releases should appear, click on additional
>> menu
>>>> on the right of your release and choose "Release" option. Submit
>>>> release date and you're done.
>>>>
>>>> Upload the artifacts
>>>>
>>>> In order to release you have to checkout release repository
>>>> located on
>>>> https://dist.apache.org/repos/dist/release/incubator/eagle/
>>>> <https://dist.apache.org/repos/dist/release/incubator/sentry/> and
>>>> add release artifacts there.
>>>>
>>>> svn co https://dist.apache.org/repos/dist/release/incubator/eagle/
>>>> eagle-release
>>>>
>>>> cd eagle-release
>>>>
>>>> mkdir <releaseVersion>-incubating/
>>>>
>>>> cp $source_to_your_artifacts <releaseVersion>-incubating/
>>>>
>>>> svn add <releaseVersion>-incubating
>>>>
>>>> It may take up to 24 hours for all mirrors to sync up (
>>>> http://www.apache.org/dyn/closer.cgi/incubator/eagle/
>>>> <http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
>>>>
>>>> Announce the release
>>>>
>>>> Send an email to announce@apache.org (the from: address must be @
>>>> apache.org). For example,
>>>>
>>>> To: announce@apache.org, dev@eagle.incubator.apache.org
>>>>
>>>> Subject: [ANNOUNCE] Apache Eagle <releaseVersion> incubating
>>>> released
>>>>
>>>>
>>>> The Apache Eagle community is happy to announce the release of
>>>> version <releaseVersion>-incubating from the Apache Incubator.
>> Apache Eagle
>>>> is a monitoring framework for Hadoop to identify access to
>> sensitive data,
>>>> recognize malicious activities and take action in real time.
>>>>
>>>> The release bits are available at:
>>>> http://www.apache.org/dyn/closer.cgi/incubator/eagle
>>>>
>>>> The change list is available at: <chageLogLocation>
>>>>
>>>> We would like to thank all contributors who made the release
>>>> possible.
>>>>
>>>>
>>>> Disclaimer
>>>>
>>>> Apache Eagle is an effort undergoing incubation at The Apache
>>>> Software Foundation (ASF), sponsored by the Apache Incubator PMC.
>>>> Incubation is required of all newly accepted projects until a
>> further
>>>> review indicates that the infrastructure, communications, and
>> decision
>>>> making process have stabilized in a manner consistent with other
>> successful
>>>> ASF projects. While incubation status is not necessarily a
>> reflection of
>>>> the completeness or stability of the code, it does indicate that
>> the
>>>> project has yet to be fully endorsed by the ASF.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Eagle Community
>>>>
>>>> Update the website
>>>> 1. Update the website:
>>>> 1. Add the release to the downloads
>>>> <http://eagle.incubator.apache.org/general/downloads.html>
>>>> 2. Add the release to the history page
>>>> <http://eagle.incubator.apache.org/general/history.html>
>>>> 2. Update the "News" section in the podling status page
>>>> <http://incubator.apache.org/projects/eagle.html>.
>>>> 3. Update how to release page with your experience
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <
>> aruncarthick@gmail.com>
>>>> wrote:
>>>>
>>>>> I agree with Julian. Edward is starting to collect the list of features
>>>>> that are ready. I'm guessing Michael Wu will be a good release manager
>> and
>>>>> start getting educated on the apache process.
>>>>>
>>>>> Thanks,
>>>>> Arun
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org>
>> wrote:
>>>>>
>>>>>> It’s difficult to describe the “licensing issues”. I suggest that you
>>>>>> nominate a release manager and that person subscribes to the
>>>>>> general@incubator list [1] and follows the discussions there. Watch
>> the
>>>>>> kind of due diligence that people such as Justin McLean apply to the
>>>>>> releases, e.g. the Freemarker release [2]. (It seems onerous but is
>> much
>>>>>> appreciated by your community, because it means they are getting
>>>>> spotlessly
>>>>>> clean IP.)
>>>>>>
>>>>>> You will need to go through the same process: after a vote on this dev
>>>>>> list, there is a second vote on the generator@incubator list.
>>>>>>
>>>>>> I can’t stress this strongly enough: The actual features (and bugs) in
>>>>> the
>>>>>> first release is very unimportant. It is all about the legal
>> packaging,
>>>>> and
>>>>>> the process by which you make the release. No reason not to start now.
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>> [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
>>>>>>
>>>>>> [2]
>>>>>>
>>>>>
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
>>>>>>
>>>>>>> On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
>>>>>> yonzhang@ebay.com> wrote:
>>>>>>>
>>>>>>> Thanks for initiating this discussion. I also wonder how to do the
>>>>> first
>>>>>>> release, what it the timing, what is the version number and what
>>>>> features
>>>>>>> we should include and what is release notes.
>>>>>>>
>>>>>>> But I am not aware of licensing issues. Does that because that not
>> all
>>>>>> our
>>>>>>> source files are for apache license so we need explicitly tell that
>> in
>>>>>>> public?
>>>>>>>
>>>>>>> I volunteer to collect the features for the first release. A lot more
>>>>>> work
>>>>>>> should be identified while we are progressing.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Edward
>>>>>>>
>>>>>>> On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
>>>>>>>
>>>>>>>> Hi eagle community,
>>>>>>>>
>>>>>>>> How¹s progress on the first Eagle release?
>>>>>>>>
>>>>>>>> The Eagle project is progressing at an admirable rate in terms of
>>>>>>>> features and community engagement. However, you¹ve not yet made a
>>>>>>>> release. Making a release is more tricky than you would imagine ‹
>> and
>>>>>>>> it¹s usually due to licensing issues, not due to bugs or other code
>>>>>>>> issues ‹ so the first one takes a month or two. But making releases
>>>>> is a
>>>>>>>> key part of learning the Apache way and demonstrating that you¹re
>>>>> ready
>>>>>>>> to graduate; and, it helps to build community.
>>>>>>>>
>>>>>>>> Also remember that the project does not need to be ³perfect². Your
>>>>> first
>>>>>>>> release will have lots of bugs in it. If it compiles and has a
>>>>> README,
>>>>>>>> that is enough.
>>>>>>>>
>>>>>>>> Julian
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Arun Karthick
>>>>> 201-850-9399
>>>>>
>>>>
>>>>
>>
>>
Re: Release?
Posted by Prasad Mujumdar <pr...@apache.org>.
ah ok. Thanks! I wasn't aware of the release plugin. will try it out.
thanks
Prasad
On Fri, Jan 22, 2016 at 2:08 PM, Julian Hyde <jh...@apache.org> wrote:
> You should consider using the maven release plugin. A lot of those steps
> you describe can be replaced with
>
> mvn -Papache release:prepare
> mvn -Papache release:perform
>
> That said, that can wait until the second release. For the first release,
> making source tarball (with the requisite LICENSE, NOTICE files, etc.) by
> any means is acceptable!
>
> Julian
>
>
> > On Jan 22, 2016, at 1:50 PM, Prasad Mujumdar <p3...@gmail.com>
> wrote:
> >
> > Looks like the formatting is bit messed up. My apologies. Hopefully it
> > will be better formatted on the wiki.
> >
> > thanks
> > Prasad
> >
> >
> > On Fri, Jan 22, 2016 at 1:48 PM, Prasad Mujumdar <pr...@apache.org>
> wrote:
> >
> >>
> >> @Julian, strong +1 to making release soon. Thanks for bring that up.
> >> @Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based
> on
> >> my experience with other incubating project releases (as Julian
> mentioned,
> >> primarily based on Justin's feedback in past) there some work that still
> >> needed. We EAGLE-115 to tracking that. I will try to prioritize getting
> a
> >> patch ready for that.
> >>
> >> Looks like we don't have a 'how to release' page that outlines the
> release
> >> steps. Here's a draft that I put together (using some of the existing
> >> incubator project templates).
> >> @Ed and @Arun, if one of you could give me access to the wiki, I can
> >> upload the draft there so that community members can directly edit the
> page.
> >>
> >>
> >> *How to Release*
> >>
> >> This document describes the release process for Apache Eagle release
> from
> >> Incubator. This is a working progress document till we have a few
> releases
> >> and ironed out the process.
> >>
> >> *Release manager*
> >>
> >> Someone from the community should volunteer to become a release
> >> manager(RM) and coordinate the release process. The release steps listed
> >> below will mostly be carried out by the release manager. Ideally this
> >> person should be a committer or PPMC member, however it should be fine
> for
> >> a contributor to take that responsibility with one of the committer or
> PPMC
> >> to mentor him/her to make the release.
> >>
> >> The Release Manager (RM) must go through the policy document to
> understand
> >> all the tasks and responsibilities of running a release. Frequently
> asked
> >> questions for making Apache releases are available on Releases FAQ
> >> <http://www.apache.org/dev/release.html>page. Guide to Release
> Management
> >> During Incubation
> >> <
> http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager>
> also
> >> has good information on best practices for releasing artifacts from an
> >> incubating Apache project.
> >>
> >>
> >>
> >> *Give a heads up*
> >>
> >> The RM should first create an umbrella issue to create the release and
> >> then setup a timeline for release branch point. The community should
> decide
> >> on the cutoff point for the release branch on the release discussion
> >> thread.
> >>
> >> To: dev@eagle.incubator.apache.org
> >>
> >> Subject: Work on $release release has started
> >>
> >>
> >> Created a tracking jira (jira#) for the eagle $release and plan to
> branch
> >> tentatively on $date.
> >>
> >>
> >>
> >> What would you like to see included?
> >>
> >> Thanks,
> >>
> >> $RM
> >>
> >> *Sanitize JIRA*
> >>
> >> 1. Before a release is done, make sure that any issues that are
> >> *fixed *have their fix version setup correctly. Run the following JIRA
> >> query to see which resolved issues do not have their fix version set
> >> up correctly:
> >>
> >> 2. project = eagle and resolution = fixed and fixVersion is empty
> >> 3.
> >>
> >>
> >>
> >>
> >>
> >> The result of the above query should be empty. If some issues do
> >> show up in this query that have been fixed since the last release,
> >> please bulk-edit them to set the fix version to '<releaseVersion>'.
> >> 4. Move the unresolved jiras to the next release
> >>
> >> 5. project = eagle and fixVersion = <releaseVersion> and status not
> >> in( resolved, done, Accepted, Closed)
> >> 6.
> >>
> >>
> >>
> >> 7. You can also run the following query to make sure that the
> >> issues fixed for the to-be-released version look accurate:
> >>
> >> 8. project = eagle and fixVersion = '<releaseVersion>'
> >> 9.
> >>
> >>
> >>
> >> 10. Finally, check out the output of the *JIRA release note tool*
> >> <
> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectName=eagle>
> to
> >> see which JIRAs are included in the release, in order to do a sanity
> check.
> >>
> >> *Creating Release Artifacts*
> >>
> >> *Communicate with the community*
> >>
> >> 1. Send an email to dev list to notify that you are about to
> >> branch. Ask to hold off any commits until this is finished.
> >> 2. Send another email after branching is done.
> >>
> >> *Preparing branches*
> >>
> >> 1. Create a release branch
> >> 1. Clone fresh repository copy
> >>
> >> 2. git clone https://
> >> git-wip-us.apache.org/repos/asf/incubator-eagle.git
> >> cd eagle
> >> 3.
> >>
> >>
> >>
> >> 4. Checkout master branch
> >>
> >> 5. git checkout master
> >> 6.
> >>
> >>
> >>
> >> 7. Check that current HEAD points to commit on which you want to
> >> base new release branch. Checkout particular commit if not.
> >>
> >> 8. git log # Check current branch history. HEAD should point to
> >> commit that you want to be base for your release branch
> >> git checkout <releaseBaseCommit> # Check out particular commit that
> >> should be base for release branch if -^
> >> 9.
> >>
> >>
> >>
> >> 10. Create new release branch with name "branch-$version"
> >>
> >> 11. git checkout -b branch-<releaseVersion>
> >> 12.
> >>
> >>
> >>
> >> 13. Update CHANGELOG in the trunk to indicate the changes going
> >> into the new version.
> >> The change list can be swiped from the *JIRA release note tool*
> >> <
> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314720
> >
> >> (use the "text" format for the change log). See JIRA Cleanup above
> >> to ensure that the release notes generated by this tool are what
> you are
> >> expecting.
> >> 14. Remove -SNAPSHOT from the release branch and commit
> >>
> >> 15. find . -name pom.xml | xargs sed -i ""
> >> -e "s/X.Y.0-SNAPSHOT/X.Y.0/" or mvn versions:set
> >> -DnewVersion=X.Y.0 -DgenerateBackupPoms=false
> >> git add .
> >> git commit -m "EAGLE-XXXX: Removing -SNAPSHOT from X.Y release
> >> branch"
> >> 16.
> >>
> >>
> >>
> >> 17. Check your changes and push new branch to Apache repository
> >>
> >> 18. mvn *install*
> >> git push origin branch-<releaseVersion>
> >> 19.
> >>
> >>
> >>
> >> 20. Check that branch was correctly propagated to Apache
> repository.
> >> 2. Prepare the master for next release (<releaseVersion+1>)
> >>
> >> 3. git checkout master
> >> find . -name pom.xml | xargs sed -i "" -e
> "s/<releaseVersion>-SNAPSHOT/
> >> <releaseVersion+1>-SNAPSHOT/" or mvn versions:set
> >> -DnewVersion=1.3.0-SNAPSHOT -DgenerateBackupPoms=false
> >> git add .
> >> git commit -m "EAGLE-XXXX: Preparing for eagle <releaseVersion+1>
> >> development"
> >> git push origin master:master
> >> 4.
> >>
> >>
> >>
> >> 5. Send an email announcing new branch
> >> To: dev@eagle.incubator.apache.org
> >> 6. Subject: New release branch <releaseVersion>
> >> 7.
> >> 8.
> >> 9. I've just created new release branch for upcoming <releaseVersion>
> >> incubating release.
> >> 10. Please continue committing to master branch as usual.
> >> 11. I'll cherry-pick commits to branch-<releaseVersion> on per needed
> >> basis.
> >> 12.
> >> 13.
> >> 14. Thanks,
> >> 15. $RM
> >>
> >>
> >> *Create release tar balls*
> >>
> >> 1. Check out release branch
> >>
> >> 2. git checkout branch-<ReleaseVersion>
> >> 3.
> >>
> >>
> >>
> >> 4. Create tag on this commit to identify precise point where the
> >> RC was generated and push this tag to main repository
> >>
> >> 5. git tag -a release-<ReleaseVersion> -m "Eagle <ReleaseVersion>
> >> incubating release"
> >> #Make sure compiles/tests run fine and rat check is fine
> >> mvn clean install -DskipTests
> >> mvn test
> >> mvn verify -DskipTests (to do the rat check)
> >> git push origin release-<ReleaseVersion>
> >> 6.
> >>
> >>
> >>
> >> 7. If an rc1, rc2, etc is needed, delete that tag before creating a
> >> new one:
> >>
> >> 8. git tag -d release-<releaseVersion>
> >> git push origin :refs/tags/release-<releaseVersion>
> >> 9.
> >>
> >>
> >>
> >>
> >>
> >>
> >> 10. Create temporary directory where you'll be preparing all required
> >> artifacts
> >>
> >> 11. mkdir -p /tmp/eagle-release-preparations
> >> 12.
> >>
> >>
> >>
> >> 13. Create source artifact and move it to your temporary directory
> >>
> >> 14. git archive --format=tar
> --prefix=apache-eagle-<releasVersion>-incubating-src/
> >> HEAD | gzip > /tmp/eagle-release-preparations/apache-eagle-
> >> <releaseVersion>-incubating-src.tar.gz
> >> 15.
> >>
> >>
> >>
> >> *Sanity Check*
> >> 1. Make sure the tar and the rc match
> >>
> >> 2. cd /tmp/eagle-release-preparations
> >> tar -xvf apache-eagle-<releaseVersion>-incubating-src.tar.gz
> >>
> >> #Do a fresh clone of the tag
> >> git clone https://
> >> git-wip-us.apache.org/repos/asf/incubator-eagle.git
> >> <http://git-wip-us.apache.org/repos/asf/incubator-sentry.git>
> >> cd incubator-eagle/
> >> git checkout tags/release-<releaseVersion>
> >> cd ..
> >> diff -r incubator-eagle
> apache-eagle-<releaseVersion>-incubating-src
> >> 3.
> >>
> >>
> >>
> >> 4. Make sure code compiles and tests pass on the untared src.
> >>
> >> 5. cd apache-eagle-<releaseVersion>-incubating-src
> >> mvn clean install -DskipTests
> >> mvn test
> >> mvn verify -DskipTests (to do the rat check)
> >> 6.
> >>
> >>
> >>
> >> *Create signatures and check sums *
> >>
> >> All artifacts must be signed and checksummed. In order to sign a
> >> release you will need a PGP key. You should get your key signed by
> a few
> >> other people. You will also need to recv their keys from a public
> key
> >> server. See the Apache release signing
> >> <https://www.apache.org/dev/release-signing> page for more
> >> details. If you add your PGP key fingerprint to your Apache
> profile, your
> >> key should automatically be added to
> >> https://people.apache.org/keys/group/eagle.asc
> >> <https://people.apache.org/keys/group/sentry.asc>
> >>
> >> 1. Change your working directory to the temporal one
> >>
> >>
> >>
> >> cd /tmp/eagle-release-preparations
> >>
> >>
> >>
> >> 2. Sing each file with your key
> >>
> >>
> >>
> >> for file in *.tar.gz; do gpg --armor --output $file.asc
> --detach-sig
> >>
> >> $file; done
> >>
> >>
> >>
> >> 3. You can immediately verify your signature
> >>
> >>
> >>
> >> for file in *.tar.gz; do gpg --verify $file.asc $file; done
> >>
> >>
> >>
> >> 4. Create md5 check sum
> >>
> >>
> >>
> >> for file in *.tar.gz; do md5sum $file > $file.md5; done
> >>
> >>
> >>
> >> 5. Create sha1 check sum
> >>
> >>
> >>
> >> for file in *.tar.gz; do sha1sum $file > $file.sha; done
> >>
> >>
> >>
> >> *Upload artifacts*
> >>
> >> Upload artifacts and all created check sums with signatures to
> >> https://dist.apache.org/repos/dist/dev/incubator/eagle
> >> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
> >>
> >> *Update KEYS file*
> >>
> >> If your PGP key is not yet in the project's KEYS file, you need to
> >> first add that in. To do this, checkout the KEYS file and update
> it using
> >> the following commands:
> >>
> >>
> >>
> >>
> >>
> >> $ svn co
> https://dist.apache.org/repos/dist/release/incubator/eagle
> >> <https://dist.apache.org/repos/dist/release/incubator/sentry>
> >> eagle-release
> >>
> >> $ cd eagle-release
> >>
> >> $ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >>
> >> KEYS
> >>
> >> $ svn commit -m "Adding PGP public key to KEYS file" KEYS
> >>
> >>
> >>
> >>
> >>
> >> Once this file has been updated, you need to publish it in the
> >> appropriate dist directory for the project on
> >> http://www.apache.org/dist. To do this, you must copy the file as
> >> follows:
> >>
> >>
> >>
> >>
> >>
> >> $ scp KEYS people.apache.
> >> org:/www/www.apache.org/dist/incubator/eagle/KEYS
> >> <http://org/www/www.apache.org/dist/incubator/sentry/KEYS>
> >>
> >>
> >>
> >>
> >>
> >> This will take some time to propagate in which you can continue
> >> with the other steps of the release process.
> >>
> >> Verifying a release candidate
> >>
> >> Following are the typical things we need to verify before voting on
> >> a release candidate. And the release manager should verify them
> too before
> >> calling out a vote.
> >> - Make sure RCs are hosted @
> >> https://dist.apache.org/repos/dist/dev/incubator/eagle
> >> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
> >> - Should be in format apache-$project-$version-incubating.tar.gz
> >> - Verify Signatures and hashes. You may have to import the
> >> public key of the release manager to verify the signatures. (gpg
> >> --recv-key <last8 of public key>)
> >> - git tag matches the released bits (diff -rf)
> >> - Can compile successfully from source
> >> - Verify DISCLAIMER, NOTICE and LICENCE (year etc)
> >> - All files have correct headers (Rat check should be clean -
> >> mvn verify)
> >> - Make sure there are no conflicting licenses (TODO: how)
> >> - No jar files or the like in the release
> >> -
> >>
> >> Running the vote
> >>
> >>
> >> Voting has to be done on dev@eagle.incubator.apache.org
> >> <de...@sentry.incubator.apache.org> list followed by
> >> general@incubator.apache.org. You can close the vote after voting
> >> period expires and you accumulate sufficient votes.
> >>
> >> Call for voting on dev list (PPMC)
> >>
> >> To: dev@eagle.incubator.apache.org
> >>
> >> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
> >>
> >> This is the incubator release of Apache Eagle, version
> >> <releaseVersion>-incubating.
> >>
> >> It fixes the following issues: http://s.apache.org/VlU
> >>
> >>
> >> Source files :
> >> https://dist.apache.org/repos/dist/dev/incubator/eagle/eagle-
> >> <releaseVersion>/
> >>
> >>
> >> Tag to be voted on (rc#):
> >>
> https://git-wip-us.apache.org/repos/asf/incubator-eagle/?p=incubator-eagle.git;a=commit;h=
> >> <commit-hash-of-the-tag>
> >>
> >> Eagle's KEYS containing the PGP key we used to sign the release:
> >>
> >> https://people.apache.org/keys/group/eagle.asc (or
> >> http://www.apache.org/dist/incubator/eagle/KEYS for non
> committers)
> >>
> >>
> >> Note that this is a source only release and we are voting on the
> >> source: tag=release-<releaseVersion>, SHA=<release_SHA> (You can
> get the
> >> hash of the tag by doing "git rev-list release-<releaseVersion> |
> head -n
> >> 1" )
> >>
> >>
> >> Vote will be open for 72 hours.
> >>
> >>
> >> [ ] +1 approve
> >>
> >> [ ] +0 no opinion
> >>
> >> [ ] -1 disapprove (and reason why)
> >>
> >>
> >>
> >> Thanks,
> >>
> >> $RM
> >>
> >> The vote has to be called first on the dev list. Upon receiving 3
> >> +1s from the PPMC, reply to the voting thread and prefixing
> >> *[RESULT]* to the subject line with the results.
> >>
> >> To: dev@eagle.incubator.apache.org
> >>
> >> Subject: [RESULT][VOTE] Release eagle incubating version
> >> <releaseVersion>
> >>
> >>
> >>
> >> Voting is now closed and has passed with the following tally.
> >>
> >>
> >> PPMC +1: <PPMC voters>
> >>
> >> Others +1: <other community members who voted>
> >>
> >>
> >> A vote will now be called on general@incubator.apache.org.
> >>
> >>
> >>
> >> $RM
> >>
> >> Voting on @general
> >>
> >> The vote should be now called on general@incubator.apache.org
> >> <ge...@incubator.apache.org.> for IPMC votes. Binding votes are
> >> from IPMC member, and non-binding votes are from PPMC members.
> >>
> >> To: general@incubator.apache.org
> >>
> >> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
> >>
> >>
> >>
> >> This is the first incubator release of Apache Eagle, version
> >>
> >> <releaseVersion>-incubating.
> >>
> >>
> >>
> >> <Same as above...>
> >>
> >>
> >> A vote on releasing this package has already passed in Apache Eagle
> >>
> >> PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...).
> >>
> >>
> >> Vote will be open for 72 hours.
> >>
> >>
> >> [ ] +1 approve
> >>
> >> [ ] +0 no opinion
> >>
> >> [ ] -1 disapprove (and reason why)
> >>
> >>
> >> <RM>
> >>
> >>
> >> [1] -
> >>
> >>
> >>
> http://markmail.org/search/?q=eagle%20vote%20release#query:eagle%20vote%20release+page:1+mid:sqrwevgsxakqatqk+state:results
> >>
> >> By convention, vote closing email is sent to
> >> general@incubator.apache.org by replying to the voting thread and
> >> prefixing *[RESULT]* to the subject line. This method keeps the
> >> closing email in the same thread with the voting emails for better
> record
> >> keeping in the mail archive.
> >>
> >>
> >>
> >> Example close email:
> >>
> >> To: general@incubator.apache.org
> >>
> >> Subject: [RESULT][VOTE] Release Eagle incubating version
> >> <releaseVersion>
> >>
> >>
> >>
> >> Voting is now closed and has passed with the following tally,
> >>
> >>
> >> Binding +1s: <IPMC binding voter list>
> >>
> >> Non binding +1s: <PPMC voter list>
> >>
> >>
> >> Thanks to everyone who voted! I'll continue with the rest of the
> >> release process.
> >>
> >>
> >>
> >> $RM
> >>
> >> Rolling out the Release
> >>
> >>
> >> Close JIRA version
> >>
> >> You need to close the release in JIRA so that everyone knows that
> >> your version should not be used as "fixVersion" for new bugs. Go to
> >> JIRA "Administer project" page and follow "Versions" in left menu.
> >> Table with list of all releases should appear, click on additional
> menu
> >> on the right of your release and choose "Release" option. Submit
> >> release date and you're done.
> >>
> >> Upload the artifacts
> >>
> >> In order to release you have to checkout release repository
> >> located on
> >> https://dist.apache.org/repos/dist/release/incubator/eagle/
> >> <https://dist.apache.org/repos/dist/release/incubator/sentry/> and
> >> add release artifacts there.
> >>
> >> svn co https://dist.apache.org/repos/dist/release/incubator/eagle/
> >> eagle-release
> >>
> >> cd eagle-release
> >>
> >> mkdir <releaseVersion>-incubating/
> >>
> >> cp $source_to_your_artifacts <releaseVersion>-incubating/
> >>
> >> svn add <releaseVersion>-incubating
> >>
> >> It may take up to 24 hours for all mirrors to sync up (
> >> http://www.apache.org/dyn/closer.cgi/incubator/eagle/
> >> <http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
> >>
> >> Announce the release
> >>
> >> Send an email to announce@apache.org (the from: address must be @
> >> apache.org). For example,
> >>
> >> To: announce@apache.org, dev@eagle.incubator.apache.org
> >>
> >> Subject: [ANNOUNCE] Apache Eagle <releaseVersion> incubating
> >> released
> >>
> >>
> >> The Apache Eagle community is happy to announce the release of
> >> version <releaseVersion>-incubating from the Apache Incubator.
> Apache Eagle
> >> is a monitoring framework for Hadoop to identify access to
> sensitive data,
> >> recognize malicious activities and take action in real time.
> >>
> >> The release bits are available at:
> >> http://www.apache.org/dyn/closer.cgi/incubator/eagle
> >>
> >> The change list is available at: <chageLogLocation>
> >>
> >> We would like to thank all contributors who made the release
> >> possible.
> >>
> >>
> >> Disclaimer
> >>
> >> Apache Eagle is an effort undergoing incubation at The Apache
> >> Software Foundation (ASF), sponsored by the Apache Incubator PMC.
> >> Incubation is required of all newly accepted projects until a
> further
> >> review indicates that the infrastructure, communications, and
> decision
> >> making process have stabilized in a manner consistent with other
> successful
> >> ASF projects. While incubation status is not necessarily a
> reflection of
> >> the completeness or stability of the code, it does indicate that
> the
> >> project has yet to be fully endorsed by the ASF.
> >>
> >>
> >> Regards,
> >>
> >> Eagle Community
> >>
> >> Update the website
> >> 1. Update the website:
> >> 1. Add the release to the downloads
> >> <http://eagle.incubator.apache.org/general/downloads.html>
> >> 2. Add the release to the history page
> >> <http://eagle.incubator.apache.org/general/history.html>
> >> 2. Update the "News" section in the podling status page
> >> <http://incubator.apache.org/projects/eagle.html>.
> >> 3. Update how to release page with your experience
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <
> aruncarthick@gmail.com>
> >> wrote:
> >>
> >>> I agree with Julian. Edward is starting to collect the list of features
> >>> that are ready. I'm guessing Michael Wu will be a good release manager
> and
> >>> start getting educated on the apache process.
> >>>
> >>> Thanks,
> >>> Arun
> >>>
> >>>
> >>>
> >>> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org>
> wrote:
> >>>
> >>>> It’s difficult to describe the “licensing issues”. I suggest that you
> >>>> nominate a release manager and that person subscribes to the
> >>>> general@incubator list [1] and follows the discussions there. Watch
> the
> >>>> kind of due diligence that people such as Justin McLean apply to the
> >>>> releases, e.g. the Freemarker release [2]. (It seems onerous but is
> much
> >>>> appreciated by your community, because it means they are getting
> >>> spotlessly
> >>>> clean IP.)
> >>>>
> >>>> You will need to go through the same process: after a vote on this dev
> >>>> list, there is a second vote on the generator@incubator list.
> >>>>
> >>>> I can’t stress this strongly enough: The actual features (and bugs) in
> >>> the
> >>>> first release is very unimportant. It is all about the legal
> packaging,
> >>> and
> >>>> the process by which you make the release. No reason not to start now.
> >>>>
> >>>> Julian
> >>>>
> >>>> [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
> >>>>
> >>>> [2]
> >>>>
> >>>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
> >>>>
> >>>>> On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
> >>>> yonzhang@ebay.com> wrote:
> >>>>>
> >>>>> Thanks for initiating this discussion. I also wonder how to do the
> >>> first
> >>>>> release, what it the timing, what is the version number and what
> >>> features
> >>>>> we should include and what is release notes.
> >>>>>
> >>>>> But I am not aware of licensing issues. Does that because that not
> all
> >>>> our
> >>>>> source files are for apache license so we need explicitly tell that
> in
> >>>>> public?
> >>>>>
> >>>>> I volunteer to collect the features for the first release. A lot more
> >>>> work
> >>>>> should be identified while we are progressing.
> >>>>>
> >>>>> Thanks
> >>>>> Edward
> >>>>>
> >>>>> On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
> >>>>>
> >>>>>> Hi eagle community,
> >>>>>>
> >>>>>> How¹s progress on the first Eagle release?
> >>>>>>
> >>>>>> The Eagle project is progressing at an admirable rate in terms of
> >>>>>> features and community engagement. However, you¹ve not yet made a
> >>>>>> release. Making a release is more tricky than you would imagine ‹
> and
> >>>>>> it¹s usually due to licensing issues, not due to bugs or other code
> >>>>>> issues ‹ so the first one takes a month or two. But making releases
> >>> is a
> >>>>>> key part of learning the Apache way and demonstrating that you¹re
> >>> ready
> >>>>>> to graduate; and, it helps to build community.
> >>>>>>
> >>>>>> Also remember that the project does not need to be ³perfect². Your
> >>> first
> >>>>>> release will have lots of bugs in it. If it compiles and has a
> >>> README,
> >>>>>> that is enough.
> >>>>>>
> >>>>>> Julian
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Arun Karthick
> >>> 201-850-9399
> >>>
> >>
> >>
>
>
Re: Release?
Posted by Julian Hyde <jh...@apache.org>.
You should consider using the maven release plugin. A lot of those steps you describe can be replaced with
mvn -Papache release:prepare
mvn -Papache release:perform
That said, that can wait until the second release. For the first release, making source tarball (with the requisite LICENSE, NOTICE files, etc.) by any means is acceptable!
Julian
> On Jan 22, 2016, at 1:50 PM, Prasad Mujumdar <p3...@gmail.com> wrote:
>
> Looks like the formatting is bit messed up. My apologies. Hopefully it
> will be better formatted on the wiki.
>
> thanks
> Prasad
>
>
> On Fri, Jan 22, 2016 at 1:48 PM, Prasad Mujumdar <pr...@apache.org> wrote:
>
>>
>> @Julian, strong +1 to making release soon. Thanks for bring that up.
>> @Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based on
>> my experience with other incubating project releases (as Julian mentioned,
>> primarily based on Justin's feedback in past) there some work that still
>> needed. We EAGLE-115 to tracking that. I will try to prioritize getting a
>> patch ready for that.
>>
>> Looks like we don't have a 'how to release' page that outlines the release
>> steps. Here's a draft that I put together (using some of the existing
>> incubator project templates).
>> @Ed and @Arun, if one of you could give me access to the wiki, I can
>> upload the draft there so that community members can directly edit the page.
>>
>>
>> *How to Release*
>>
>> This document describes the release process for Apache Eagle release from
>> Incubator. This is a working progress document till we have a few releases
>> and ironed out the process.
>>
>> *Release manager*
>>
>> Someone from the community should volunteer to become a release
>> manager(RM) and coordinate the release process. The release steps listed
>> below will mostly be carried out by the release manager. Ideally this
>> person should be a committer or PPMC member, however it should be fine for
>> a contributor to take that responsibility with one of the committer or PPMC
>> to mentor him/her to make the release.
>>
>> The Release Manager (RM) must go through the policy document to understand
>> all the tasks and responsibilities of running a release. Frequently asked
>> questions for making Apache releases are available on Releases FAQ
>> <http://www.apache.org/dev/release.html>page. Guide to Release Management
>> During Incubation
>> <http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager> also
>> has good information on best practices for releasing artifacts from an
>> incubating Apache project.
>>
>>
>>
>> *Give a heads up*
>>
>> The RM should first create an umbrella issue to create the release and
>> then setup a timeline for release branch point. The community should decide
>> on the cutoff point for the release branch on the release discussion
>> thread.
>>
>> To: dev@eagle.incubator.apache.org
>>
>> Subject: Work on $release release has started
>>
>>
>> Created a tracking jira (jira#) for the eagle $release and plan to branch
>> tentatively on $date.
>>
>>
>>
>> What would you like to see included?
>>
>> Thanks,
>>
>> $RM
>>
>> *Sanitize JIRA*
>>
>> 1. Before a release is done, make sure that any issues that are
>> *fixed *have their fix version setup correctly. Run the following JIRA
>> query to see which resolved issues do not have their fix version set
>> up correctly:
>>
>> 2. project = eagle and resolution = fixed and fixVersion is empty
>> 3.
>>
>>
>>
>>
>>
>> The result of the above query should be empty. If some issues do
>> show up in this query that have been fixed since the last release,
>> please bulk-edit them to set the fix version to '<releaseVersion>'.
>> 4. Move the unresolved jiras to the next release
>>
>> 5. project = eagle and fixVersion = <releaseVersion> and status not
>> in( resolved, done, Accepted, Closed)
>> 6.
>>
>>
>>
>> 7. You can also run the following query to make sure that the
>> issues fixed for the to-be-released version look accurate:
>>
>> 8. project = eagle and fixVersion = '<releaseVersion>'
>> 9.
>>
>>
>>
>> 10. Finally, check out the output of the *JIRA release note tool*
>> <https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectName=eagle> to
>> see which JIRAs are included in the release, in order to do a sanity check.
>>
>> *Creating Release Artifacts*
>>
>> *Communicate with the community*
>>
>> 1. Send an email to dev list to notify that you are about to
>> branch. Ask to hold off any commits until this is finished.
>> 2. Send another email after branching is done.
>>
>> *Preparing branches*
>>
>> 1. Create a release branch
>> 1. Clone fresh repository copy
>>
>> 2. git clone https://
>> git-wip-us.apache.org/repos/asf/incubator-eagle.git
>> cd eagle
>> 3.
>>
>>
>>
>> 4. Checkout master branch
>>
>> 5. git checkout master
>> 6.
>>
>>
>>
>> 7. Check that current HEAD points to commit on which you want to
>> base new release branch. Checkout particular commit if not.
>>
>> 8. git log # Check current branch history. HEAD should point to
>> commit that you want to be base for your release branch
>> git checkout <releaseBaseCommit> # Check out particular commit that
>> should be base for release branch if -^
>> 9.
>>
>>
>>
>> 10. Create new release branch with name "branch-$version"
>>
>> 11. git checkout -b branch-<releaseVersion>
>> 12.
>>
>>
>>
>> 13. Update CHANGELOG in the trunk to indicate the changes going
>> into the new version.
>> The change list can be swiped from the *JIRA release note tool*
>> <https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314720>
>> (use the "text" format for the change log). See JIRA Cleanup above
>> to ensure that the release notes generated by this tool are what you are
>> expecting.
>> 14. Remove -SNAPSHOT from the release branch and commit
>>
>> 15. find . -name pom.xml | xargs sed -i ""
>> -e "s/X.Y.0-SNAPSHOT/X.Y.0/" or mvn versions:set
>> -DnewVersion=X.Y.0 -DgenerateBackupPoms=false
>> git add .
>> git commit -m "EAGLE-XXXX: Removing -SNAPSHOT from X.Y release
>> branch"
>> 16.
>>
>>
>>
>> 17. Check your changes and push new branch to Apache repository
>>
>> 18. mvn *install*
>> git push origin branch-<releaseVersion>
>> 19.
>>
>>
>>
>> 20. Check that branch was correctly propagated to Apache repository.
>> 2. Prepare the master for next release (<releaseVersion+1>)
>>
>> 3. git checkout master
>> find . -name pom.xml | xargs sed -i "" -e "s/<releaseVersion>-SNAPSHOT/
>> <releaseVersion+1>-SNAPSHOT/" or mvn versions:set
>> -DnewVersion=1.3.0-SNAPSHOT -DgenerateBackupPoms=false
>> git add .
>> git commit -m "EAGLE-XXXX: Preparing for eagle <releaseVersion+1>
>> development"
>> git push origin master:master
>> 4.
>>
>>
>>
>> 5. Send an email announcing new branch
>> To: dev@eagle.incubator.apache.org
>> 6. Subject: New release branch <releaseVersion>
>> 7.
>> 8.
>> 9. I've just created new release branch for upcoming <releaseVersion>
>> incubating release.
>> 10. Please continue committing to master branch as usual.
>> 11. I'll cherry-pick commits to branch-<releaseVersion> on per needed
>> basis.
>> 12.
>> 13.
>> 14. Thanks,
>> 15. $RM
>>
>>
>> *Create release tar balls*
>>
>> 1. Check out release branch
>>
>> 2. git checkout branch-<ReleaseVersion>
>> 3.
>>
>>
>>
>> 4. Create tag on this commit to identify precise point where the
>> RC was generated and push this tag to main repository
>>
>> 5. git tag -a release-<ReleaseVersion> -m "Eagle <ReleaseVersion>
>> incubating release"
>> #Make sure compiles/tests run fine and rat check is fine
>> mvn clean install -DskipTests
>> mvn test
>> mvn verify -DskipTests (to do the rat check)
>> git push origin release-<ReleaseVersion>
>> 6.
>>
>>
>>
>> 7. If an rc1, rc2, etc is needed, delete that tag before creating a
>> new one:
>>
>> 8. git tag -d release-<releaseVersion>
>> git push origin :refs/tags/release-<releaseVersion>
>> 9.
>>
>>
>>
>>
>>
>>
>> 10. Create temporary directory where you'll be preparing all required
>> artifacts
>>
>> 11. mkdir -p /tmp/eagle-release-preparations
>> 12.
>>
>>
>>
>> 13. Create source artifact and move it to your temporary directory
>>
>> 14. git archive --format=tar --prefix=apache-eagle-<releasVersion>-incubating-src/
>> HEAD | gzip > /tmp/eagle-release-preparations/apache-eagle-
>> <releaseVersion>-incubating-src.tar.gz
>> 15.
>>
>>
>>
>> *Sanity Check*
>> 1. Make sure the tar and the rc match
>>
>> 2. cd /tmp/eagle-release-preparations
>> tar -xvf apache-eagle-<releaseVersion>-incubating-src.tar.gz
>>
>> #Do a fresh clone of the tag
>> git clone https://
>> git-wip-us.apache.org/repos/asf/incubator-eagle.git
>> <http://git-wip-us.apache.org/repos/asf/incubator-sentry.git>
>> cd incubator-eagle/
>> git checkout tags/release-<releaseVersion>
>> cd ..
>> diff -r incubator-eagle apache-eagle-<releaseVersion>-incubating-src
>> 3.
>>
>>
>>
>> 4. Make sure code compiles and tests pass on the untared src.
>>
>> 5. cd apache-eagle-<releaseVersion>-incubating-src
>> mvn clean install -DskipTests
>> mvn test
>> mvn verify -DskipTests (to do the rat check)
>> 6.
>>
>>
>>
>> *Create signatures and check sums *
>>
>> All artifacts must be signed and checksummed. In order to sign a
>> release you will need a PGP key. You should get your key signed by a few
>> other people. You will also need to recv their keys from a public key
>> server. See the Apache release signing
>> <https://www.apache.org/dev/release-signing> page for more
>> details. If you add your PGP key fingerprint to your Apache profile, your
>> key should automatically be added to
>> https://people.apache.org/keys/group/eagle.asc
>> <https://people.apache.org/keys/group/sentry.asc>
>>
>> 1. Change your working directory to the temporal one
>>
>>
>>
>> cd /tmp/eagle-release-preparations
>>
>>
>>
>> 2. Sing each file with your key
>>
>>
>>
>> for file in *.tar.gz; do gpg --armor --output $file.asc --detach-sig
>>
>> $file; done
>>
>>
>>
>> 3. You can immediately verify your signature
>>
>>
>>
>> for file in *.tar.gz; do gpg --verify $file.asc $file; done
>>
>>
>>
>> 4. Create md5 check sum
>>
>>
>>
>> for file in *.tar.gz; do md5sum $file > $file.md5; done
>>
>>
>>
>> 5. Create sha1 check sum
>>
>>
>>
>> for file in *.tar.gz; do sha1sum $file > $file.sha; done
>>
>>
>>
>> *Upload artifacts*
>>
>> Upload artifacts and all created check sums with signatures to
>> https://dist.apache.org/repos/dist/dev/incubator/eagle
>> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
>>
>> *Update KEYS file*
>>
>> If your PGP key is not yet in the project's KEYS file, you need to
>> first add that in. To do this, checkout the KEYS file and update it using
>> the following commands:
>>
>>
>>
>>
>>
>> $ svn co https://dist.apache.org/repos/dist/release/incubator/eagle
>> <https://dist.apache.org/repos/dist/release/incubator/sentry>
>> eagle-release
>>
>> $ cd eagle-release
>>
>> $ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >>
>> KEYS
>>
>> $ svn commit -m "Adding PGP public key to KEYS file" KEYS
>>
>>
>>
>>
>>
>> Once this file has been updated, you need to publish it in the
>> appropriate dist directory for the project on
>> http://www.apache.org/dist. To do this, you must copy the file as
>> follows:
>>
>>
>>
>>
>>
>> $ scp KEYS people.apache.
>> org:/www/www.apache.org/dist/incubator/eagle/KEYS
>> <http://org/www/www.apache.org/dist/incubator/sentry/KEYS>
>>
>>
>>
>>
>>
>> This will take some time to propagate in which you can continue
>> with the other steps of the release process.
>>
>> Verifying a release candidate
>>
>> Following are the typical things we need to verify before voting on
>> a release candidate. And the release manager should verify them too before
>> calling out a vote.
>> - Make sure RCs are hosted @
>> https://dist.apache.org/repos/dist/dev/incubator/eagle
>> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
>> - Should be in format apache-$project-$version-incubating.tar.gz
>> - Verify Signatures and hashes. You may have to import the
>> public key of the release manager to verify the signatures. (gpg
>> --recv-key <last8 of public key>)
>> - git tag matches the released bits (diff -rf)
>> - Can compile successfully from source
>> - Verify DISCLAIMER, NOTICE and LICENCE (year etc)
>> - All files have correct headers (Rat check should be clean -
>> mvn verify)
>> - Make sure there are no conflicting licenses (TODO: how)
>> - No jar files or the like in the release
>> -
>>
>> Running the vote
>>
>>
>> Voting has to be done on dev@eagle.incubator.apache.org
>> <de...@sentry.incubator.apache.org> list followed by
>> general@incubator.apache.org. You can close the vote after voting
>> period expires and you accumulate sufficient votes.
>>
>> Call for voting on dev list (PPMC)
>>
>> To: dev@eagle.incubator.apache.org
>>
>> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
>>
>> This is the incubator release of Apache Eagle, version
>> <releaseVersion>-incubating.
>>
>> It fixes the following issues: http://s.apache.org/VlU
>>
>>
>> Source files :
>> https://dist.apache.org/repos/dist/dev/incubator/eagle/eagle-
>> <releaseVersion>/
>>
>>
>> Tag to be voted on (rc#):
>> https://git-wip-us.apache.org/repos/asf/incubator-eagle/?p=incubator-eagle.git;a=commit;h=
>> <commit-hash-of-the-tag>
>>
>> Eagle's KEYS containing the PGP key we used to sign the release:
>>
>> https://people.apache.org/keys/group/eagle.asc (or
>> http://www.apache.org/dist/incubator/eagle/KEYS for non committers)
>>
>>
>> Note that this is a source only release and we are voting on the
>> source: tag=release-<releaseVersion>, SHA=<release_SHA> (You can get the
>> hash of the tag by doing "git rev-list release-<releaseVersion> | head -n
>> 1" )
>>
>>
>> Vote will be open for 72 hours.
>>
>>
>> [ ] +1 approve
>>
>> [ ] +0 no opinion
>>
>> [ ] -1 disapprove (and reason why)
>>
>>
>>
>> Thanks,
>>
>> $RM
>>
>> The vote has to be called first on the dev list. Upon receiving 3
>> +1s from the PPMC, reply to the voting thread and prefixing
>> *[RESULT]* to the subject line with the results.
>>
>> To: dev@eagle.incubator.apache.org
>>
>> Subject: [RESULT][VOTE] Release eagle incubating version
>> <releaseVersion>
>>
>>
>>
>> Voting is now closed and has passed with the following tally.
>>
>>
>> PPMC +1: <PPMC voters>
>>
>> Others +1: <other community members who voted>
>>
>>
>> A vote will now be called on general@incubator.apache.org.
>>
>>
>>
>> $RM
>>
>> Voting on @general
>>
>> The vote should be now called on general@incubator.apache.org
>> <ge...@incubator.apache.org.> for IPMC votes. Binding votes are
>> from IPMC member, and non-binding votes are from PPMC members.
>>
>> To: general@incubator.apache.org
>>
>> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
>>
>>
>>
>> This is the first incubator release of Apache Eagle, version
>>
>> <releaseVersion>-incubating.
>>
>>
>>
>> <Same as above...>
>>
>>
>> A vote on releasing this package has already passed in Apache Eagle
>>
>> PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...).
>>
>>
>> Vote will be open for 72 hours.
>>
>>
>> [ ] +1 approve
>>
>> [ ] +0 no opinion
>>
>> [ ] -1 disapprove (and reason why)
>>
>>
>> <RM>
>>
>>
>> [1] -
>>
>>
>> http://markmail.org/search/?q=eagle%20vote%20release#query:eagle%20vote%20release+page:1+mid:sqrwevgsxakqatqk+state:results
>>
>> By convention, vote closing email is sent to
>> general@incubator.apache.org by replying to the voting thread and
>> prefixing *[RESULT]* to the subject line. This method keeps the
>> closing email in the same thread with the voting emails for better record
>> keeping in the mail archive.
>>
>>
>>
>> Example close email:
>>
>> To: general@incubator.apache.org
>>
>> Subject: [RESULT][VOTE] Release Eagle incubating version
>> <releaseVersion>
>>
>>
>>
>> Voting is now closed and has passed with the following tally,
>>
>>
>> Binding +1s: <IPMC binding voter list>
>>
>> Non binding +1s: <PPMC voter list>
>>
>>
>> Thanks to everyone who voted! I'll continue with the rest of the
>> release process.
>>
>>
>>
>> $RM
>>
>> Rolling out the Release
>>
>>
>> Close JIRA version
>>
>> You need to close the release in JIRA so that everyone knows that
>> your version should not be used as "fixVersion" for new bugs. Go to
>> JIRA "Administer project" page and follow "Versions" in left menu.
>> Table with list of all releases should appear, click on additional menu
>> on the right of your release and choose "Release" option. Submit
>> release date and you're done.
>>
>> Upload the artifacts
>>
>> In order to release you have to checkout release repository
>> located on
>> https://dist.apache.org/repos/dist/release/incubator/eagle/
>> <https://dist.apache.org/repos/dist/release/incubator/sentry/> and
>> add release artifacts there.
>>
>> svn co https://dist.apache.org/repos/dist/release/incubator/eagle/
>> eagle-release
>>
>> cd eagle-release
>>
>> mkdir <releaseVersion>-incubating/
>>
>> cp $source_to_your_artifacts <releaseVersion>-incubating/
>>
>> svn add <releaseVersion>-incubating
>>
>> It may take up to 24 hours for all mirrors to sync up (
>> http://www.apache.org/dyn/closer.cgi/incubator/eagle/
>> <http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
>>
>> Announce the release
>>
>> Send an email to announce@apache.org (the from: address must be @
>> apache.org). For example,
>>
>> To: announce@apache.org, dev@eagle.incubator.apache.org
>>
>> Subject: [ANNOUNCE] Apache Eagle <releaseVersion> incubating
>> released
>>
>>
>> The Apache Eagle community is happy to announce the release of
>> version <releaseVersion>-incubating from the Apache Incubator. Apache Eagle
>> is a monitoring framework for Hadoop to identify access to sensitive data,
>> recognize malicious activities and take action in real time.
>>
>> The release bits are available at:
>> http://www.apache.org/dyn/closer.cgi/incubator/eagle
>>
>> The change list is available at: <chageLogLocation>
>>
>> We would like to thank all contributors who made the release
>> possible.
>>
>>
>> Disclaimer
>>
>> Apache Eagle is an effort undergoing incubation at The Apache
>> Software Foundation (ASF), sponsored by the Apache Incubator PMC.
>> Incubation is required of all newly accepted projects until a further
>> review indicates that the infrastructure, communications, and decision
>> making process have stabilized in a manner consistent with other successful
>> ASF projects. While incubation status is not necessarily a reflection of
>> the completeness or stability of the code, it does indicate that the
>> project has yet to be fully endorsed by the ASF.
>>
>>
>> Regards,
>>
>> Eagle Community
>>
>> Update the website
>> 1. Update the website:
>> 1. Add the release to the downloads
>> <http://eagle.incubator.apache.org/general/downloads.html>
>> 2. Add the release to the history page
>> <http://eagle.incubator.apache.org/general/history.html>
>> 2. Update the "News" section in the podling status page
>> <http://incubator.apache.org/projects/eagle.html>.
>> 3. Update how to release page with your experience
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <ar...@gmail.com>
>> wrote:
>>
>>> I agree with Julian. Edward is starting to collect the list of features
>>> that are ready. I'm guessing Michael Wu will be a good release manager and
>>> start getting educated on the apache process.
>>>
>>> Thanks,
>>> Arun
>>>
>>>
>>>
>>> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org> wrote:
>>>
>>>> It’s difficult to describe the “licensing issues”. I suggest that you
>>>> nominate a release manager and that person subscribes to the
>>>> general@incubator list [1] and follows the discussions there. Watch the
>>>> kind of due diligence that people such as Justin McLean apply to the
>>>> releases, e.g. the Freemarker release [2]. (It seems onerous but is much
>>>> appreciated by your community, because it means they are getting
>>> spotlessly
>>>> clean IP.)
>>>>
>>>> You will need to go through the same process: after a vote on this dev
>>>> list, there is a second vote on the generator@incubator list.
>>>>
>>>> I can’t stress this strongly enough: The actual features (and bugs) in
>>> the
>>>> first release is very unimportant. It is all about the legal packaging,
>>> and
>>>> the process by which you make the release. No reason not to start now.
>>>>
>>>> Julian
>>>>
>>>> [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
>>>>
>>>> [2]
>>>>
>>> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
>>>>
>>>>> On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
>>>> yonzhang@ebay.com> wrote:
>>>>>
>>>>> Thanks for initiating this discussion. I also wonder how to do the
>>> first
>>>>> release, what it the timing, what is the version number and what
>>> features
>>>>> we should include and what is release notes.
>>>>>
>>>>> But I am not aware of licensing issues. Does that because that not all
>>>> our
>>>>> source files are for apache license so we need explicitly tell that in
>>>>> public?
>>>>>
>>>>> I volunteer to collect the features for the first release. A lot more
>>>> work
>>>>> should be identified while we are progressing.
>>>>>
>>>>> Thanks
>>>>> Edward
>>>>>
>>>>> On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
>>>>>
>>>>>> Hi eagle community,
>>>>>>
>>>>>> How¹s progress on the first Eagle release?
>>>>>>
>>>>>> The Eagle project is progressing at an admirable rate in terms of
>>>>>> features and community engagement. However, you¹ve not yet made a
>>>>>> release. Making a release is more tricky than you would imagine ‹ and
>>>>>> it¹s usually due to licensing issues, not due to bugs or other code
>>>>>> issues ‹ so the first one takes a month or two. But making releases
>>> is a
>>>>>> key part of learning the Apache way and demonstrating that you¹re
>>> ready
>>>>>> to graduate; and, it helps to build community.
>>>>>>
>>>>>> Also remember that the project does not need to be ³perfect². Your
>>> first
>>>>>> release will have lots of bugs in it. If it compiles and has a
>>> README,
>>>>>> that is enough.
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Arun Karthick
>>> 201-850-9399
>>>
>>
>>
Re: Release?
Posted by Edward Zhang <yo...@gmail.com>.
Hi Prasad,
Could you ask Eagle mentors to give the privileges of adding/editing a
wiki? Myself could not grant privilege.
Thanks
Edward
On Fri, Jan 22, 2016 at 2:03 PM, arunkarthick m <ar...@gmail.com>
wrote:
> I used to have administrator rights on the wiki. Not seeing the space admin
> button anymore. Will ask Edward once he is here.
>
> Thanks,
> Arun
>
> On Fri, Jan 22, 2016 at 1:50 PM, Prasad Mujumdar <p3...@gmail.com>
> wrote:
>
> > Looks like the formatting is bit messed up. My apologies. Hopefully it
> > will be better formatted on the wiki.
> >
> > thanks
> > Prasad
> >
> >
> > On Fri, Jan 22, 2016 at 1:48 PM, Prasad Mujumdar <pr...@apache.org>
> > wrote:
> >
> > >
> > > @Julian, strong +1 to making release soon. Thanks for bring that up.
> > > @Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based
> on
> > > my experience with other incubating project releases (as Julian
> > mentioned,
> > > primarily based on Justin's feedback in past) there some work that
> still
> > > needed. We EAGLE-115 to tracking that. I will try to prioritize
> getting a
> > > patch ready for that.
> > >
> > > Looks like we don't have a 'how to release' page that outlines the
> > release
> > > steps. Here's a draft that I put together (using some of the existing
> > > incubator project templates).
> > > @Ed and @Arun, if one of you could give me access to the wiki, I can
> > > upload the draft there so that community members can directly edit the
> > page.
> > >
> > >
> > > *How to Release*
> > >
> > > This document describes the release process for Apache Eagle release
> from
> > > Incubator. This is a working progress document till we have a few
> > releases
> > > and ironed out the process.
> > >
> > > *Release manager*
> > >
> > > Someone from the community should volunteer to become a release
> > > manager(RM) and coordinate the release process. The release steps
> listed
> > > below will mostly be carried out by the release manager. Ideally this
> > > person should be a committer or PPMC member, however it should be fine
> > for
> > > a contributor to take that responsibility with one of the committer or
> > PPMC
> > > to mentor him/her to make the release.
> > >
> > > The Release Manager (RM) must go through the policy document to
> > understand
> > > all the tasks and responsibilities of running a release. Frequently
> > asked
> > > questions for making Apache releases are available on Releases FAQ
> > > <http://www.apache.org/dev/release.html>page. Guide to Release
> > Management
> > > During Incubation
> > > <
> >
> http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager
> >
> > also
> > > has good information on best practices for releasing artifacts from an
> > > incubating Apache project.
> > >
> > >
> > >
> > > *Give a heads up*
> > >
> > > The RM should first create an umbrella issue to create the release and
> > > then setup a timeline for release branch point. The community should
> > decide
> > > on the cutoff point for the release branch on the release discussion
> > > thread.
> > >
> > > To: dev@eagle.incubator.apache.org
> > >
> > > Subject: Work on $release release has started
> > >
> > >
> > > Created a tracking jira (jira#) for the eagle $release and plan to
> branch
> > > tentatively on $date.
> > >
> > >
> > >
> > > What would you like to see included?
> > >
> > > Thanks,
> > >
> > > $RM
> > >
> > > *Sanitize JIRA*
> > >
> > > 1. Before a release is done, make sure that any issues that are
> > > *fixed *have their fix version setup correctly. Run the following
> JIRA
> > > query to see which resolved issues do not have their fix version set
> > > up correctly:
> > >
> > > 2. project = eagle and resolution = fixed and fixVersion is empty
> > > 3.
> > >
> > >
> > >
> > >
> > >
> > > The result of the above query should be empty. If some issues do
> > > show up in this query that have been fixed since the last release,
> > > please bulk-edit them to set the fix version to '<releaseVersion>'.
> > > 4. Move the unresolved jiras to the next release
> > >
> > > 5. project = eagle and fixVersion = <releaseVersion> and status not
> > > in( resolved, done, Accepted, Closed)
> > > 6.
> > >
> > >
> > >
> > > 7. You can also run the following query to make sure that the
> > > issues fixed for the to-be-released version look accurate:
> > >
> > > 8. project = eagle and fixVersion = '<releaseVersion>'
> > > 9.
> > >
> > >
> > >
> > > 10. Finally, check out the output of the *JIRA release note tool*
> > > <
> >
> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectName=eagle
> >
> > to
> > > see which JIRAs are included in the release, in order to do a sanity
> > check.
> > >
> > > *Creating Release Artifacts*
> > >
> > > *Communicate with the community*
> > >
> > > 1. Send an email to dev list to notify that you are about to
> > > branch. Ask to hold off any commits until this is finished.
> > > 2. Send another email after branching is done.
> > >
> > > *Preparing branches*
> > >
> > > 1. Create a release branch
> > > 1. Clone fresh repository copy
> > >
> > > 2. git clone https://
> > > git-wip-us.apache.org/repos/asf/incubator-eagle.git
> > > cd eagle
> > > 3.
> > >
> > >
> > >
> > > 4. Checkout master branch
> > >
> > > 5. git checkout master
> > > 6.
> > >
> > >
> > >
> > > 7. Check that current HEAD points to commit on which you want to
> > > base new release branch. Checkout particular commit if not.
> > >
> > > 8. git log # Check current branch history. HEAD should point to
> > > commit that you want to be base for your release branch
> > > git checkout <releaseBaseCommit> # Check out particular commit
> that
> > > should be base for release branch if -^
> > > 9.
> > >
> > >
> > >
> > > 10. Create new release branch with name "branch-$version"
> > >
> > > 11. git checkout -b branch-<releaseVersion>
> > > 12.
> > >
> > >
> > >
> > > 13. Update CHANGELOG in the trunk to indicate the changes going
> > > into the new version.
> > > The change list can be swiped from the *JIRA release note tool*
> > > <
> >
> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314720
> > >
> > > (use the "text" format for the change log). See JIRA Cleanup
> above
> > > to ensure that the release notes generated by this tool are what
> > you are
> > > expecting.
> > > 14. Remove -SNAPSHOT from the release branch and commit
> > >
> > > 15. find . -name pom.xml | xargs sed -i ""
> > > -e "s/X.Y.0-SNAPSHOT/X.Y.0/" or mvn versions:set
> > > -DnewVersion=X.Y.0 -DgenerateBackupPoms=false
> > > git add .
> > > git commit -m "EAGLE-XXXX: Removing -SNAPSHOT from X.Y release
> > > branch"
> > > 16.
> > >
> > >
> > >
> > > 17. Check your changes and push new branch to Apache repository
> > >
> > > 18. mvn *install*
> > > git push origin branch-<releaseVersion>
> > > 19.
> > >
> > >
> > >
> > > 20. Check that branch was correctly propagated to Apache
> > repository.
> > > 2. Prepare the master for next release (<releaseVersion+1>)
> > >
> > > 3. git checkout master
> > > find . -name pom.xml | xargs sed -i "" -e
> > "s/<releaseVersion>-SNAPSHOT/
> > > <releaseVersion+1>-SNAPSHOT/" or mvn versions:set
> > > -DnewVersion=1.3.0-SNAPSHOT -DgenerateBackupPoms=false
> > > git add .
> > > git commit -m "EAGLE-XXXX: Preparing for eagle <releaseVersion+1>
> > > development"
> > > git push origin master:master
> > > 4.
> > >
> > >
> > >
> > > 5. Send an email announcing new branch
> > > To: dev@eagle.incubator.apache.org
> > > 6. Subject: New release branch <releaseVersion>
> > > 7.
> > > 8.
> > > 9. I've just created new release branch for upcoming
> <releaseVersion>
> > > incubating release.
> > > 10. Please continue committing to master branch as usual.
> > > 11. I'll cherry-pick commits to branch-<releaseVersion> on per
> needed
> > > basis.
> > > 12.
> > > 13.
> > > 14. Thanks,
> > > 15. $RM
> > >
> > >
> > > *Create release tar balls*
> > >
> > > 1. Check out release branch
> > >
> > > 2. git checkout branch-<ReleaseVersion>
> > > 3.
> > >
> > >
> > >
> > > 4. Create tag on this commit to identify precise point where the
> > > RC was generated and push this tag to main repository
> > >
> > > 5. git tag -a release-<ReleaseVersion> -m "Eagle <ReleaseVersion>
> > > incubating release"
> > > #Make sure compiles/tests run fine and rat check is fine
> > > mvn clean install -DskipTests
> > > mvn test
> > > mvn verify -DskipTests (to do the rat check)
> > > git push origin release-<ReleaseVersion>
> > > 6.
> > >
> > >
> > >
> > > 7. If an rc1, rc2, etc is needed, delete that tag before creating a
> > > new one:
> > >
> > > 8. git tag -d release-<releaseVersion>
> > > git push origin :refs/tags/release-<releaseVersion>
> > > 9.
> > >
> > >
> > >
> > >
> > >
> > >
> > > 10. Create temporary directory where you'll be preparing all
> required
> > > artifacts
> > >
> > > 11. mkdir -p /tmp/eagle-release-preparations
> > > 12.
> > >
> > >
> > >
> > > 13. Create source artifact and move it to your temporary directory
> > >
> > > 14. git archive --format=tar
> > --prefix=apache-eagle-<releasVersion>-incubating-src/
> > > HEAD | gzip > /tmp/eagle-release-preparations/apache-eagle-
> > > <releaseVersion>-incubating-src.tar.gz
> > > 15.
> > >
> > >
> > >
> > > *Sanity Check*
> > > 1. Make sure the tar and the rc match
> > >
> > > 2. cd /tmp/eagle-release-preparations
> > > tar -xvf apache-eagle-<releaseVersion>-incubating-src.tar.gz
> > >
> > > #Do a fresh clone of the tag
> > > git clone https://
> > > git-wip-us.apache.org/repos/asf/incubator-eagle.git
> > > <http://git-wip-us.apache.org/repos/asf/incubator-sentry.git>
> > > cd incubator-eagle/
> > > git checkout tags/release-<releaseVersion>
> > > cd ..
> > > diff -r incubator-eagle
> > apache-eagle-<releaseVersion>-incubating-src
> > > 3.
> > >
> > >
> > >
> > > 4. Make sure code compiles and tests pass on the untared src.
> > >
> > > 5. cd apache-eagle-<releaseVersion>-incubating-src
> > > mvn clean install -DskipTests
> > > mvn test
> > > mvn verify -DskipTests (to do the rat check)
> > > 6.
> > >
> > >
> > >
> > > *Create signatures and check sums *
> > >
> > > All artifacts must be signed and checksummed. In order to sign a
> > > release you will need a PGP key. You should get your key signed
> by
> > a few
> > > other people. You will also need to recv their keys from a public
> > key
> > > server. See the Apache release signing
> > > <https://www.apache.org/dev/release-signing> page for more
> > > details. If you add your PGP key fingerprint to your Apache
> > profile, your
> > > key should automatically be added to
> > > https://people.apache.org/keys/group/eagle.asc
> > > <https://people.apache.org/keys/group/sentry.asc>
> > >
> > > 1. Change your working directory to the temporal one
> > >
> > >
> > >
> > > cd /tmp/eagle-release-preparations
> > >
> > >
> > >
> > > 2. Sing each file with your key
> > >
> > >
> > >
> > > for file in *.tar.gz; do gpg --armor --output $file.asc
> > --detach-sig
> > >
> > > $file; done
> > >
> > >
> > >
> > > 3. You can immediately verify your signature
> > >
> > >
> > >
> > > for file in *.tar.gz; do gpg --verify $file.asc $file; done
> > >
> > >
> > >
> > > 4. Create md5 check sum
> > >
> > >
> > >
> > > for file in *.tar.gz; do md5sum $file > $file.md5; done
> > >
> > >
> > >
> > > 5. Create sha1 check sum
> > >
> > >
> > >
> > > for file in *.tar.gz; do sha1sum $file > $file.sha; done
> > >
> > >
> > >
> > > *Upload artifacts*
> > >
> > > Upload artifacts and all created check sums with signatures to
> > > https://dist.apache.org/repos/dist/dev/incubator/eagle
> > > <https://dist.apache.org/repos/dist/dev/incubator/sentry>
> > >
> > > *Update KEYS file*
> > >
> > > If your PGP key is not yet in the project's KEYS file, you need
> to
> > > first add that in. To do this, checkout the KEYS file and update
> > it using
> > > the following commands:
> > >
> > >
> > >
> > >
> > >
> > > $ svn co
> > https://dist.apache.org/repos/dist/release/incubator/eagle
> > > <https://dist.apache.org/repos/dist/release/incubator/sentry>
> > > eagle-release
> > >
> > > $ cd eagle-release
> > >
> > > $ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >>
> > > KEYS
> > >
> > > $ svn commit -m "Adding PGP public key to KEYS file" KEYS
> > >
> > >
> > >
> > >
> > >
> > > Once this file has been updated, you need to publish it in the
> > > appropriate dist directory for the project on
> > > http://www.apache.org/dist. To do this, you must copy the file
> as
> > > follows:
> > >
> > >
> > >
> > >
> > >
> > > $ scp KEYS people.apache.
> > > org:/www/www.apache.org/dist/incubator/eagle/KEYS
> > > <http://org/www/www.apache.org/dist/incubator/sentry/KEYS>
> > >
> > >
> > >
> > >
> > >
> > > This will take some time to propagate in which you can continue
> > > with the other steps of the release process.
> > >
> > > Verifying a release candidate
> > >
> > > Following are the typical things we need to verify before voting
> on
> > > a release candidate. And the release manager should verify them
> > too before
> > > calling out a vote.
> > > - Make sure RCs are hosted @
> > > https://dist.apache.org/repos/dist/dev/incubator/eagle
> > > <https://dist.apache.org/repos/dist/dev/incubator/sentry>
> > > - Should be in format
> apache-$project-$version-incubating.tar.gz
> > > - Verify Signatures and hashes. You may have to import the
> > > public key of the release manager to verify the signatures.
> (gpg
> > > --recv-key <last8 of public key>)
> > > - git tag matches the released bits (diff -rf)
> > > - Can compile successfully from source
> > > - Verify DISCLAIMER, NOTICE and LICENCE (year etc)
> > > - All files have correct headers (Rat check should be clean -
> > > mvn verify)
> > > - Make sure there are no conflicting licenses (TODO: how)
> > > - No jar files or the like in the release
> > > -
> > >
> > > Running the vote
> > >
> > >
> > > Voting has to be done on dev@eagle.incubator.apache.org
> > > <de...@sentry.incubator.apache.org> list followed by
> > > general@incubator.apache.org. You can close the vote after
> voting
> > > period expires and you accumulate sufficient votes.
> > >
> > > Call for voting on dev list (PPMC)
> > >
> > > To: dev@eagle.incubator.apache.org
> > >
> > > Subject: [VOTE] Release Eagle incubating version <releaseVersion>
> > >
> > > This is the incubator release of Apache Eagle, version
> > > <releaseVersion>-incubating.
> > >
> > > It fixes the following issues: http://s.apache.org/VlU
> > >
> > >
> > > Source files :
> > > https://dist.apache.org/repos/dist/dev/incubator/eagle/eagle-
> > > <releaseVersion>/
> > >
> > >
> > > Tag to be voted on (rc#):
> > >
> >
> https://git-wip-us.apache.org/repos/asf/incubator-eagle/?p=incubator-eagle.git;a=commit;h=
> > > <commit-hash-of-the-tag>
> > >
> > > Eagle's KEYS containing the PGP key we used to sign the release:
> > >
> > > https://people.apache.org/keys/group/eagle.asc (or
> > > http://www.apache.org/dist/incubator/eagle/KEYS for non
> > committers)
> > >
> > >
> > > Note that this is a source only release and we are voting on the
> > > source: tag=release-<releaseVersion>, SHA=<release_SHA> (You can
> > get the
> > > hash of the tag by doing "git rev-list release-<releaseVersion> |
> > head -n
> > > 1" )
> > >
> > >
> > > Vote will be open for 72 hours.
> > >
> > >
> > > [ ] +1 approve
> > >
> > > [ ] +0 no opinion
> > >
> > > [ ] -1 disapprove (and reason why)
> > >
> > >
> > >
> > > Thanks,
> > >
> > > $RM
> > >
> > > The vote has to be called first on the dev list. Upon receiving 3
> > > +1s from the PPMC, reply to the voting thread and prefixing
> > > *[RESULT]* to the subject line with the results.
> > >
> > > To: dev@eagle.incubator.apache.org
> > >
> > > Subject: [RESULT][VOTE] Release eagle incubating version
> > > <releaseVersion>
> > >
> > >
> > >
> > > Voting is now closed and has passed with the following tally.
> > >
> > >
> > > PPMC +1: <PPMC voters>
> > >
> > > Others +1: <other community members who voted>
> > >
> > >
> > > A vote will now be called on general@incubator.apache.org.
> > >
> > >
> > >
> > > $RM
> > >
> > > Voting on @general
> > >
> > > The vote should be now called on general@incubator.apache.org
> > > <ge...@incubator.apache.org.> for IPMC votes. Binding votes
> are
> > > from IPMC member, and non-binding votes are from PPMC members.
> > >
> > > To: general@incubator.apache.org
> > >
> > > Subject: [VOTE] Release Eagle incubating version <releaseVersion>
> > >
> > >
> > >
> > > This is the first incubator release of Apache Eagle, version
> > >
> > > <releaseVersion>-incubating.
> > >
> > >
> > >
> > > <Same as above...>
> > >
> > >
> > > A vote on releasing this package has already passed in Apache
> Eagle
> > >
> > > PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...).
> > >
> > >
> > > Vote will be open for 72 hours.
> > >
> > >
> > > [ ] +1 approve
> > >
> > > [ ] +0 no opinion
> > >
> > > [ ] -1 disapprove (and reason why)
> > >
> > >
> > > <RM>
> > >
> > >
> > > [1] -
> > >
> > >
> > >
> >
> http://markmail.org/search/?q=eagle%20vote%20release#query:eagle%20vote%20release+page:1+mid:sqrwevgsxakqatqk+state:results
> > >
> > > By convention, vote closing email is sent to
> > > general@incubator.apache.org by replying to the voting thread
> and
> > > prefixing *[RESULT]* to the subject line. This method keeps the
> > > closing email in the same thread with the voting emails for
> better
> > record
> > > keeping in the mail archive.
> > >
> > >
> > >
> > > Example close email:
> > >
> > > To: general@incubator.apache.org
> > >
> > > Subject: [RESULT][VOTE] Release Eagle incubating version
> > > <releaseVersion>
> > >
> > >
> > >
> > > Voting is now closed and has passed with the following tally,
> > >
> > >
> > > Binding +1s: <IPMC binding voter list>
> > >
> > > Non binding +1s: <PPMC voter list>
> > >
> > >
> > > Thanks to everyone who voted! I'll continue with the rest of the
> > > release process.
> > >
> > >
> > >
> > > $RM
> > >
> > > Rolling out the Release
> > >
> > >
> > > Close JIRA version
> > >
> > > You need to close the release in JIRA so that everyone knows that
> > > your version should not be used as "fixVersion" for new bugs. Go
> to
> > > JIRA "Administer project" page and follow "Versions" in left
> menu.
> > > Table with list of all releases should appear, click on
> additional
> > menu
> > > on the right of your release and choose "Release" option. Submit
> > > release date and you're done.
> > >
> > > Upload the artifacts
> > >
> > > In order to release you have to checkout release repository
> > > located on
> > > https://dist.apache.org/repos/dist/release/incubator/eagle/
> > > <https://dist.apache.org/repos/dist/release/incubator/sentry/>
> and
> > > add release artifacts there.
> > >
> > > svn co
> https://dist.apache.org/repos/dist/release/incubator/eagle/
> > > eagle-release
> > >
> > > cd eagle-release
> > >
> > > mkdir <releaseVersion>-incubating/
> > >
> > > cp $source_to_your_artifacts <releaseVersion>-incubating/
> > >
> > > svn add <releaseVersion>-incubating
> > >
> > > It may take up to 24 hours for all mirrors to sync up (
> > > http://www.apache.org/dyn/closer.cgi/incubator/eagle/
> > > <http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
> > >
> > > Announce the release
> > >
> > > Send an email to announce@apache.org (the from: address must be
> @
> > > apache.org). For example,
> > >
> > > To: announce@apache.org, dev@eagle.incubator.apache.org
> > >
> > > Subject: [ANNOUNCE] Apache Eagle <releaseVersion> incubating
> > > released
> > >
> > >
> > > The Apache Eagle community is happy to announce the release of
> > > version <releaseVersion>-incubating from the Apache Incubator.
> > Apache Eagle
> > > is a monitoring framework for Hadoop to identify access to
> > sensitive data,
> > > recognize malicious activities and take action in real time.
> > >
> > > The release bits are available at:
> > > http://www.apache.org/dyn/closer.cgi/incubator/eagle
> > >
> > > The change list is available at: <chageLogLocation>
> > >
> > > We would like to thank all contributors who made the release
> > > possible.
> > >
> > >
> > > Disclaimer
> > >
> > > Apache Eagle is an effort undergoing incubation at The Apache
> > > Software Foundation (ASF), sponsored by the Apache Incubator PMC.
> > > Incubation is required of all newly accepted projects until a
> > further
> > > review indicates that the infrastructure, communications, and
> > decision
> > > making process have stabilized in a manner consistent with other
> > successful
> > > ASF projects. While incubation status is not necessarily a
> > reflection of
> > > the completeness or stability of the code, it does indicate that
> > the
> > > project has yet to be fully endorsed by the ASF.
> > >
> > >
> > > Regards,
> > >
> > > Eagle Community
> > >
> > > Update the website
> > > 1. Update the website:
> > > 1. Add the release to the downloads
> > > <http://eagle.incubator.apache.org/general/downloads.html>
> > > 2. Add the release to the history page
> > > <http://eagle.incubator.apache.org/general/history.html>
> > > 2. Update the "News" section in the podling status page
> > > <http://incubator.apache.org/projects/eagle.html>.
> > > 3. Update how to release page with your experience
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <
> aruncarthick@gmail.com
> > >
> > > wrote:
> > >
> > >> I agree with Julian. Edward is starting to collect the list of
> features
> > >> that are ready. I'm guessing Michael Wu will be a good release manager
> > and
> > >> start getting educated on the apache process.
> > >>
> > >> Thanks,
> > >> Arun
> > >>
> > >>
> > >>
> > >> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org>
> wrote:
> > >>
> > >> > It’s difficult to describe the “licensing issues”. I suggest that
> you
> > >> > nominate a release manager and that person subscribes to the
> > >> > general@incubator list [1] and follows the discussions there. Watch
> > the
> > >> > kind of due diligence that people such as Justin McLean apply to the
> > >> > releases, e.g. the Freemarker release [2]. (It seems onerous but is
> > much
> > >> > appreciated by your community, because it means they are getting
> > >> spotlessly
> > >> > clean IP.)
> > >> >
> > >> > You will need to go through the same process: after a vote on this
> dev
> > >> > list, there is a second vote on the generator@incubator list.
> > >> >
> > >> > I can’t stress this strongly enough: The actual features (and bugs)
> in
> > >> the
> > >> > first release is very unimportant. It is all about the legal
> > packaging,
> > >> and
> > >> > the process by which you make the release. No reason not to start
> now.
> > >> >
> > >> > Julian
> > >> >
> > >> > [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
> > >> >
> > >> > [2]
> > >> >
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
> > >> >
> > >> > > On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
> > >> > yonzhang@ebay.com> wrote:
> > >> > >
> > >> > > Thanks for initiating this discussion. I also wonder how to do the
> > >> first
> > >> > > release, what it the timing, what is the version number and what
> > >> features
> > >> > > we should include and what is release notes.
> > >> > >
> > >> > > But I am not aware of licensing issues. Does that because that not
> > all
> > >> > our
> > >> > > source files are for apache license so we need explicitly tell
> that
> > in
> > >> > > public?
> > >> > >
> > >> > > I volunteer to collect the features for the first release. A lot
> > more
> > >> > work
> > >> > > should be identified while we are progressing.
> > >> > >
> > >> > > Thanks
> > >> > > Edward
> > >> > >
> > >> > > On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
> > >> > >
> > >> > >> Hi eagle community,
> > >> > >>
> > >> > >> How¹s progress on the first Eagle release?
> > >> > >>
> > >> > >> The Eagle project is progressing at an admirable rate in terms of
> > >> > >> features and community engagement. However, you¹ve not yet made a
> > >> > >> release. Making a release is more tricky than you would imagine ‹
> > and
> > >> > >> it¹s usually due to licensing issues, not due to bugs or other
> code
> > >> > >> issues ‹ so the first one takes a month or two. But making
> releases
> > >> is a
> > >> > >> key part of learning the Apache way and demonstrating that you¹re
> > >> ready
> > >> > >> to graduate; and, it helps to build community.
> > >> > >>
> > >> > >> Also remember that the project does not need to be ³perfect².
> Your
> > >> first
> > >> > >> release will have lots of bugs in it. If it compiles and has a
> > >> README,
> > >> > >> that is enough.
> > >> > >>
> > >> > >> Julian
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Arun Karthick
> > >> 201-850-9399
> > >>
> > >
> > >
> >
>
>
>
> --
> Arun Karthick
> 201-850-9399
>
Re: Release?
Posted by arunkarthick m <ar...@gmail.com>.
I used to have administrator rights on the wiki. Not seeing the space admin
button anymore. Will ask Edward once he is here.
Thanks,
Arun
On Fri, Jan 22, 2016 at 1:50 PM, Prasad Mujumdar <p3...@gmail.com>
wrote:
> Looks like the formatting is bit messed up. My apologies. Hopefully it
> will be better formatted on the wiki.
>
> thanks
> Prasad
>
>
> On Fri, Jan 22, 2016 at 1:48 PM, Prasad Mujumdar <pr...@apache.org>
> wrote:
>
> >
> > @Julian, strong +1 to making release soon. Thanks for bring that up.
> > @Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based on
> > my experience with other incubating project releases (as Julian
> mentioned,
> > primarily based on Justin's feedback in past) there some work that still
> > needed. We EAGLE-115 to tracking that. I will try to prioritize getting a
> > patch ready for that.
> >
> > Looks like we don't have a 'how to release' page that outlines the
> release
> > steps. Here's a draft that I put together (using some of the existing
> > incubator project templates).
> > @Ed and @Arun, if one of you could give me access to the wiki, I can
> > upload the draft there so that community members can directly edit the
> page.
> >
> >
> > *How to Release*
> >
> > This document describes the release process for Apache Eagle release from
> > Incubator. This is a working progress document till we have a few
> releases
> > and ironed out the process.
> >
> > *Release manager*
> >
> > Someone from the community should volunteer to become a release
> > manager(RM) and coordinate the release process. The release steps listed
> > below will mostly be carried out by the release manager. Ideally this
> > person should be a committer or PPMC member, however it should be fine
> for
> > a contributor to take that responsibility with one of the committer or
> PPMC
> > to mentor him/her to make the release.
> >
> > The Release Manager (RM) must go through the policy document to
> understand
> > all the tasks and responsibilities of running a release. Frequently
> asked
> > questions for making Apache releases are available on Releases FAQ
> > <http://www.apache.org/dev/release.html>page. Guide to Release
> Management
> > During Incubation
> > <
> http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager>
> also
> > has good information on best practices for releasing artifacts from an
> > incubating Apache project.
> >
> >
> >
> > *Give a heads up*
> >
> > The RM should first create an umbrella issue to create the release and
> > then setup a timeline for release branch point. The community should
> decide
> > on the cutoff point for the release branch on the release discussion
> > thread.
> >
> > To: dev@eagle.incubator.apache.org
> >
> > Subject: Work on $release release has started
> >
> >
> > Created a tracking jira (jira#) for the eagle $release and plan to branch
> > tentatively on $date.
> >
> >
> >
> > What would you like to see included?
> >
> > Thanks,
> >
> > $RM
> >
> > *Sanitize JIRA*
> >
> > 1. Before a release is done, make sure that any issues that are
> > *fixed *have their fix version setup correctly. Run the following JIRA
> > query to see which resolved issues do not have their fix version set
> > up correctly:
> >
> > 2. project = eagle and resolution = fixed and fixVersion is empty
> > 3.
> >
> >
> >
> >
> >
> > The result of the above query should be empty. If some issues do
> > show up in this query that have been fixed since the last release,
> > please bulk-edit them to set the fix version to '<releaseVersion>'.
> > 4. Move the unresolved jiras to the next release
> >
> > 5. project = eagle and fixVersion = <releaseVersion> and status not
> > in( resolved, done, Accepted, Closed)
> > 6.
> >
> >
> >
> > 7. You can also run the following query to make sure that the
> > issues fixed for the to-be-released version look accurate:
> >
> > 8. project = eagle and fixVersion = '<releaseVersion>'
> > 9.
> >
> >
> >
> > 10. Finally, check out the output of the *JIRA release note tool*
> > <
> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectName=eagle>
> to
> > see which JIRAs are included in the release, in order to do a sanity
> check.
> >
> > *Creating Release Artifacts*
> >
> > *Communicate with the community*
> >
> > 1. Send an email to dev list to notify that you are about to
> > branch. Ask to hold off any commits until this is finished.
> > 2. Send another email after branching is done.
> >
> > *Preparing branches*
> >
> > 1. Create a release branch
> > 1. Clone fresh repository copy
> >
> > 2. git clone https://
> > git-wip-us.apache.org/repos/asf/incubator-eagle.git
> > cd eagle
> > 3.
> >
> >
> >
> > 4. Checkout master branch
> >
> > 5. git checkout master
> > 6.
> >
> >
> >
> > 7. Check that current HEAD points to commit on which you want to
> > base new release branch. Checkout particular commit if not.
> >
> > 8. git log # Check current branch history. HEAD should point to
> > commit that you want to be base for your release branch
> > git checkout <releaseBaseCommit> # Check out particular commit that
> > should be base for release branch if -^
> > 9.
> >
> >
> >
> > 10. Create new release branch with name "branch-$version"
> >
> > 11. git checkout -b branch-<releaseVersion>
> > 12.
> >
> >
> >
> > 13. Update CHANGELOG in the trunk to indicate the changes going
> > into the new version.
> > The change list can be swiped from the *JIRA release note tool*
> > <
> https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314720
> >
> > (use the "text" format for the change log). See JIRA Cleanup above
> > to ensure that the release notes generated by this tool are what
> you are
> > expecting.
> > 14. Remove -SNAPSHOT from the release branch and commit
> >
> > 15. find . -name pom.xml | xargs sed -i ""
> > -e "s/X.Y.0-SNAPSHOT/X.Y.0/" or mvn versions:set
> > -DnewVersion=X.Y.0 -DgenerateBackupPoms=false
> > git add .
> > git commit -m "EAGLE-XXXX: Removing -SNAPSHOT from X.Y release
> > branch"
> > 16.
> >
> >
> >
> > 17. Check your changes and push new branch to Apache repository
> >
> > 18. mvn *install*
> > git push origin branch-<releaseVersion>
> > 19.
> >
> >
> >
> > 20. Check that branch was correctly propagated to Apache
> repository.
> > 2. Prepare the master for next release (<releaseVersion+1>)
> >
> > 3. git checkout master
> > find . -name pom.xml | xargs sed -i "" -e
> "s/<releaseVersion>-SNAPSHOT/
> > <releaseVersion+1>-SNAPSHOT/" or mvn versions:set
> > -DnewVersion=1.3.0-SNAPSHOT -DgenerateBackupPoms=false
> > git add .
> > git commit -m "EAGLE-XXXX: Preparing for eagle <releaseVersion+1>
> > development"
> > git push origin master:master
> > 4.
> >
> >
> >
> > 5. Send an email announcing new branch
> > To: dev@eagle.incubator.apache.org
> > 6. Subject: New release branch <releaseVersion>
> > 7.
> > 8.
> > 9. I've just created new release branch for upcoming <releaseVersion>
> > incubating release.
> > 10. Please continue committing to master branch as usual.
> > 11. I'll cherry-pick commits to branch-<releaseVersion> on per needed
> > basis.
> > 12.
> > 13.
> > 14. Thanks,
> > 15. $RM
> >
> >
> > *Create release tar balls*
> >
> > 1. Check out release branch
> >
> > 2. git checkout branch-<ReleaseVersion>
> > 3.
> >
> >
> >
> > 4. Create tag on this commit to identify precise point where the
> > RC was generated and push this tag to main repository
> >
> > 5. git tag -a release-<ReleaseVersion> -m "Eagle <ReleaseVersion>
> > incubating release"
> > #Make sure compiles/tests run fine and rat check is fine
> > mvn clean install -DskipTests
> > mvn test
> > mvn verify -DskipTests (to do the rat check)
> > git push origin release-<ReleaseVersion>
> > 6.
> >
> >
> >
> > 7. If an rc1, rc2, etc is needed, delete that tag before creating a
> > new one:
> >
> > 8. git tag -d release-<releaseVersion>
> > git push origin :refs/tags/release-<releaseVersion>
> > 9.
> >
> >
> >
> >
> >
> >
> > 10. Create temporary directory where you'll be preparing all required
> > artifacts
> >
> > 11. mkdir -p /tmp/eagle-release-preparations
> > 12.
> >
> >
> >
> > 13. Create source artifact and move it to your temporary directory
> >
> > 14. git archive --format=tar
> --prefix=apache-eagle-<releasVersion>-incubating-src/
> > HEAD | gzip > /tmp/eagle-release-preparations/apache-eagle-
> > <releaseVersion>-incubating-src.tar.gz
> > 15.
> >
> >
> >
> > *Sanity Check*
> > 1. Make sure the tar and the rc match
> >
> > 2. cd /tmp/eagle-release-preparations
> > tar -xvf apache-eagle-<releaseVersion>-incubating-src.tar.gz
> >
> > #Do a fresh clone of the tag
> > git clone https://
> > git-wip-us.apache.org/repos/asf/incubator-eagle.git
> > <http://git-wip-us.apache.org/repos/asf/incubator-sentry.git>
> > cd incubator-eagle/
> > git checkout tags/release-<releaseVersion>
> > cd ..
> > diff -r incubator-eagle
> apache-eagle-<releaseVersion>-incubating-src
> > 3.
> >
> >
> >
> > 4. Make sure code compiles and tests pass on the untared src.
> >
> > 5. cd apache-eagle-<releaseVersion>-incubating-src
> > mvn clean install -DskipTests
> > mvn test
> > mvn verify -DskipTests (to do the rat check)
> > 6.
> >
> >
> >
> > *Create signatures and check sums *
> >
> > All artifacts must be signed and checksummed. In order to sign a
> > release you will need a PGP key. You should get your key signed by
> a few
> > other people. You will also need to recv their keys from a public
> key
> > server. See the Apache release signing
> > <https://www.apache.org/dev/release-signing> page for more
> > details. If you add your PGP key fingerprint to your Apache
> profile, your
> > key should automatically be added to
> > https://people.apache.org/keys/group/eagle.asc
> > <https://people.apache.org/keys/group/sentry.asc>
> >
> > 1. Change your working directory to the temporal one
> >
> >
> >
> > cd /tmp/eagle-release-preparations
> >
> >
> >
> > 2. Sing each file with your key
> >
> >
> >
> > for file in *.tar.gz; do gpg --armor --output $file.asc
> --detach-sig
> >
> > $file; done
> >
> >
> >
> > 3. You can immediately verify your signature
> >
> >
> >
> > for file in *.tar.gz; do gpg --verify $file.asc $file; done
> >
> >
> >
> > 4. Create md5 check sum
> >
> >
> >
> > for file in *.tar.gz; do md5sum $file > $file.md5; done
> >
> >
> >
> > 5. Create sha1 check sum
> >
> >
> >
> > for file in *.tar.gz; do sha1sum $file > $file.sha; done
> >
> >
> >
> > *Upload artifacts*
> >
> > Upload artifacts and all created check sums with signatures to
> > https://dist.apache.org/repos/dist/dev/incubator/eagle
> > <https://dist.apache.org/repos/dist/dev/incubator/sentry>
> >
> > *Update KEYS file*
> >
> > If your PGP key is not yet in the project's KEYS file, you need to
> > first add that in. To do this, checkout the KEYS file and update
> it using
> > the following commands:
> >
> >
> >
> >
> >
> > $ svn co
> https://dist.apache.org/repos/dist/release/incubator/eagle
> > <https://dist.apache.org/repos/dist/release/incubator/sentry>
> > eagle-release
> >
> > $ cd eagle-release
> >
> > $ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >>
> > KEYS
> >
> > $ svn commit -m "Adding PGP public key to KEYS file" KEYS
> >
> >
> >
> >
> >
> > Once this file has been updated, you need to publish it in the
> > appropriate dist directory for the project on
> > http://www.apache.org/dist. To do this, you must copy the file as
> > follows:
> >
> >
> >
> >
> >
> > $ scp KEYS people.apache.
> > org:/www/www.apache.org/dist/incubator/eagle/KEYS
> > <http://org/www/www.apache.org/dist/incubator/sentry/KEYS>
> >
> >
> >
> >
> >
> > This will take some time to propagate in which you can continue
> > with the other steps of the release process.
> >
> > Verifying a release candidate
> >
> > Following are the typical things we need to verify before voting on
> > a release candidate. And the release manager should verify them
> too before
> > calling out a vote.
> > - Make sure RCs are hosted @
> > https://dist.apache.org/repos/dist/dev/incubator/eagle
> > <https://dist.apache.org/repos/dist/dev/incubator/sentry>
> > - Should be in format apache-$project-$version-incubating.tar.gz
> > - Verify Signatures and hashes. You may have to import the
> > public key of the release manager to verify the signatures. (gpg
> > --recv-key <last8 of public key>)
> > - git tag matches the released bits (diff -rf)
> > - Can compile successfully from source
> > - Verify DISCLAIMER, NOTICE and LICENCE (year etc)
> > - All files have correct headers (Rat check should be clean -
> > mvn verify)
> > - Make sure there are no conflicting licenses (TODO: how)
> > - No jar files or the like in the release
> > -
> >
> > Running the vote
> >
> >
> > Voting has to be done on dev@eagle.incubator.apache.org
> > <de...@sentry.incubator.apache.org> list followed by
> > general@incubator.apache.org. You can close the vote after voting
> > period expires and you accumulate sufficient votes.
> >
> > Call for voting on dev list (PPMC)
> >
> > To: dev@eagle.incubator.apache.org
> >
> > Subject: [VOTE] Release Eagle incubating version <releaseVersion>
> >
> > This is the incubator release of Apache Eagle, version
> > <releaseVersion>-incubating.
> >
> > It fixes the following issues: http://s.apache.org/VlU
> >
> >
> > Source files :
> > https://dist.apache.org/repos/dist/dev/incubator/eagle/eagle-
> > <releaseVersion>/
> >
> >
> > Tag to be voted on (rc#):
> >
> https://git-wip-us.apache.org/repos/asf/incubator-eagle/?p=incubator-eagle.git;a=commit;h=
> > <commit-hash-of-the-tag>
> >
> > Eagle's KEYS containing the PGP key we used to sign the release:
> >
> > https://people.apache.org/keys/group/eagle.asc (or
> > http://www.apache.org/dist/incubator/eagle/KEYS for non
> committers)
> >
> >
> > Note that this is a source only release and we are voting on the
> > source: tag=release-<releaseVersion>, SHA=<release_SHA> (You can
> get the
> > hash of the tag by doing "git rev-list release-<releaseVersion> |
> head -n
> > 1" )
> >
> >
> > Vote will be open for 72 hours.
> >
> >
> > [ ] +1 approve
> >
> > [ ] +0 no opinion
> >
> > [ ] -1 disapprove (and reason why)
> >
> >
> >
> > Thanks,
> >
> > $RM
> >
> > The vote has to be called first on the dev list. Upon receiving 3
> > +1s from the PPMC, reply to the voting thread and prefixing
> > *[RESULT]* to the subject line with the results.
> >
> > To: dev@eagle.incubator.apache.org
> >
> > Subject: [RESULT][VOTE] Release eagle incubating version
> > <releaseVersion>
> >
> >
> >
> > Voting is now closed and has passed with the following tally.
> >
> >
> > PPMC +1: <PPMC voters>
> >
> > Others +1: <other community members who voted>
> >
> >
> > A vote will now be called on general@incubator.apache.org.
> >
> >
> >
> > $RM
> >
> > Voting on @general
> >
> > The vote should be now called on general@incubator.apache.org
> > <ge...@incubator.apache.org.> for IPMC votes. Binding votes are
> > from IPMC member, and non-binding votes are from PPMC members.
> >
> > To: general@incubator.apache.org
> >
> > Subject: [VOTE] Release Eagle incubating version <releaseVersion>
> >
> >
> >
> > This is the first incubator release of Apache Eagle, version
> >
> > <releaseVersion>-incubating.
> >
> >
> >
> > <Same as above...>
> >
> >
> > A vote on releasing this package has already passed in Apache Eagle
> >
> > PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...).
> >
> >
> > Vote will be open for 72 hours.
> >
> >
> > [ ] +1 approve
> >
> > [ ] +0 no opinion
> >
> > [ ] -1 disapprove (and reason why)
> >
> >
> > <RM>
> >
> >
> > [1] -
> >
> >
> >
> http://markmail.org/search/?q=eagle%20vote%20release#query:eagle%20vote%20release+page:1+mid:sqrwevgsxakqatqk+state:results
> >
> > By convention, vote closing email is sent to
> > general@incubator.apache.org by replying to the voting thread and
> > prefixing *[RESULT]* to the subject line. This method keeps the
> > closing email in the same thread with the voting emails for better
> record
> > keeping in the mail archive.
> >
> >
> >
> > Example close email:
> >
> > To: general@incubator.apache.org
> >
> > Subject: [RESULT][VOTE] Release Eagle incubating version
> > <releaseVersion>
> >
> >
> >
> > Voting is now closed and has passed with the following tally,
> >
> >
> > Binding +1s: <IPMC binding voter list>
> >
> > Non binding +1s: <PPMC voter list>
> >
> >
> > Thanks to everyone who voted! I'll continue with the rest of the
> > release process.
> >
> >
> >
> > $RM
> >
> > Rolling out the Release
> >
> >
> > Close JIRA version
> >
> > You need to close the release in JIRA so that everyone knows that
> > your version should not be used as "fixVersion" for new bugs. Go to
> > JIRA "Administer project" page and follow "Versions" in left menu.
> > Table with list of all releases should appear, click on additional
> menu
> > on the right of your release and choose "Release" option. Submit
> > release date and you're done.
> >
> > Upload the artifacts
> >
> > In order to release you have to checkout release repository
> > located on
> > https://dist.apache.org/repos/dist/release/incubator/eagle/
> > <https://dist.apache.org/repos/dist/release/incubator/sentry/> and
> > add release artifacts there.
> >
> > svn co https://dist.apache.org/repos/dist/release/incubator/eagle/
> > eagle-release
> >
> > cd eagle-release
> >
> > mkdir <releaseVersion>-incubating/
> >
> > cp $source_to_your_artifacts <releaseVersion>-incubating/
> >
> > svn add <releaseVersion>-incubating
> >
> > It may take up to 24 hours for all mirrors to sync up (
> > http://www.apache.org/dyn/closer.cgi/incubator/eagle/
> > <http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
> >
> > Announce the release
> >
> > Send an email to announce@apache.org (the from: address must be @
> > apache.org). For example,
> >
> > To: announce@apache.org, dev@eagle.incubator.apache.org
> >
> > Subject: [ANNOUNCE] Apache Eagle <releaseVersion> incubating
> > released
> >
> >
> > The Apache Eagle community is happy to announce the release of
> > version <releaseVersion>-incubating from the Apache Incubator.
> Apache Eagle
> > is a monitoring framework for Hadoop to identify access to
> sensitive data,
> > recognize malicious activities and take action in real time.
> >
> > The release bits are available at:
> > http://www.apache.org/dyn/closer.cgi/incubator/eagle
> >
> > The change list is available at: <chageLogLocation>
> >
> > We would like to thank all contributors who made the release
> > possible.
> >
> >
> > Disclaimer
> >
> > Apache Eagle is an effort undergoing incubation at The Apache
> > Software Foundation (ASF), sponsored by the Apache Incubator PMC.
> > Incubation is required of all newly accepted projects until a
> further
> > review indicates that the infrastructure, communications, and
> decision
> > making process have stabilized in a manner consistent with other
> successful
> > ASF projects. While incubation status is not necessarily a
> reflection of
> > the completeness or stability of the code, it does indicate that
> the
> > project has yet to be fully endorsed by the ASF.
> >
> >
> > Regards,
> >
> > Eagle Community
> >
> > Update the website
> > 1. Update the website:
> > 1. Add the release to the downloads
> > <http://eagle.incubator.apache.org/general/downloads.html>
> > 2. Add the release to the history page
> > <http://eagle.incubator.apache.org/general/history.html>
> > 2. Update the "News" section in the podling status page
> > <http://incubator.apache.org/projects/eagle.html>.
> > 3. Update how to release page with your experience
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <aruncarthick@gmail.com
> >
> > wrote:
> >
> >> I agree with Julian. Edward is starting to collect the list of features
> >> that are ready. I'm guessing Michael Wu will be a good release manager
> and
> >> start getting educated on the apache process.
> >>
> >> Thanks,
> >> Arun
> >>
> >>
> >>
> >> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org> wrote:
> >>
> >> > It’s difficult to describe the “licensing issues”. I suggest that you
> >> > nominate a release manager and that person subscribes to the
> >> > general@incubator list [1] and follows the discussions there. Watch
> the
> >> > kind of due diligence that people such as Justin McLean apply to the
> >> > releases, e.g. the Freemarker release [2]. (It seems onerous but is
> much
> >> > appreciated by your community, because it means they are getting
> >> spotlessly
> >> > clean IP.)
> >> >
> >> > You will need to go through the same process: after a vote on this dev
> >> > list, there is a second vote on the generator@incubator list.
> >> >
> >> > I can’t stress this strongly enough: The actual features (and bugs) in
> >> the
> >> > first release is very unimportant. It is all about the legal
> packaging,
> >> and
> >> > the process by which you make the release. No reason not to start now.
> >> >
> >> > Julian
> >> >
> >> > [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
> >> >
> >> > [2]
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
> >> >
> >> > > On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
> >> > yonzhang@ebay.com> wrote:
> >> > >
> >> > > Thanks for initiating this discussion. I also wonder how to do the
> >> first
> >> > > release, what it the timing, what is the version number and what
> >> features
> >> > > we should include and what is release notes.
> >> > >
> >> > > But I am not aware of licensing issues. Does that because that not
> all
> >> > our
> >> > > source files are for apache license so we need explicitly tell that
> in
> >> > > public?
> >> > >
> >> > > I volunteer to collect the features for the first release. A lot
> more
> >> > work
> >> > > should be identified while we are progressing.
> >> > >
> >> > > Thanks
> >> > > Edward
> >> > >
> >> > > On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
> >> > >
> >> > >> Hi eagle community,
> >> > >>
> >> > >> How¹s progress on the first Eagle release?
> >> > >>
> >> > >> The Eagle project is progressing at an admirable rate in terms of
> >> > >> features and community engagement. However, you¹ve not yet made a
> >> > >> release. Making a release is more tricky than you would imagine ‹
> and
> >> > >> it¹s usually due to licensing issues, not due to bugs or other code
> >> > >> issues ‹ so the first one takes a month or two. But making releases
> >> is a
> >> > >> key part of learning the Apache way and demonstrating that you¹re
> >> ready
> >> > >> to graduate; and, it helps to build community.
> >> > >>
> >> > >> Also remember that the project does not need to be ³perfect². Your
> >> first
> >> > >> release will have lots of bugs in it. If it compiles and has a
> >> README,
> >> > >> that is enough.
> >> > >>
> >> > >> Julian
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >>
> >> --
> >> Arun Karthick
> >> 201-850-9399
> >>
> >
> >
>
--
Arun Karthick
201-850-9399
Re: Release?
Posted by Prasad Mujumdar <p3...@gmail.com>.
Looks like the formatting is bit messed up. My apologies. Hopefully it
will be better formatted on the wiki.
thanks
Prasad
On Fri, Jan 22, 2016 at 1:48 PM, Prasad Mujumdar <pr...@apache.org> wrote:
>
> @Julian, strong +1 to making release soon. Thanks for bring that up.
> @Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based on
> my experience with other incubating project releases (as Julian mentioned,
> primarily based on Justin's feedback in past) there some work that still
> needed. We EAGLE-115 to tracking that. I will try to prioritize getting a
> patch ready for that.
>
> Looks like we don't have a 'how to release' page that outlines the release
> steps. Here's a draft that I put together (using some of the existing
> incubator project templates).
> @Ed and @Arun, if one of you could give me access to the wiki, I can
> upload the draft there so that community members can directly edit the page.
>
>
> *How to Release*
>
> This document describes the release process for Apache Eagle release from
> Incubator. This is a working progress document till we have a few releases
> and ironed out the process.
>
> *Release manager*
>
> Someone from the community should volunteer to become a release
> manager(RM) and coordinate the release process. The release steps listed
> below will mostly be carried out by the release manager. Ideally this
> person should be a committer or PPMC member, however it should be fine for
> a contributor to take that responsibility with one of the committer or PPMC
> to mentor him/her to make the release.
>
> The Release Manager (RM) must go through the policy document to understand
> all the tasks and responsibilities of running a release. Frequently asked
> questions for making Apache releases are available on Releases FAQ
> <http://www.apache.org/dev/release.html>page. Guide to Release Management
> During Incubation
> <http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager> also
> has good information on best practices for releasing artifacts from an
> incubating Apache project.
>
>
>
> *Give a heads up*
>
> The RM should first create an umbrella issue to create the release and
> then setup a timeline for release branch point. The community should decide
> on the cutoff point for the release branch on the release discussion
> thread.
>
> To: dev@eagle.incubator.apache.org
>
> Subject: Work on $release release has started
>
>
> Created a tracking jira (jira#) for the eagle $release and plan to branch
> tentatively on $date.
>
>
>
> What would you like to see included?
>
> Thanks,
>
> $RM
>
> *Sanitize JIRA*
>
> 1. Before a release is done, make sure that any issues that are
> *fixed *have their fix version setup correctly. Run the following JIRA
> query to see which resolved issues do not have their fix version set
> up correctly:
>
> 2. project = eagle and resolution = fixed and fixVersion is empty
> 3.
>
>
>
>
>
> The result of the above query should be empty. If some issues do
> show up in this query that have been fixed since the last release,
> please bulk-edit them to set the fix version to '<releaseVersion>'.
> 4. Move the unresolved jiras to the next release
>
> 5. project = eagle and fixVersion = <releaseVersion> and status not
> in( resolved, done, Accepted, Closed)
> 6.
>
>
>
> 7. You can also run the following query to make sure that the
> issues fixed for the to-be-released version look accurate:
>
> 8. project = eagle and fixVersion = '<releaseVersion>'
> 9.
>
>
>
> 10. Finally, check out the output of the *JIRA release note tool*
> <https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectName=eagle> to
> see which JIRAs are included in the release, in order to do a sanity check.
>
> *Creating Release Artifacts*
>
> *Communicate with the community*
>
> 1. Send an email to dev list to notify that you are about to
> branch. Ask to hold off any commits until this is finished.
> 2. Send another email after branching is done.
>
> *Preparing branches*
>
> 1. Create a release branch
> 1. Clone fresh repository copy
>
> 2. git clone https://
> git-wip-us.apache.org/repos/asf/incubator-eagle.git
> cd eagle
> 3.
>
>
>
> 4. Checkout master branch
>
> 5. git checkout master
> 6.
>
>
>
> 7. Check that current HEAD points to commit on which you want to
> base new release branch. Checkout particular commit if not.
>
> 8. git log # Check current branch history. HEAD should point to
> commit that you want to be base for your release branch
> git checkout <releaseBaseCommit> # Check out particular commit that
> should be base for release branch if -^
> 9.
>
>
>
> 10. Create new release branch with name "branch-$version"
>
> 11. git checkout -b branch-<releaseVersion>
> 12.
>
>
>
> 13. Update CHANGELOG in the trunk to indicate the changes going
> into the new version.
> The change list can be swiped from the *JIRA release note tool*
> <https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314720>
> (use the "text" format for the change log). See JIRA Cleanup above
> to ensure that the release notes generated by this tool are what you are
> expecting.
> 14. Remove -SNAPSHOT from the release branch and commit
>
> 15. find . -name pom.xml | xargs sed -i ""
> -e "s/X.Y.0-SNAPSHOT/X.Y.0/" or mvn versions:set
> -DnewVersion=X.Y.0 -DgenerateBackupPoms=false
> git add .
> git commit -m "EAGLE-XXXX: Removing -SNAPSHOT from X.Y release
> branch"
> 16.
>
>
>
> 17. Check your changes and push new branch to Apache repository
>
> 18. mvn *install*
> git push origin branch-<releaseVersion>
> 19.
>
>
>
> 20. Check that branch was correctly propagated to Apache repository.
> 2. Prepare the master for next release (<releaseVersion+1>)
>
> 3. git checkout master
> find . -name pom.xml | xargs sed -i "" -e "s/<releaseVersion>-SNAPSHOT/
> <releaseVersion+1>-SNAPSHOT/" or mvn versions:set
> -DnewVersion=1.3.0-SNAPSHOT -DgenerateBackupPoms=false
> git add .
> git commit -m "EAGLE-XXXX: Preparing for eagle <releaseVersion+1>
> development"
> git push origin master:master
> 4.
>
>
>
> 5. Send an email announcing new branch
> To: dev@eagle.incubator.apache.org
> 6. Subject: New release branch <releaseVersion>
> 7.
> 8.
> 9. I've just created new release branch for upcoming <releaseVersion>
> incubating release.
> 10. Please continue committing to master branch as usual.
> 11. I'll cherry-pick commits to branch-<releaseVersion> on per needed
> basis.
> 12.
> 13.
> 14. Thanks,
> 15. $RM
>
>
> *Create release tar balls*
>
> 1. Check out release branch
>
> 2. git checkout branch-<ReleaseVersion>
> 3.
>
>
>
> 4. Create tag on this commit to identify precise point where the
> RC was generated and push this tag to main repository
>
> 5. git tag -a release-<ReleaseVersion> -m "Eagle <ReleaseVersion>
> incubating release"
> #Make sure compiles/tests run fine and rat check is fine
> mvn clean install -DskipTests
> mvn test
> mvn verify -DskipTests (to do the rat check)
> git push origin release-<ReleaseVersion>
> 6.
>
>
>
> 7. If an rc1, rc2, etc is needed, delete that tag before creating a
> new one:
>
> 8. git tag -d release-<releaseVersion>
> git push origin :refs/tags/release-<releaseVersion>
> 9.
>
>
>
>
>
>
> 10. Create temporary directory where you'll be preparing all required
> artifacts
>
> 11. mkdir -p /tmp/eagle-release-preparations
> 12.
>
>
>
> 13. Create source artifact and move it to your temporary directory
>
> 14. git archive --format=tar --prefix=apache-eagle-<releasVersion>-incubating-src/
> HEAD | gzip > /tmp/eagle-release-preparations/apache-eagle-
> <releaseVersion>-incubating-src.tar.gz
> 15.
>
>
>
> *Sanity Check*
> 1. Make sure the tar and the rc match
>
> 2. cd /tmp/eagle-release-preparations
> tar -xvf apache-eagle-<releaseVersion>-incubating-src.tar.gz
>
> #Do a fresh clone of the tag
> git clone https://
> git-wip-us.apache.org/repos/asf/incubator-eagle.git
> <http://git-wip-us.apache.org/repos/asf/incubator-sentry.git>
> cd incubator-eagle/
> git checkout tags/release-<releaseVersion>
> cd ..
> diff -r incubator-eagle apache-eagle-<releaseVersion>-incubating-src
> 3.
>
>
>
> 4. Make sure code compiles and tests pass on the untared src.
>
> 5. cd apache-eagle-<releaseVersion>-incubating-src
> mvn clean install -DskipTests
> mvn test
> mvn verify -DskipTests (to do the rat check)
> 6.
>
>
>
> *Create signatures and check sums *
>
> All artifacts must be signed and checksummed. In order to sign a
> release you will need a PGP key. You should get your key signed by a few
> other people. You will also need to recv their keys from a public key
> server. See the Apache release signing
> <https://www.apache.org/dev/release-signing> page for more
> details. If you add your PGP key fingerprint to your Apache profile, your
> key should automatically be added to
> https://people.apache.org/keys/group/eagle.asc
> <https://people.apache.org/keys/group/sentry.asc>
>
> 1. Change your working directory to the temporal one
>
>
>
> cd /tmp/eagle-release-preparations
>
>
>
> 2. Sing each file with your key
>
>
>
> for file in *.tar.gz; do gpg --armor --output $file.asc --detach-sig
>
> $file; done
>
>
>
> 3. You can immediately verify your signature
>
>
>
> for file in *.tar.gz; do gpg --verify $file.asc $file; done
>
>
>
> 4. Create md5 check sum
>
>
>
> for file in *.tar.gz; do md5sum $file > $file.md5; done
>
>
>
> 5. Create sha1 check sum
>
>
>
> for file in *.tar.gz; do sha1sum $file > $file.sha; done
>
>
>
> *Upload artifacts*
>
> Upload artifacts and all created check sums with signatures to
> https://dist.apache.org/repos/dist/dev/incubator/eagle
> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
>
> *Update KEYS file*
>
> If your PGP key is not yet in the project's KEYS file, you need to
> first add that in. To do this, checkout the KEYS file and update it using
> the following commands:
>
>
>
>
>
> $ svn co https://dist.apache.org/repos/dist/release/incubator/eagle
> <https://dist.apache.org/repos/dist/release/incubator/sentry>
> eagle-release
>
> $ cd eagle-release
>
> $ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >>
> KEYS
>
> $ svn commit -m "Adding PGP public key to KEYS file" KEYS
>
>
>
>
>
> Once this file has been updated, you need to publish it in the
> appropriate dist directory for the project on
> http://www.apache.org/dist. To do this, you must copy the file as
> follows:
>
>
>
>
>
> $ scp KEYS people.apache.
> org:/www/www.apache.org/dist/incubator/eagle/KEYS
> <http://org/www/www.apache.org/dist/incubator/sentry/KEYS>
>
>
>
>
>
> This will take some time to propagate in which you can continue
> with the other steps of the release process.
>
> Verifying a release candidate
>
> Following are the typical things we need to verify before voting on
> a release candidate. And the release manager should verify them too before
> calling out a vote.
> - Make sure RCs are hosted @
> https://dist.apache.org/repos/dist/dev/incubator/eagle
> <https://dist.apache.org/repos/dist/dev/incubator/sentry>
> - Should be in format apache-$project-$version-incubating.tar.gz
> - Verify Signatures and hashes. You may have to import the
> public key of the release manager to verify the signatures. (gpg
> --recv-key <last8 of public key>)
> - git tag matches the released bits (diff -rf)
> - Can compile successfully from source
> - Verify DISCLAIMER, NOTICE and LICENCE (year etc)
> - All files have correct headers (Rat check should be clean -
> mvn verify)
> - Make sure there are no conflicting licenses (TODO: how)
> - No jar files or the like in the release
> -
>
> Running the vote
>
>
> Voting has to be done on dev@eagle.incubator.apache.org
> <de...@sentry.incubator.apache.org> list followed by
> general@incubator.apache.org. You can close the vote after voting
> period expires and you accumulate sufficient votes.
>
> Call for voting on dev list (PPMC)
>
> To: dev@eagle.incubator.apache.org
>
> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
>
> This is the incubator release of Apache Eagle, version
> <releaseVersion>-incubating.
>
> It fixes the following issues: http://s.apache.org/VlU
>
>
> Source files :
> https://dist.apache.org/repos/dist/dev/incubator/eagle/eagle-
> <releaseVersion>/
>
>
> Tag to be voted on (rc#):
> https://git-wip-us.apache.org/repos/asf/incubator-eagle/?p=incubator-eagle.git;a=commit;h=
> <commit-hash-of-the-tag>
>
> Eagle's KEYS containing the PGP key we used to sign the release:
>
> https://people.apache.org/keys/group/eagle.asc (or
> http://www.apache.org/dist/incubator/eagle/KEYS for non committers)
>
>
> Note that this is a source only release and we are voting on the
> source: tag=release-<releaseVersion>, SHA=<release_SHA> (You can get the
> hash of the tag by doing "git rev-list release-<releaseVersion> | head -n
> 1" )
>
>
> Vote will be open for 72 hours.
>
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove (and reason why)
>
>
>
> Thanks,
>
> $RM
>
> The vote has to be called first on the dev list. Upon receiving 3
> +1s from the PPMC, reply to the voting thread and prefixing
> *[RESULT]* to the subject line with the results.
>
> To: dev@eagle.incubator.apache.org
>
> Subject: [RESULT][VOTE] Release eagle incubating version
> <releaseVersion>
>
>
>
> Voting is now closed and has passed with the following tally.
>
>
> PPMC +1: <PPMC voters>
>
> Others +1: <other community members who voted>
>
>
> A vote will now be called on general@incubator.apache.org.
>
>
>
> $RM
>
> Voting on @general
>
> The vote should be now called on general@incubator.apache.org
> <ge...@incubator.apache.org.> for IPMC votes. Binding votes are
> from IPMC member, and non-binding votes are from PPMC members.
>
> To: general@incubator.apache.org
>
> Subject: [VOTE] Release Eagle incubating version <releaseVersion>
>
>
>
> This is the first incubator release of Apache Eagle, version
>
> <releaseVersion>-incubating.
>
>
>
> <Same as above...>
>
>
> A vote on releasing this package has already passed in Apache Eagle
>
> PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...).
>
>
> Vote will be open for 72 hours.
>
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove (and reason why)
>
>
> <RM>
>
>
> [1] -
>
>
> http://markmail.org/search/?q=eagle%20vote%20release#query:eagle%20vote%20release+page:1+mid:sqrwevgsxakqatqk+state:results
>
> By convention, vote closing email is sent to
> general@incubator.apache.org by replying to the voting thread and
> prefixing *[RESULT]* to the subject line. This method keeps the
> closing email in the same thread with the voting emails for better record
> keeping in the mail archive.
>
>
>
> Example close email:
>
> To: general@incubator.apache.org
>
> Subject: [RESULT][VOTE] Release Eagle incubating version
> <releaseVersion>
>
>
>
> Voting is now closed and has passed with the following tally,
>
>
> Binding +1s: <IPMC binding voter list>
>
> Non binding +1s: <PPMC voter list>
>
>
> Thanks to everyone who voted! I'll continue with the rest of the
> release process.
>
>
>
> $RM
>
> Rolling out the Release
>
>
> Close JIRA version
>
> You need to close the release in JIRA so that everyone knows that
> your version should not be used as "fixVersion" for new bugs. Go to
> JIRA "Administer project" page and follow "Versions" in left menu.
> Table with list of all releases should appear, click on additional menu
> on the right of your release and choose "Release" option. Submit
> release date and you're done.
>
> Upload the artifacts
>
> In order to release you have to checkout release repository
> located on
> https://dist.apache.org/repos/dist/release/incubator/eagle/
> <https://dist.apache.org/repos/dist/release/incubator/sentry/> and
> add release artifacts there.
>
> svn co https://dist.apache.org/repos/dist/release/incubator/eagle/
> eagle-release
>
> cd eagle-release
>
> mkdir <releaseVersion>-incubating/
>
> cp $source_to_your_artifacts <releaseVersion>-incubating/
>
> svn add <releaseVersion>-incubating
>
> It may take up to 24 hours for all mirrors to sync up (
> http://www.apache.org/dyn/closer.cgi/incubator/eagle/
> <http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
>
> Announce the release
>
> Send an email to announce@apache.org (the from: address must be @
> apache.org). For example,
>
> To: announce@apache.org, dev@eagle.incubator.apache.org
>
> Subject: [ANNOUNCE] Apache Eagle <releaseVersion> incubating
> released
>
>
> The Apache Eagle community is happy to announce the release of
> version <releaseVersion>-incubating from the Apache Incubator. Apache Eagle
> is a monitoring framework for Hadoop to identify access to sensitive data,
> recognize malicious activities and take action in real time.
>
> The release bits are available at:
> http://www.apache.org/dyn/closer.cgi/incubator/eagle
>
> The change list is available at: <chageLogLocation>
>
> We would like to thank all contributors who made the release
> possible.
>
>
> Disclaimer
>
> Apache Eagle is an effort undergoing incubation at The Apache
> Software Foundation (ASF), sponsored by the Apache Incubator PMC.
> Incubation is required of all newly accepted projects until a further
> review indicates that the infrastructure, communications, and decision
> making process have stabilized in a manner consistent with other successful
> ASF projects. While incubation status is not necessarily a reflection of
> the completeness or stability of the code, it does indicate that the
> project has yet to be fully endorsed by the ASF.
>
>
> Regards,
>
> Eagle Community
>
> Update the website
> 1. Update the website:
> 1. Add the release to the downloads
> <http://eagle.incubator.apache.org/general/downloads.html>
> 2. Add the release to the history page
> <http://eagle.incubator.apache.org/general/history.html>
> 2. Update the "News" section in the podling status page
> <http://incubator.apache.org/projects/eagle.html>.
> 3. Update how to release page with your experience
>
>
>
>
>
>
>
> On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <ar...@gmail.com>
> wrote:
>
>> I agree with Julian. Edward is starting to collect the list of features
>> that are ready. I'm guessing Michael Wu will be a good release manager and
>> start getting educated on the apache process.
>>
>> Thanks,
>> Arun
>>
>>
>>
>> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org> wrote:
>>
>> > It’s difficult to describe the “licensing issues”. I suggest that you
>> > nominate a release manager and that person subscribes to the
>> > general@incubator list [1] and follows the discussions there. Watch the
>> > kind of due diligence that people such as Justin McLean apply to the
>> > releases, e.g. the Freemarker release [2]. (It seems onerous but is much
>> > appreciated by your community, because it means they are getting
>> spotlessly
>> > clean IP.)
>> >
>> > You will need to go through the same process: after a vote on this dev
>> > list, there is a second vote on the generator@incubator list.
>> >
>> > I can’t stress this strongly enough: The actual features (and bugs) in
>> the
>> > first release is very unimportant. It is all about the legal packaging,
>> and
>> > the process by which you make the release. No reason not to start now.
>> >
>> > Julian
>> >
>> > [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
>> >
>> > [2]
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
>> >
>> > > On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
>> > yonzhang@ebay.com> wrote:
>> > >
>> > > Thanks for initiating this discussion. I also wonder how to do the
>> first
>> > > release, what it the timing, what is the version number and what
>> features
>> > > we should include and what is release notes.
>> > >
>> > > But I am not aware of licensing issues. Does that because that not all
>> > our
>> > > source files are for apache license so we need explicitly tell that in
>> > > public?
>> > >
>> > > I volunteer to collect the features for the first release. A lot more
>> > work
>> > > should be identified while we are progressing.
>> > >
>> > > Thanks
>> > > Edward
>> > >
>> > > On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
>> > >
>> > >> Hi eagle community,
>> > >>
>> > >> How¹s progress on the first Eagle release?
>> > >>
>> > >> The Eagle project is progressing at an admirable rate in terms of
>> > >> features and community engagement. However, you¹ve not yet made a
>> > >> release. Making a release is more tricky than you would imagine ‹ and
>> > >> it¹s usually due to licensing issues, not due to bugs or other code
>> > >> issues ‹ so the first one takes a month or two. But making releases
>> is a
>> > >> key part of learning the Apache way and demonstrating that you¹re
>> ready
>> > >> to graduate; and, it helps to build community.
>> > >>
>> > >> Also remember that the project does not need to be ³perfect². Your
>> first
>> > >> release will have lots of bugs in it. If it compiles and has a
>> README,
>> > >> that is enough.
>> > >>
>> > >> Julian
>> > >>
>> > >
>> >
>> >
>>
>>
>> --
>> Arun Karthick
>> 201-850-9399
>>
>
>
Re: Release?
Posted by Prasad Mujumdar <pr...@apache.org>.
@Julian, strong +1 to making release soon. Thanks for bring that up.
@Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based on
my experience with other incubating project releases (as Julian mentioned,
primarily based on Justin's feedback in past) there some work that still
needed. We EAGLE-115 to tracking that. I will try to prioritize getting a
patch ready for that.
Looks like we don't have a 'how to release' page that outlines the release
steps. Here's a draft that I put together (using some of the existing
incubator project templates).
@Ed and @Arun, if one of you could give me access to the wiki, I can upload
the draft there so that community members can directly edit the page.
*How to Release*
This document describes the release process for Apache Eagle release from
Incubator. This is a working progress document till we have a few releases
and ironed out the process.
*Release manager*
Someone from the community should volunteer to become a release manager(RM)
and coordinate the release process. The release steps listed below will
mostly be carried out by the release manager. Ideally this person should be
a committer or PPMC member, however it should be fine for a contributor to
take that responsibility with one of the committer or PPMC to mentor
him/her to make the release.
The Release Manager (RM) must go through the policy document to understand
all the tasks and responsibilities of running a release. Frequently asked
questions for making Apache releases are available on Releases FAQ
<http://www.apache.org/dev/release.html>page. Guide to Release Management
During Incubation
<http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager>
also
has good information on best practices for releasing artifacts from an
incubating Apache project.
*Give a heads up*
The RM should first create an umbrella issue to create the release and then
setup a timeline for release branch point. The community should decide on
the cutoff point for the release branch on the release discussion thread.
To: dev@eagle.incubator.apache.org
Subject: Work on $release release has started
Created a tracking jira (jira#) for the eagle $release and plan to branch
tentatively on $date.
What would you like to see included?
Thanks,
$RM
*Sanitize JIRA*
1. Before a release is done, make sure that any issues that are *fixed *have
their fix version setup correctly. Run the following JIRA query to see
which resolved issues do not have their fix version set up correctly:
2. project = eagle and resolution = fixed and fixVersion is empty
3.
The result of the above query should be empty. If some issues do show up
in this query that have been fixed since the last release, please bulk-edit
them to set the fix version to '<releaseVersion>'.
4. Move the unresolved jiras to the next release
5. project = eagle and fixVersion = <releaseVersion> and status not in(
resolved, done, Accepted, Closed)
6.
7. You can also run the following query to make sure that the
issues fixed for the to-be-released version look accurate:
8. project = eagle and fixVersion = '<releaseVersion>'
9.
10. Finally, check out the output of the *JIRA release note tool*
<https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectName=eagle>
to
see which JIRAs are included in the release, in order to do a sanity check.
*Creating Release Artifacts*
*Communicate with the community*
1. Send an email to dev list to notify that you are about to
branch. Ask to hold off any commits until this is finished.
2. Send another email after branching is done.
*Preparing branches*
1. Create a release branch
1. Clone fresh repository copy
2. git clone https://
git-wip-us.apache.org/repos/asf/incubator-eagle.git
cd eagle
3.
4. Checkout master branch
5. git checkout master
6.
7. Check that current HEAD points to commit on which you want to
base new release branch. Checkout particular commit if not.
8. git log # Check current branch history. HEAD should point to
commit that you want to be base for your release branch
git checkout <releaseBaseCommit> # Check out particular commit that
should be base for release branch if -^
9.
10. Create new release branch with name "branch-$version"
11. git checkout -b branch-<releaseVersion>
12.
13. Update CHANGELOG in the trunk to indicate the changes going into
the new version.
The change list can be swiped from the *JIRA release note tool*
<https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314720>
(use the "text" format for the change log). See JIRA Cleanup above
to ensure that the release notes generated by this tool are what you are
expecting.
14. Remove -SNAPSHOT from the release branch and commit
15. find . -name pom.xml | xargs sed -i ""
-e "s/X.Y.0-SNAPSHOT/X.Y.0/" or mvn versions:set -DnewVersion=X.Y.0
-DgenerateBackupPoms=false
git add .
git commit -m "EAGLE-XXXX: Removing -SNAPSHOT from X.Y release branch"
16.
17. Check your changes and push new branch to Apache repository
18. mvn *install*
git push origin branch-<releaseVersion>
19.
20. Check that branch was correctly propagated to Apache repository.
2. Prepare the master for next release (<releaseVersion+1>)
3. git checkout master
find . -name pom.xml | xargs sed -i "" -e "s/<releaseVersion>-SNAPSHOT/
<releaseVersion+1>-SNAPSHOT/" or mvn versions:set
-DnewVersion=1.3.0-SNAPSHOT -DgenerateBackupPoms=false
git add .
git commit -m "EAGLE-XXXX: Preparing for eagle <releaseVersion+1>
development"
git push origin master:master
4.
5. Send an email announcing new branch
To: dev@eagle.incubator.apache.org
6. Subject: New release branch <releaseVersion>
7.
8.
9. I've just created new release branch for upcoming <releaseVersion>
incubating release.
10. Please continue committing to master branch as usual.
11. I'll cherry-pick commits to branch-<releaseVersion> on per needed
basis.
12.
13.
14. Thanks,
15. $RM
*Create release tar balls*
1. Check out release branch
2. git checkout branch-<ReleaseVersion>
3.
4. Create tag on this commit to identify precise point where the RC was
generated and push this tag to main repository
5. git tag -a release-<ReleaseVersion> -m "Eagle <ReleaseVersion>
incubating release"
#Make sure compiles/tests run fine and rat check is fine
mvn clean install -DskipTests
mvn test
mvn verify -DskipTests (to do the rat check)
git push origin release-<ReleaseVersion>
6.
7. If an rc1, rc2, etc is needed, delete that tag before creating a new
one:
8. git tag -d release-<releaseVersion>
git push origin :refs/tags/release-<releaseVersion>
9.
10. Create temporary directory where you'll be preparing all required
artifacts
11. mkdir -p /tmp/eagle-release-preparations
12.
13. Create source artifact and move it to your temporary directory
14. git archive --format=tar
--prefix=apache-eagle-<releasVersion>-incubating-src/
HEAD | gzip > /tmp/eagle-release-preparations/apache-eagle-
<releaseVersion>-incubating-src.tar.gz
15.
*Sanity Check*
1. Make sure the tar and the rc match
2. cd /tmp/eagle-release-preparations
tar -xvf apache-eagle-<releaseVersion>-incubating-src.tar.gz
#Do a fresh clone of the tag
git clone https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
<http://git-wip-us.apache.org/repos/asf/incubator-sentry.git>
cd incubator-eagle/
git checkout tags/release-<releaseVersion>
cd ..
diff -r incubator-eagle apache-eagle-<releaseVersion>-incubating-src
3.
4. Make sure code compiles and tests pass on the untared src.
5. cd apache-eagle-<releaseVersion>-incubating-src
mvn clean install -DskipTests
mvn test
mvn verify -DskipTests (to do the rat check)
6.
*Create signatures and check sums *
All artifacts must be signed and checksummed. In order to sign a
release you will need a PGP key. You should get your key signed by a few
other people. You will also need to recv their keys from a public key
server. See the Apache release signing
<https://www.apache.org/dev/release-signing> page for more
details. If you add your PGP key fingerprint to your Apache profile, your
key should automatically be added to
https://people.apache.org/keys/group/eagle.asc
<https://people.apache.org/keys/group/sentry.asc>
1. Change your working directory to the temporal one
cd /tmp/eagle-release-preparations
2. Sing each file with your key
for file in *.tar.gz; do gpg --armor --output $file.asc --detach-sig
$file; done
3. You can immediately verify your signature
for file in *.tar.gz; do gpg --verify $file.asc $file; done
4. Create md5 check sum
for file in *.tar.gz; do md5sum $file > $file.md5; done
5. Create sha1 check sum
for file in *.tar.gz; do sha1sum $file > $file.sha; done
*Upload artifacts*
Upload artifacts and all created check sums with signatures to
https://dist.apache.org/repos/dist/dev/incubator/eagle
<https://dist.apache.org/repos/dist/dev/incubator/sentry>
*Update KEYS file*
If your PGP key is not yet in the project's KEYS file, you need to
first add that in. To do this, checkout the KEYS file and update it using
the following commands:
$ svn co https://dist.apache.org/repos/dist/release/incubator/eagle
<https://dist.apache.org/repos/dist/release/incubator/sentry>
eagle-release
$ cd eagle-release
$ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >> KEYS
$ svn commit -m "Adding PGP public key to KEYS file" KEYS
Once this file has been updated, you need to publish it in the
appropriate dist directory for the project on
http://www.apache.org/dist. To do this, you must copy the file as
follows:
$ scp KEYS people.apache.
org:/www/www.apache.org/dist/incubator/eagle/KEYS
<http://org/www/www.apache.org/dist/incubator/sentry/KEYS>
This will take some time to propagate in which you can continue with
the other steps of the release process.
Verifying a release candidate
Following are the typical things we need to verify before voting on a
release candidate. And the release manager should verify them too before
calling out a vote.
- Make sure RCs are hosted @
https://dist.apache.org/repos/dist/dev/incubator/eagle
<https://dist.apache.org/repos/dist/dev/incubator/sentry>
- Should be in format apache-$project-$version-incubating.tar.gz
- Verify Signatures and hashes. You may have to import the public
key of the release manager to verify the signatures. (gpg
--recv-key <last8 of public key>)
- git tag matches the released bits (diff -rf)
- Can compile successfully from source
- Verify DISCLAIMER, NOTICE and LICENCE (year etc)
- All files have correct headers (Rat check should be clean - mvn
verify)
- Make sure there are no conflicting licenses (TODO: how)
- No jar files or the like in the release
-
Running the vote
Voting has to be done on dev@eagle.incubator.apache.org
<de...@sentry.incubator.apache.org> list followed by
general@incubator.apache.org. You can close the vote after voting
period expires and you accumulate sufficient votes.
Call for voting on dev list (PPMC)
To: dev@eagle.incubator.apache.org
Subject: [VOTE] Release Eagle incubating version <releaseVersion>
This is the incubator release of Apache Eagle, version
<releaseVersion>-incubating.
It fixes the following issues: http://s.apache.org/VlU
Source files :
https://dist.apache.org/repos/dist/dev/incubator/eagle/eagle-
<releaseVersion>/
Tag to be voted on (rc#):
https://git-wip-us.apache.org/repos/asf/incubator-eagle/?p=incubator-eagle.git;a=commit;h=
<commit-hash-of-the-tag>
Eagle's KEYS containing the PGP key we used to sign the release:
https://people.apache.org/keys/group/eagle.asc (or
http://www.apache.org/dist/incubator/eagle/KEYS for non committers)
Note that this is a source only release and we are voting on the
source: tag=release-<releaseVersion>, SHA=<release_SHA> (You can get the
hash of the tag by doing "git rev-list release-<releaseVersion> | head -n
1" )
Vote will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Thanks,
$RM
The vote has to be called first on the dev list. Upon receiving 3 +1s
from the PPMC, reply to the voting thread and prefixing *[RESULT]* to
the subject line with the results.
To: dev@eagle.incubator.apache.org
Subject: [RESULT][VOTE] Release eagle incubating version
<releaseVersion>
Voting is now closed and has passed with the following tally.
PPMC +1: <PPMC voters>
Others +1: <other community members who voted>
A vote will now be called on general@incubator.apache.org.
$RM
Voting on @general
The vote should be now called on general@incubator.apache.org
<ge...@incubator.apache.org.> for IPMC votes. Binding votes are
from IPMC member, and non-binding votes are from PPMC members.
To: general@incubator.apache.org
Subject: [VOTE] Release Eagle incubating version <releaseVersion>
This is the first incubator release of Apache Eagle, version
<releaseVersion>-incubating.
<Same as above...>
A vote on releasing this package has already passed in Apache Eagle
PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...).
Vote will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
<RM>
[1] -
http://markmail.org/search/?q=eagle%20vote%20release#query:eagle%20vote%20release+page:1+mid:sqrwevgsxakqatqk+state:results
By convention, vote closing email is sent to
general@incubator.apache.org by replying to the voting thread and
prefixing *[RESULT]* to the subject line. This method keeps the
closing email in the same thread with the voting emails for better record
keeping in the mail archive.
Example close email:
To: general@incubator.apache.org
Subject: [RESULT][VOTE] Release Eagle incubating version
<releaseVersion>
Voting is now closed and has passed with the following tally,
Binding +1s: <IPMC binding voter list>
Non binding +1s: <PPMC voter list>
Thanks to everyone who voted! I'll continue with the rest of the
release process.
$RM
Rolling out the Release
Close JIRA version
You need to close the release in JIRA so that everyone knows that
your version should not be used as "fixVersion" for new bugs. Go to
JIRA "Administer project" page and follow "Versions" in left menu.
Table with list of all releases should appear, click on additional menu
on the right of your release and choose "Release" option. Submit
release date and you're done.
Upload the artifacts
In order to release you have to checkout release repository
located on https://dist.apache.org/repos/dist/release/incubator/eagle/
<https://dist.apache.org/repos/dist/release/incubator/sentry/> and
add release artifacts there.
svn co https://dist.apache.org/repos/dist/release/incubator/eagle/
eagle-release
cd eagle-release
mkdir <releaseVersion>-incubating/
cp $source_to_your_artifacts <releaseVersion>-incubating/
svn add <releaseVersion>-incubating
It may take up to 24 hours for all mirrors to sync up (
http://www.apache.org/dyn/closer.cgi/incubator/eagle/
<http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
Announce the release
Send an email to announce@apache.org (the from: address must be @
apache.org). For example,
To: announce@apache.org, dev@eagle.incubator.apache.org
Subject: [ANNOUNCE] Apache Eagle <releaseVersion> incubating released
The Apache Eagle community is happy to announce the release of
version <releaseVersion>-incubating from the Apache Incubator.
Apache Eagle
is a monitoring framework for Hadoop to identify access to
sensitive data,
recognize malicious activities and take action in real time.
The release bits are available at:
http://www.apache.org/dyn/closer.cgi/incubator/eagle
The change list is available at: <chageLogLocation>
We would like to thank all contributors who made the release possible.
Disclaimer
Apache Eagle is an effort undergoing incubation at The Apache
Software Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful
ASF projects. While incubation status is not necessarily a reflection of
the completeness or stability of the code, it does indicate that the
project has yet to be fully endorsed by the ASF.
Regards,
Eagle Community
Update the website
1. Update the website:
1. Add the release to the downloads
<http://eagle.incubator.apache.org/general/downloads.html>
2. Add the release to the history page
<http://eagle.incubator.apache.org/general/history.html>
2. Update the "News" section in the podling status page
<http://incubator.apache.org/projects/eagle.html>.
3. Update how to release page with your experience
On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <ar...@gmail.com>
wrote:
> I agree with Julian. Edward is starting to collect the list of features
> that are ready. I'm guessing Michael Wu will be a good release manager and
> start getting educated on the apache process.
>
> Thanks,
> Arun
>
>
>
> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org> wrote:
>
> > It’s difficult to describe the “licensing issues”. I suggest that you
> > nominate a release manager and that person subscribes to the
> > general@incubator list [1] and follows the discussions there. Watch the
> > kind of due diligence that people such as Justin McLean apply to the
> > releases, e.g. the Freemarker release [2]. (It seems onerous but is much
> > appreciated by your community, because it means they are getting
> spotlessly
> > clean IP.)
> >
> > You will need to go through the same process: after a vote on this dev
> > list, there is a second vote on the generator@incubator list.
> >
> > I can’t stress this strongly enough: The actual features (and bugs) in
> the
> > first release is very unimportant. It is all about the legal packaging,
> and
> > the process by which you make the release. No reason not to start now.
> >
> > Julian
> >
> > [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
> >
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
> >
> > > On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
> > yonzhang@ebay.com> wrote:
> > >
> > > Thanks for initiating this discussion. I also wonder how to do the
> first
> > > release, what it the timing, what is the version number and what
> features
> > > we should include and what is release notes.
> > >
> > > But I am not aware of licensing issues. Does that because that not all
> > our
> > > source files are for apache license so we need explicitly tell that in
> > > public?
> > >
> > > I volunteer to collect the features for the first release. A lot more
> > work
> > > should be identified while we are progressing.
> > >
> > > Thanks
> > > Edward
> > >
> > > On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
> > >
> > >> Hi eagle community,
> > >>
> > >> How¹s progress on the first Eagle release?
> > >>
> > >> The Eagle project is progressing at an admirable rate in terms of
> > >> features and community engagement. However, you¹ve not yet made a
> > >> release. Making a release is more tricky than you would imagine ‹ and
> > >> it¹s usually due to licensing issues, not due to bugs or other code
> > >> issues ‹ so the first one takes a month or two. But making releases
> is a
> > >> key part of learning the Apache way and demonstrating that you¹re
> ready
> > >> to graduate; and, it helps to build community.
> > >>
> > >> Also remember that the project does not need to be ³perfect². Your
> first
> > >> release will have lots of bugs in it. If it compiles and has a README,
> > >> that is enough.
> > >>
> > >> Julian
> > >>
> > >
> >
> >
>
>
> --
> Arun Karthick
> 201-850-9399
>
Re: Release?
Posted by Henry Saputra <he...@gmail.com>.
Friendly reminder that Release manager should come from PPMC since it may
need access to ASF resources.
- Henry
On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <ar...@gmail.com>
wrote:
> I agree with Julian. Edward is starting to collect the list of features
> that are ready. I'm guessing Michael Wu will be a good release manager and
> start getting educated on the apache process.
>
> Thanks,
> Arun
>
>
>
> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org> wrote:
>
> > It’s difficult to describe the “licensing issues”. I suggest that you
> > nominate a release manager and that person subscribes to the
> > general@incubator list [1] and follows the discussions there. Watch the
> > kind of due diligence that people such as Justin McLean apply to the
> > releases, e.g. the Freemarker release [2]. (It seems onerous but is much
> > appreciated by your community, because it means they are getting
> spotlessly
> > clean IP.)
> >
> > You will need to go through the same process: after a vote on this dev
> > list, there is a second vote on the generator@incubator list.
> >
> > I can’t stress this strongly enough: The actual features (and bugs) in
> the
> > first release is very unimportant. It is all about the legal packaging,
> and
> > the process by which you make the release. No reason not to start now.
> >
> > Julian
> >
> > [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
> >
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
> >
> > > On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
> > yonzhang@ebay.com> wrote:
> > >
> > > Thanks for initiating this discussion. I also wonder how to do the
> first
> > > release, what it the timing, what is the version number and what
> features
> > > we should include and what is release notes.
> > >
> > > But I am not aware of licensing issues. Does that because that not all
> > our
> > > source files are for apache license so we need explicitly tell that in
> > > public?
> > >
> > > I volunteer to collect the features for the first release. A lot more
> > work
> > > should be identified while we are progressing.
> > >
> > > Thanks
> > > Edward
> > >
> > > On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
> > >
> > >> Hi eagle community,
> > >>
> > >> How¹s progress on the first Eagle release?
> > >>
> > >> The Eagle project is progressing at an admirable rate in terms of
> > >> features and community engagement. However, you¹ve not yet made a
> > >> release. Making a release is more tricky than you would imagine ‹ and
> > >> it¹s usually due to licensing issues, not due to bugs or other code
> > >> issues ‹ so the first one takes a month or two. But making releases
> is a
> > >> key part of learning the Apache way and demonstrating that you¹re
> ready
> > >> to graduate; and, it helps to build community.
> > >>
> > >> Also remember that the project does not need to be ³perfect². Your
> first
> > >> release will have lots of bugs in it. If it compiles and has a README,
> > >> that is enough.
> > >>
> > >> Julian
> > >>
> > >
> >
> >
>
>
> --
> Arun Karthick
> 201-850-9399
>
Re: Release?
Posted by arunkarthick m <ar...@gmail.com>.
I agree with Julian. Edward is starting to collect the list of features
that are ready. I'm guessing Michael Wu will be a good release manager and
start getting educated on the apache process.
Thanks,
Arun
On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org> wrote:
> It’s difficult to describe the “licensing issues”. I suggest that you
> nominate a release manager and that person subscribes to the
> general@incubator list [1] and follows the discussions there. Watch the
> kind of due diligence that people such as Justin McLean apply to the
> releases, e.g. the Freemarker release [2]. (It seems onerous but is much
> appreciated by your community, because it means they are getting spotlessly
> clean IP.)
>
> You will need to go through the same process: after a vote on this dev
> list, there is a second vote on the generator@incubator list.
>
> I can’t stress this strongly enough: The actual features (and bugs) in the
> first release is very unimportant. It is all about the legal packaging, and
> the process by which you make the release. No reason not to start now.
>
> Julian
>
> [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
>
> [2]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
>
> > On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
> yonzhang@ebay.com> wrote:
> >
> > Thanks for initiating this discussion. I also wonder how to do the first
> > release, what it the timing, what is the version number and what features
> > we should include and what is release notes.
> >
> > But I am not aware of licensing issues. Does that because that not all
> our
> > source files are for apache license so we need explicitly tell that in
> > public?
> >
> > I volunteer to collect the features for the first release. A lot more
> work
> > should be identified while we are progressing.
> >
> > Thanks
> > Edward
> >
> > On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
> >
> >> Hi eagle community,
> >>
> >> How¹s progress on the first Eagle release?
> >>
> >> The Eagle project is progressing at an admirable rate in terms of
> >> features and community engagement. However, you¹ve not yet made a
> >> release. Making a release is more tricky than you would imagine ‹ and
> >> it¹s usually due to licensing issues, not due to bugs or other code
> >> issues ‹ so the first one takes a month or two. But making releases is a
> >> key part of learning the Apache way and demonstrating that you¹re ready
> >> to graduate; and, it helps to build community.
> >>
> >> Also remember that the project does not need to be ³perfect². Your first
> >> release will have lots of bugs in it. If it compiles and has a README,
> >> that is enough.
> >>
> >> Julian
> >>
> >
>
>
--
Arun Karthick
201-850-9399
Re: Release?
Posted by Julian Hyde <jh...@apache.org>.
It’s difficult to describe the “licensing issues”. I suggest that you nominate a release manager and that person subscribes to the general@incubator list [1] and follows the discussions there. Watch the kind of due diligence that people such as Justin McLean apply to the releases, e.g. the Freemarker release [2]. (It seems onerous but is much appreciated by your community, because it means they are getting spotlessly clean IP.)
You will need to go through the same process: after a vote on this dev list, there is a second vote on the generator@incubator list.
I can’t stress this strongly enough: The actual features (and bugs) in the first release is very unimportant. It is all about the legal packaging, and the process by which you make the release. No reason not to start now.
Julian
[1] http://mail-archives.apache.org/mod_mbox/incubator-general/
[2] http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
> On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <yo...@ebay.com> wrote:
>
> Thanks for initiating this discussion. I also wonder how to do the first
> release, what it the timing, what is the version number and what features
> we should include and what is release notes.
>
> But I am not aware of licensing issues. Does that because that not all our
> source files are for apache license so we need explicitly tell that in
> public?
>
> I volunteer to collect the features for the first release. A lot more work
> should be identified while we are progressing.
>
> Thanks
> Edward
>
> On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
>
>> Hi eagle community,
>>
>> How¹s progress on the first Eagle release?
>>
>> The Eagle project is progressing at an admirable rate in terms of
>> features and community engagement. However, you¹ve not yet made a
>> release. Making a release is more tricky than you would imagine ‹ and
>> it¹s usually due to licensing issues, not due to bugs or other code
>> issues ‹ so the first one takes a month or two. But making releases is a
>> key part of learning the Apache way and demonstrating that you¹re ready
>> to graduate; and, it helps to build community.
>>
>> Also remember that the project does not need to be ³perfect². Your first
>> release will have lots of bugs in it. If it compiles and has a README,
>> that is enough.
>>
>> Julian
>>
>
Re: Release?
Posted by "Zhang, Edward (GDI Hadoop)" <yo...@ebay.com>.
Thanks for initiating this discussion. I also wonder how to do the first
release, what it the timing, what is the version number and what features
we should include and what is release notes.
But I am not aware of licensing issues. Does that because that not all our
source files are for apache license so we need explicitly tell that in
public?
I volunteer to collect the features for the first release. A lot more work
should be identified while we are progressing.
Thanks
Edward
On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
>Hi eagle community,
>
>How¹s progress on the first Eagle release?
>
>The Eagle project is progressing at an admirable rate in terms of
>features and community engagement. However, you¹ve not yet made a
>release. Making a release is more tricky than you would imagine ‹ and
>it¹s usually due to licensing issues, not due to bugs or other code
>issues ‹ so the first one takes a month or two. But making releases is a
>key part of learning the Apache way and demonstrating that you¹re ready
>to graduate; and, it helps to build community.
>
>Also remember that the project does not need to be ³perfect². Your first
>release will have lots of bugs in it. If it compiles and has a README,
>that is enough.
>
>Julian
>