suggested additions: get and insert the latest libtool, which includes files: libtool.m4 ltgcc.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4, all way-old currently in gcc-7
get latest autoconf. 2.64 in use, latest is 2.69 get latest texinfo.tex, not one 5 years old GNU is supposed to be a unified system, but it's not even up-to-date with its own software. I'm trying to debug a libtool bug but I am forced to downgrade autoconf... getting too hard to bother. It's not too late to fix it in gcc-7... On Mon, Mar 13, 2017 at 1:31 AM, Richard Biener <[email protected]> wrote: > On Sun, Mar 12, 2017 at 11:45 PM, Gerald Pfeifer <[email protected]> wrote: >> On Wed, 24 Aug 2016, Richard Biener wrote: >>> We've been creating those lazily over the last decade. We can change >>> that, an entry for releasing.html is appreciated then so we don't forget. >> >> And here we go, in time for the release of GCC 7 / branching of GCC 8. >> >> (Except, this time I went ahead and already created gcc-8/changes.html >> so that you guys don't have to worry about that. ;-) >> >> Note, I added this to branching.html, not releasing.html, not the least >> since branching.html already had the creation of other web pages for the >> new release series and that also seems the more appropriate point time- >> wise. Agreed? > > Yes. > > Thanks, > Richard. > >> Gerald >> >> >> Index: branching.html >> =================================================================== >> RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v >> retrieving revision 1.32 >> diff -u -r1.32 branching.html >> --- branching.html 28 Jun 2014 10:34:16 -0000 1.32 >> +++ branching.html 12 Mar 2017 22:37:59 -0000 >> @@ -7,6 +7,8 @@ >> <body> >> <p>This page documents the procedure for making a new release branch.</p> >> >> +<h2>Preparations</h2> >> + >> <ol> >> <li>Execute the following commands, substituting appropriate version >> numbers: >> @@ -38,15 +40,25 @@ >> for the next major release in the <code>wwwdocs</code> repository and >> populate it with initial copies of <code>changes.html</code> and >> <code>criteria.html</code>.</li> >> +</ol> >> >> -<li>Add <code>index.html</code> and <code>buildstat.html</code> pages >> -to the directory corresponding to the newly created release branch. >> -Update the toplevel <code>buildstat.html</code> accordingly.</li> >> +<h2>Web Site Updates</h2> >> + >> +<ol start="6"> >> +<li>Add <code>index.html</code> and <code>changes.html</code> pages >> +based on the previous release branch to the directory corresponding to >> +the newly created release branch.</li> >> + >> +<li>Add <code>buildstat.html</code> and update the toplevel >> +<code>buildstat.html</code> accordingly.</li> >> >> <li>Update the toplevel <code>index.html</code> page to show the new active >> release branch, the current release series, and active development >> (mainline). Update the version and development stage for mainline.</li> >> +</ol> >> >> +<ol start="9"> >> <li>Update <code>maintainer-scripts/crontab</code> on the mainline by >> adding an entry to make snapshots of the new branch and adjusting the >> version number of the mainline snapshots. >> @@ -67,7 +79,11 @@ >> <a href="translation.html#submit">Send them >> to the translation project</a> if no snapshot of this version was sent >> during development stage 3 or 4.</li> >> +</ol> >> >> +<h2>Bugzilla Updates</h2> >> + >> +<ol start="11"> >> <li>Create new versions in Bugzilla corresponding to the new mainline >> version. This can be accomplished by choosing "products", choosing "gcc", >> and editing the versions. Please do <strong>not</strong> delete old >> @@ -85,7 +101,6 @@ >> <li>Ask Daniel Berlin to adjust all PRs with the just-branched version >> in their summary to also contain the new version corresponding to >> mainline.</li> >> - >> </ol> >> >> </body>
