[Top][All Lists]

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

Re: Octave-Forge website / docs.html

From: Julien Bect
Subject: Re: Octave-Forge website / docs.html
Date: Wed, 13 Aug 2014 13:59:42 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0

Le 13/08/2014 13:37, c. a écrit :
On 13 Aug 2014, at 13:23, Julien Bect <address@hidden> wrote:

Le 13/08/2014 12:46, c. a écrit :
the list used internally by pkg.m is here:


be aware that this is not a static text file it is generated
by a server-side script by iterating over all directories containing
html docs.
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...

Especially since I'm looking for a way to _build_ the website... If the website 
is lost, then I cannot get the package list... so how I can I rebuild the 
website ?

It would make more sense to me to have a STATIC list of packages somewhere 
(perhaps on a Mercurial repo on SF, together with all the other admin scripts 
that are used to build the website ?) that could be used to build the website, 
and also uploaded as octave.sourceforge.net/list_packages.txt (for instance) 
for use from pkg.

Does that make sense to you ?
No, it doesn't.

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 ?


Whatever change you plan, I strongly recommend that you please follow this 
anything else has proven to be unpractical with the EXTREMELY low workforce we
can dedicate to site maintaince.

I understand your point. It is very important that the maintenance burdens should remain as low as possible.

It seems to me, however, that having a static list of package *names* adds very little to the current maintenance routine.

In fact, the only difference, I believe, is that when a *new package* is added (not a new release of an existing package), the static list must be updated.

Another option would be to have a list of *unmaintained* packages. In this case, we could obtain the list of packages by parsing


and then removing unmaintained packages from the list.

Does any of this makes sense to you ? Or does it still look too heavy ?

reply via email to

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