octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave-Forge website / docs.html


From: Carnë Draug
Subject: Re: Octave-Forge website / docs.html
Date: Wed, 13 Aug 2014 15:22:51 +0100

On 12 August 2014 19:01, Julien Bect <address@hidden> wrote:
> [...]
>
> Easier said than done, I know, but perhaps is this a direction where I could
> contribute, if I knew where to start from... Is there some sort of "source
> code" for the website, somewhere ? I mean, a place where all the data and
> admin scripts for building all the html pages are located ?

I have prepared a repository with the octave-forge website. Feel free to clone
and change it but take note that many changes will need to be made in sync with
the generate_html package. That's all written in Octave and string manipulation
with Octave is not fun. There were a few things that do not appear on the
repository but are currently online:

* backups of NEWS and index page. The script I use for the release and
page update modifies those pages but keeps the previous page as backup
just in case. You will notice that there's tags in those pages so that
my script nows where to add new entries. Would be nice to have a plain
text file with the news and have the index and NEWS page parse that
file instead.
* da coda al fine. There's a coda directory with tarball, pdf, and
html pages which seem to be generated automatically. The source is in
the svn repository doc/coda. I guess this should either be merged into
the Octave core manual if it is still relevant.
* compare_plots. I only commited the index page. Aside that, there's a
matlab, gnuplot, and fltk directories with the generated plots
* doxygen. There are doxygen32, 34, 36, and 38 directories, each with
only a html directory. Then there's a symlink named doxygen which I
change to the doxygen of the latest version.
* old_packages and old_website. Both of those directories exist and
I'm keeping there "just because". I don't think there's any link to
them though.
* packages documentation. Each package has its own directory in
htdocs/ which is generated with the generate_html package. I guess all
of them should go in packages/ directory to avoid conflicts but
there's a lot of dependency on relative paths.
* octave-core documentation. This is treated like pretty much a normal
package, i.e., there's an octave/ directory in htdocs/ with the same
structure as the other packages (it is only missing an index.html). It
is also generated automatically with the generate_html package
* MIPS73-isoheaders.tar.gz in htdocs/
* octave_embed.tar.gz in htdocs/
* operators.html page in htdocs/ (this page is generated automatically
with the generate_html package)
* soctcl0.1.zip in htdocs/
* texmacs.pdf in htdocs/


The discussion has gone too long since my last reply so I'll address just a few
points.

On 13 August 2014 10:28, Julien Bect <address@hidden> wrote:
> Le 13/08/2014 11:14, c. a écrit :
>
>> On 13 Aug 2014, at 07:36, Julien Bect <address@hidden> wrote:
>>>
>>> Lengthy... and not fully automated, I assume ?
>>
>> actually it almost all automated,
>
> Ok. So my first goal will be to make it FULLY (and not almost) automated.
>
>>   what needs to be done is:
>>
>> 1) install ALL packages.
>
>
> Let's tackle this one first... Is there somewhere a "raw" list of all the
> packages that must be included ?

Take note that even the unmaintained packages have their documentation still
online and I would like to keep it that way:

http://octave.sourceforge.net/ad/index.html
http://octave.sourceforge.net/ann/index.html


> It seems that I can obtain it by parsing one of the following pages :
>
> http://octave.sourceforge.net/packages.php
>
> http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/
>
> but shouldn't there be a "source" for this somewhere (for the sake of
> argument, think of the extreme case where both the FRS data and the web data
> are lost on SF)

If you take a look at the project-web, you will notice that there's actually not
much on the pages that are not generated automatically. And there is a svn
repository with this content. It hasn't had any changes since 2009 but the
website has only had very small changes since then, most of them on content
which can easily be retrieved from the intrenet archive. I am aware that's not
the best way to do it, but to tackle this issue better would mean dropping
the ball on other OF responsabilities.

On the even extremer case that we also lose the files in the FRS (for those
following that do not know, that's the releases packages which are separated
from the web content), we can re-release from them from the repositories. It
is one of the OF requirements that we have the source for every single package
at time of release.

>> 2) patch generate_html to produce web pages with the new style
>> 3) run generate_package_html for each package
>> 4) upload all new html files to sourceforge
>>
>> Carnë, correct me if something is missing from the list.

This all assumes you can install all packages in any system. And run the
demos successfully. Can you install the windows package on a mac or Linux?
Can you handle all dependencies of all packages successfully? What about the
packages that disable some of its functionalities instead of simply refusing
to install? How will the demos of those functions appear? What if the version
of one of its dependency is wrong and gives wrong results?

Handling the html of packages was one of the things about automating when I
started but I could handle all of those cases. In my mind, the ideal would
be the maintainer add a tag to their repo, so that I could just update their
repo on my machine which would automatically create the release tarball and
documentation. But each package has its own little details. We can't, for
example, even assume a structure on the repository (see the ltfat package).
We can only assume it for the released package. In the end, it was too much
trouble so it continues to the job of a package maintainer to generate the
html of packages.

On 13 August 2014 12:23, Julien Bect <address@hidden> wrote:
>
> It seems a little unnatural to me to require that the whole OF website has
> been built to be able to get something as "primitive" as the list of all
> Octave packages...

Well, if you consider the history of the project it makes sense how it evolved
that way. It use to be a single monolithic package, all packages released at the
same time and it was built at the same time. You can still see how it worked by
digging on the svn repository.


On 13 August 2014 12:59, Julien Bect <address@hidden> wrote:
> Le 13/08/2014 13:37, c. a écrit :
>
>> With the current setup, the process to make a package release is very
>> simple,
>> the package maintainer produces the package tarball and html docs and the
>> site
>> maintainer uploads the docs to the website.
>
>
> Why ask the package maintainer to produce the html doc himself ? Because
> some packages do not rely on generate_html to do this ?

Because installing the package is not always straightforward (see comments
above).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]