octave-maintainers
[Top][All Lists]
Advanced

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

Re: Merging Octave and Octave-Forge?


From: Thomas Weber
Subject: Re: Merging Octave and Octave-Forge?
Date: Tue, 26 Aug 2008 16:31:54 +0200

Am Dienstag, den 26.08.2008, 15:53 +0200 schrieb address@hidden:
> Quoting Thomas Weber <address@hidden>:
> > Am Dienstag, den 26.08.2008, 09:01 +0200 schrieb address@hidden:
> >> The problem with a wiki is that we have lots of auto-generated
> >> contents such as the function reference, the doxygen stuff, the manual
> >> (on octave.org), and similar. I'm not sure how well that would fit
> >> into a wiki.
> >
> > Simply let that stuff outside of the wiki and link to it. If it's
> > autogenerated, there's no need for people to touch it.
> 
> Sure, we can do that, but then I don't get the point of having a wiki.
> 
> My main points with the web site is simply:
>    * I think it's confusing that we have two web sites.
>    * It's more work to maintain two web sites than one.
> 
> If the two web sites were merged by creating a wiki, then fine by me.  
> I'm just advocating a merge, not a specific technical solution  
> (although it is highly relevant to figure the technical stuff out).

The reason for a wiki (or any other solution that doesn't require
directo access to the octave.org servers): I don't want to put more load
onto John and the other developers. 

I'm not sure a wiki is the best solution either, but it seems to work
for other projects.


> >> I think we have access to the GNU mirrors.
> >
> > Oh, I see that GNU hosts windows binaries. I didn't know that.
> 
> Okay, good point :-)  But we could easily host the binaries on  
> sourceforge and link directly to them from octave.org, couldn't we?

I think we misunderstand each other. GNU indeeds hosts windows binaries,
i. e. you can download Emacs executables for Win.


> > How do you update the documentation? I don't think you write it by hand,
> > do you? It's probably part of the Makefile.
> 
> Well, you update the documentation by changing the texinfo help text  
> in the specific function (either m-file or cc-file). 

Okay, that's part of the normal vcs check-in, nothing to worry about.

> Then we run a  
> script that extracts all the help texts and generates a whole bunch of  
> html pages. Fairly simple, but also quite time-consuming (it takes  
> about half an hour on my machine to generate the function reference).

cron-job, either 
- once daily if the web documentation should be up-to-date with current
  SVN head
or
- triggered by a new package upload by a PM.

> > It shouldn't be a problem to trigger an update when a new package is
> > uploaded.
> 
> In principle no, but it requires some server-side functionality, that  
> might be hard to get (you need a fairly large build setup to create  
> the web pages).

How big is that? SF restricts you to 100 MB (without SVN), is that
correct? Or do you mean the build setup for creating the HTML pages? 

        Thomas



reply via email to

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