Re: Merging Octave and Octave-Forge?

[soren]

Hi,

Quoting Thomas Weber <address@hidden>:
> Am Montag, den 25.08.2008, 11:27 +0200 schrieb address@hidden:
> >    * The Octave-Forge web site is fairly nice, while the Octave web site
> >      doesn't provide much information. Personally, I use the  
> > function reference
> >      on the Octave-Forge website quite a bit, and I also find the  
> > doxygen stuff
> >      useful. I don't see why this stuff isn't on the Octave  
> > website. However,
> >      maintaining the Octave-Forge website is plenty of work, so I'm  
> > definitely
> >      not volunteering for the job of also maintaining octave.org. So why not
> >      merge the websites into one?
>
> Who has access to the current Octave/Octave-Forge websites? If we merge
> them, there must be some way for the people to access the system.

Access, as in who can change the files? I think it's only David and me  
who can change the Octave-Forge website, although I'm really not sure.  
Perhaps Michael and Thomas Treichl are also able to change the site.  
As to octave.org, I think John is the only one with write access. But  
I think he would be willing to let somebody else maintain it.

> 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.

> >    * 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.

> >    * One reason for the Octave/Octave-Forge split is that the Octave mailing
> >      lists shouldn't be spammed with mails from people who have  
> > problems with
> >      the Octave-Forge functions. These people should use the
> > Octave-Forge mailing
> >      lists. However, this isn't really happening at the moment.  
> > Everybody just
> >      seems to use the 'help' octave mailing list.
>
> People ask for help at what they think is appropriate. Often, it's not
> clear whether a bug is in Octave or a package.
> That's actually a compliment, the packages integrate seamlessly into the
> system.

Yeah, I think it's a good thing that people don't really know the  
difference between Octave and Octave-Forge. I'm just asking: if the  
users don't seem to get the difference, why should we have it?

> >    * The Octave-Forge infrastructure (SVN, release management, servers and
> >      bandwidth, ...) are very nice to have available. But honestly, this
> >      infrastructure just isn't very good. Their servers are slow, and the
> >      release process is very painful.
>
> Hmm, well, the release process is painful because you abuse SF's system,
> sorry. From SF's point of view, every octave package should probably be
> its own project, with the individual package maintainer as project
> admin.

Yes, very true. But if we want separate packages, then I see no alternative.

> > Anyway, this mail is getting long (sorry 'bout that) so I'll stop now.
> > But I'd like to ask: why are Octave and Octave-Forge two separate
> > projects? Why don't we simply have http://packages.octave.org as a
> > place for downloading add-on packages?
>
> Hmm, what problems will that address?
>         + octave.org will be a one-stop address for Octave, agreed.
>           That's good as it raises awareness for Octave.

Yes, and this is actually my main concern: make it easier for new  
users to get the code.

>         - The release process wouldn't change, would it?

Not much. If we were able to host packages on octave.org, then we  
wouldn't have to go through the pain of uploading packages on  
sourceforge. But agreed, the change would be mostly cosmetic.

> 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.

Søren