Re: Octave-Forge website / docs.html

[Julien Bect]

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:
> > >
> > > http://octave.sourceforge.net/list_packages.php
> > >
> > > 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 
> approach
> 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

http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases

and then removing unmaintained packages from the list.

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