[261c37]: releasechecklist Maximize Restore History

Download this file

releasechecklist    193 lines (190 with data), 8.5 kB

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="content-type">
  <title>OProfile release checklist</title>
</head>
<body>
<h1><a name="OProfile_release_checklist"></a>OProfile release checklist</h1>
<span style="font-weight: bold;"><br>
Note:</span> The OProfile maintainer must give you admin privileges to
put out a release.<br>
<br>
<ol>
  <li>
    Create/update Release Notes for new release
    <ul>
      <li>Checkout or create release-notes/oprofile-&lt;new-version&gt; from 
      the oprofile-www project.  Any git log entry that fixes a user-visible bug should be
in the new release notes unless it was not reproducible in the last release.&nbsp;
All new user-visible features should also be in the release notes.
Note: The SourceForge download site for a release will display the associated release
notes file, and due to other gunk shown on the screen, lines are broken at 72 chars,
so try to keep line length under that 72 char limit.<br>
      </li>
    </ul>
  </li>
  <li>
    Check if sample data file format has changed (libop/op_sample_file.h) the since previous release.  If so,
bump OPD_VERSION (in libop/op_config.h) if it hasn't already been done.
  </li>
  <li>
    Change version to non-git and commit
  </li>
  <ul>
    <li>Change version in configure.ac's AM_INIT_AUTOMAKE</li>
    <li>Probably want to start with a
&lt;<span style="font-style: italic;">v.r.m</span>&gt;rc&lt;<span
 style="font-style: italic;">n</span>&gt;.&nbsp; Since this has to be
changed for
every release candidate, it's best not to commit this until the final
GA of the release.<br>
    </li>
  </ul>
  <li>
    Build and test a release tar file.
  </li>
  <ul>
    <li>./autogen.sh; ./configure; make dist. &nbsp; This produces a
tarball called oprofile-&lt;<span style="font-style: italic;">release</span>&gt;.tar.gz,
where "<span style="font-style: italic;">release</span>" is what
you specified in AM_INIT_AUTOMAKE.<br>
    </li>
    <li>Build and install the release tar file created in the above step.  When you run 'configure',
        use the following options:<br>
            <pre>[--prefix=&lt;op-install-dir&gt;] --with-java=&lt;jdk-install-dir&gt;</pre>
        Run the oprofile testsuite against the installed release -- ideally, on
        more than one system of different distros/architectures.
    </li>
    <li>Since the oprofile-tests testsuite does not include any Java profiling
        tests, do some manual Java app profiling.  Be sure the JVM uses oprofile's
        java agent library by way of the '-agentpath' or '-agentlib' option.
    </li>

  </ul>
  <li>
    Make a release (candidate) publicly available.

  <ol>
    <li>With a browser, go to the OProfile website and click on the
"SOURCEFORGE.NET" at the bottom left of the screen.&nbsp; Sign in with
your admin user ID.&nbsp; Right-click on the "Help" link
(to open it in a new tab or window), click the "Site Documentation" link and follow the instructions 
for "Using the File Manager".
</li>
<li>Click on the main 'oprofile' folder. For each release candidate (and, eventually, for the GA), create a
new folder, based on the release name (e.g., oprofile-0.9.5-rc1) and upload
your release tar ball into that folder.  After creating the next release candidate
(or GA), cut the tar ball from the previous release candidate folder and paste it
into oldfiles; then delete the folder it was in.
</li>
<li>Start by uploading the new oprofile-&lt;release&gt;.tar.gz file.
Then upload the release notes file, but rename it to
oprofile-&lt;release&gt;_readme so that it's obvious to users who
browse the project files. NOTE: It may take a few minutes for the files
to become 'downloadable' (i.e., 'clickable'), and you'll need to refresh the browser to see it.
   </li>
  <li>Go to project download page on SourceForge and verify that
the new release tar ball is listed there.  It will take some time for
the new release to be mirrored to all of the mirror sites.  Once you
can successfully download the tar ball from a SourceForge mirror, go
to the next step.
   </li>
   <li>For release candidates, post a message to the oprofile-list
with a URL to the download page for the release you just created and
paste the Release Notes into the message.  For GA release, continue
to the "Close fixed bugs" step.<br>
   </li>
   <li>Get testing feedback from the community.&nbsp; Return to
step 1 for each new release candidate (and, eventually, for the
GA).
    </li>
  </ol>
  </ul>
<p>
<em>The following steps are to be done once the decision is made
to GA and you've iterated over the previous steps again for the GA
release.</em>
</p>
  <li>
    Close fixed bugs
  </li>
  <ul>
    <li>Log into SourceForge with admin ID and close oprofile bugs that
have been
fixed in this release.&nbsp; <span style="font-weight: bold;">Note:</span>&nbsp;
Bugs for problems that are <span style="font-style: italic;">not</span>
reproducible in previous releases should
have been closed already.<br>
    </li>
  </ul>
  <li>
    Run the command <pre>'git tag RELEASE_&lt;v_r_m&gt;';  e.g, 'git tag RELEASE_0_9_4'</pre>
  </li>
  <ul>
    <li>After committing the change to configure.ac's AM_INIT_AUTOMAKE
for the GA release, cd into the checked-out oprofile directory and run
the 'git tag' and 'git push origin &lt;TagName&gt;' commands.<br>
    </li>
  </ul>
  <li>
    Update web page release-notes/, news, download, srcdoc/, doc/
  </li>
  <ul>
    <li>Do a 'git clone' of oprofile and
oprofile-www.</li>
    <li>In oprofile-www, make the following updates:<br>
	<ul><li>Edit the news/index.php and
	download/index.php files to point to the new release.</li>
	<li> Regenerate events files documentation.  To do this, you must first make
	a temporary change in the oprofile source code -- change the value of LINE_LEN
	in utils/ophelp from 99 to 999.  Do a 'make install' to put this change into effect for
	the actual generation of event doc. In your checked out oprofile-www dir, add new .php
        files in the docs directory for any new processor type that was added since last
        regeneration.  Also, add a new 'do_events ...' line in the all-events-doc.sh file for each
        new processor type. If any processor types were removed for this release,
	then also remove the generation for its events in all-events-doc.sh. Finally,
	make sure the docs/index.php is updated to reflect any new or removed processors.
	Now run 'sh all-events-doc.sh' and do a 'git diff'
	to verify the updates to the docs dir.</li>
	<li>Verify correctness/completeness
	of the new release-notes.  Any meaningful change seen when diffing docs/ subdir
	should be reported in the release-notes file.</li>
	</ul>
	Do 'git commit' and 'git push' of these changes.&nbsp; </li>
    <li>In oprofile, do ./autogen.sh, ./configure, and then cd into
doc/ and run 'make chunk'.&nbsp; Tar up the doc/ directory that gets created inside of
doc/.&nbsp; Then
cd into doc/srcdoc/ and run 'make'.&nbsp; Tar up the srcdoc/ directory.</li>
  </ul>
  <li>
    Sync website to oprofile-www git
  </li>
  <ul>
    <li>Navigate to SourceForge's Site Documentation (https://sourceforge.net/p/forge/documentation/Docs%20Home/).
Then click on the "Complete Documentation" link, and then click the "Interactive Shell Service" link.
See the instructions on that page on how to access SourceForge using ssh and scp.
Then ssh into SF with your admin ID and cd to oprofile's www directory
(/home/project-web/oprofile/htdocs/). There's a git dir there; do a 'git
pull' to update that directory with current data from the shared repo.</li>
    <li>scp the new doc and srcdoc tar balls created in the previous
step over to SF and untar them into the git dir.</li>
    <li>Ensure that any new files you create have write access for the
'oprofile' group (do 'chmod g+w' if necessary).</li>
    <li>Point your browser at http://oprofile.sourceforge.net/git/ and
verify the website, documentation, etc. looks OK.</li>
    <li>Make a backup of the parent (htdocs) directory; remove all
	files from htdocs/docs and htdocs/srcdoc; then copy all
	the stuff from the git dir into the parent htdocs dir to make it live.&nbsp;
	Now use your browser to verify that the actual OProfile website looks
OK.<br>
    </li>
  </ul>
  <li>
    Send release email
  </li>
  <li>
    Change AM_INIT_AUTOMAKE in configure.ac '&lt;<span
 style="font-style: italic;">v.r.m</span>&gt;git' and commit
  </li>
</ol>
</body>
</html>