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

Re: [Pkg-octave-devel] octave2.9 in sid




On Nov 24, 2005, at 7:24 PM, folajimi wrote:

On Wed, 23 Nov 2005, Colin Ingram wrote:

Rafael Laboissiere wrote:

* folajimi <folajimi@speakeasy.net> [2005-11-23 09:39]:



Colin seems to think that Rafael has taken care of the issue, but
Rafael thinks that the project has stalled...



If Colin is not taking care of the project and if he thinks I am doing
it, then I can certify that the project is stalled.

So, feel free to take the plunge. For now, we need a good design, before
we start the implementation.


my bad...I was thinking about the glpk thing.  I've been off the deep
end lately trying to make this trip happen. It looks to me that "number 1" of the original plan[1] has been taking care of[2]. We still need to prepare the remain packages that have octave2.1 as a dependence for the
"smooth" switch i.e. octave-forge.  I haven't been able to think about
this much  except for checking out what exactly it takes to build
octave-forge against the two different octave versions.  I agree that
three packages are needed here (octave2.9-forge, octave2.1-forge, and
octave-forge-common for example)  but I haven't began looking at the
exacts of this and I won't until I return to Madison next week so feel
free (folajimi) to jump right in. I think this will be a big a project
that is likely to break the repository how do you all feel about
branching /package/octave-forge for this transition?

Uh... I haven't the SLIGHTEST idea how to proceed. I would probably have to
read up on how to address this issue.

I'm swamped and haven't been doing a proper job on octave-forge
maintenance (for several years now ;-)  If anybody needs access
to the upstream repository to do this right let me know.

octave-forge needs to branch 2.1.x and 2.9.x streams, and purge a
number of routines which shadow octave routines.  In particular,
sparse needs to disappear from the 2.9.x trunk.

- Paul




Reply to: