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: Mon, 25 Aug 2008 12:06:44 +0200

Am Montag, den 25.08.2008, 11:27 +0200 schrieb address@hidden:
> Hi,
>    As I've recently announced a new release of Octave-Forge has just  
> been made. Whenever I make these releases the same thought pops up in  
> my head: "why does Octave-Forge even exist?". (This line of thinking  
> is probably related to the fact the making the release is a painful  
> experience... :-) )
>    Here are some of my thoughts/observations about the  
> Octave/Octave-Forge relationship:
> 
>    * 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. 

Maybe moving the whole site to a wiki (either directly or via a wiki
compiler like ikiwiki) is a possibility?



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


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


>    * I think new users are confused by the split between Octave and  
> Octave-Forge.
>      I don't think we present the boundaries between the two projects very 
> well
>      to new users. I'm guessing this is simply because nobody really  
> knows these
>      boundaries...
> 
>    * 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.

There are some related problems (like autoconf, where you can't simply
use the current state of the repository and release that -- instead, you
have to generate configure scripts and package the resulting directory).


> 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.
        
        - The release process wouldn't change, would it? 

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.

        Thomas



reply via email to

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