[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging Octave and Octave-Forge?
From: |
soren |
Subject: |
Re: Merging Octave and Octave-Forge? |
Date: |
Tue, 26 Aug 2008 09:01:42 +0200 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.2-RC2) |
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
Merging Octave and Octave-Forge?, John W. Eaton, 2008/08/26