Re: Merging Octave and Octave-Forge?

[Thomas Weber]

Am Dienstag, den 26.08.2008, 09:01 +0200 schrieb address@hidden:
> Hi,
> 
> Quoting Thomas Weber <address@hidden>:
> > Maybe moving the whole site to a wiki (either directly or via a wiki
> > compiler like ikiwiki) is a possibility?
> 
> 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.

> 
> >>    * The Windows binary at Octave-Forge currently is the de-facto way
> >> of getting
> >>      Octave on Windows. I really think this binary is a great feature, and 
> >> I
> >>      honestly think it should be hosted at octave.org, and be blessed as 
> >> the
> >>      semi-official way of getting Octave on Windows. I don't
> >> know/understand the
> >>      Mac situation, as it seems many people are also using Fink.
> >
> > How is octave.org's bandwidth? SF, as bad/slow as it may be, has several
> > mirrors available.
> 
> I think we have access to the GNU mirrors.

Oh, I see that GNU hosts windows binaries. I didn't know that. 


> > Now, about the release pain (shoot me if the following is stupid):
> > How about getting rid of the pain/release manager. I imagine the
> > following work-flow:
> >
> > An individual package's maintainer (call him/her PM for now) decides
> to
> > release the package in its current state. The PM tags the package in
> the
> > version control system and simply uploads the small tarball to a
> > directory on a server.
> >
> > A bundle release is created every X months by
> > 1) Sending a mail: 'hey guys, bundle release in 2 weeks, get your
> stuff
> > in shape'.
> > 2) Tarring and shipping the contents of the above directory after
> the 2
> > weeks.
> > 3) Tagging the release in version control.
> >
> > Advantages:
> > - The release manager doesn't have to touch a gazillion of files
> >   (read: every DESCRIPTION file)
> > - PMs can release a package when they have time/reason to do so.
> > - Packages that had no update during a bundle release cycle will
> stay at
> > the same version number and still be included in the bundle.
> >
> > Problem:
> > I don't know if the above workflow is possible within SF's
> framework.
> 
> This approach would be very nice. The problem is actually a silly
> one.  
> Say, if I make a change in the documentation of a function in a  
> package, and make a new release, then we want the function reference  
> online to be updated as well. Currently we have to build the entire  
> function reference to update one file, so that'll be some work for  
> each package maintainer. Also, if we have, say, 40 maintainers, we  
> would need 40 people with write access to the website. I do a poor  
> enough job maintaining the octave-forge website, but imagine 40
> people  
> like me -- that's just bound to go wrong. But I agree: each package  
> maintainer really should be the one handling the release if his/her  
> package.

How do you update the documentation? I don't think you write it by hand,
do you? It's probably part of the Makefile.

It shouldn't be a problem to trigger an update when a new package is
uploaded.