Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

[1e911d]: doc / editors / new-entry-checkin.html Maximize Restore History

Download this file

new-entry-checkin.html    115 lines (81 with data), 5.0 kB

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
<!DOCTYPE public "-//w3c//dtd html 4.01 transitional//en"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>How to check in a new submission</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<h2>New Submissions (editors only)</h2>
<p>[<a href="#setup">setup</a>] [<a href="#new">new submission</a>] [<a href="#devel">new submission in devel</a>]</p>
<p><a name="setup"><b>Mercurial Setup</b></a></p>
<p>As editor you have at least two working copies of the repository: current
release branch and development version.</p>
<ul>
<li>
Start by making a directory <code>~/afp</code> where the different branches
will go.
</li>
<li>To set up the release version, in that directory do (fill in 20XX and login)<br>
<code>hg clone ssh://&lt;login&gt;@hg.code.sf.net/p/afp/afp-20XX release</code>
</li>
<li>for development<br>
<code>hg clone ssh://&lt;login&gt;@hg.code.sf.net/p/afp/code devel
</code></li>
</ul>
<p>You might need to set up ssh keys on sourceforge for this to work. More information on ssh at sourceforge is available <a
href="http://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys">here
[ssh keys]</a>.</p>
<p>New submissions, changes to the web site and to admin scripts go into
afp/release. A script automatically propagates these to the development
branch once a day.</p>
<p>Maintenance and changes on existing submissions all occur in afp/devel and go
properly public with the next Isabelle release (they are only available as
(public) development tar.gz's)</p>
<p><a name="new"><b>New Submissions</b></a></p>
<p>Everything happens in the release branch <tt>afp/release</tt>.</p>
<ol>
<li>unpack tar file and move new entry to <tt>afp/release/thys</tt></li>
<li>create/adjust <tt>config</tt> file (template in <tt>thys/Example-Submission/config</tt>)</li>
<li>make sure there is a <tt>thys/entryname/ROOT</tt> file and add <code>entryname</code> to <code>thys/ROOTS</code>. For the former see the template in <tt>thys/Example-Submission/ROOT</tt>. In particular the entry should be in chapter AFP, and group <tt>(AFP)</tt>, i.e.
<pre>
chapter AFP
session foo (AFP) = bar +
</pre></li>
<li>to check, run in <tt>afp/release/thys</tt><br>
<code>../admin/testall -r Isabelle20XX -c &lt;name&gt;</code><br>
(be sure to have ISABELLE_RELEASES set to the path where Isabelle releases are kept, e.g. /home/proj/isabelle/)
</li>
<li>check license headers: if the authors want the code released under LGPL instead of BSD, each file should mention "License: LGPL" in the header.</li>
<li><code>hg add</code> and <code>hg commit</code> the new submission</li>
<li>Enter data for author/abstract/index/etc in the file
<code>metadata/metadata</code>. Make sure that your editor uses UTF-8 encoding
for this file to preserve special characters. If the entry uses a new topic or
category, add it to metadata/topics (make sure there is an empty line at the
end of the file). </li>
<li>Generate the new web site by running <code>../admin/sitegen</code> .</li>
<li>Use <code>hg st</code> and <code>hg diff</code> to make sure the generated html makes sense. The diff should be small and concern the new entry only.</li>
<li><code>hg add</code> and <code>hg commit</code> the web site updates.</li>
<li>finally, when you are happy with everything, <code>hg push</code> all changes to sourceforge. The publish script will refuse to publish if the changes aren't pushed.
<li>to publish the changes to the web, run<br>
<code>
cd ../admin<br>
./publish -r Isabelle201X &lt;name&gt;
</code>
<p>
This will check out the Isabelle201X (=release) version of the archive from
sourceforge, will run the session &lt;name&gt; to generate
HTML, produce a <code>.tar.gz</code> for the archive and for the entry, and will update the
web pages on the server. The script will ask before it copies, so you can check locally if everything is as you want it.
</p></li>
<li>That's it. Changes should show up at <a href="http://afp.sf.net">http://afp.sf.net</a></li>
</ol>
<p><a name="devel"><b>New submission in devel</b></a></p>
<p>
Although it is a condition of submission that the entry works with the current stable Isabelle version, occasionally it happens that a submission does not work with the stable version and cannot be backported, but is important/good enough to include anyway. In this case, we can't release the submission on the main web site yet, but we can add it to the development version of the archive, such that it is at least available to those who are working with the current Isabelle development snapshot.</p>
<p>
The check-in procedure is the same as for a normal release entry, apart from the fact that everything happens in the devel instead of release directory and that the last step (publish) is omitted.</p>
<p>
The authors of the entry should be notified that the entry will only show up on the front page when the next Isabelle version is released.</p>
</body>
</html>