m-code

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

m-code

doolin

[ snip snap ]

>The point is let's gets started.  The first improvement is easy because
>something is better than nothing.  Let's get some first drafts of code up and
>tinker.

It is my understanding that there is a mailing list for octave source.
What about m files?  I have a small but growing subdirectory of code
for spatial statistics (geostatistics, i.e. kriging) that would make a
welcome (to me) addition to octave stats capabilities.  

Is there someplace I should be submitting this too?

Dave Doolin

[hidden email]

>Heber


Reply | Threaded
Open this post in threaded view
|

Re: m-code

heberf-2
There is such a list but it hasn't been very active.

This brings up a very interesting and important point.  JWE has done the lion's
share of the work on octave and contributions of m-files has been poor.  If we
are going to make this work we ought to have something like a CVS tree where we
could submit functions.  Perhaps we should designate people to be in charge of
toolboxes and they would have write access to a branch of the tree.  Everyone
else should submit new functions and changes to these people who would check
them before including them.

Does that sound good.

Heber

> It is my understanding that there is a mailing list for octave source.
> What about m files?  I have a small but growing subdirectory of code
> for spatial statistics (geostatistics, i.e. kriging) that would make a
> welcome (to me) addition to octave stats capabilities.  
>
> Is there someplace I should be submitting this too?
>
> Dave Doolin
>
> [hidden email]
>



Reply | Threaded
Open this post in threaded view
|

Re: m-code

heberf-2
In reply to this post by doolin
Whoops.  What I meant to say was that the octave-sources list is for m-files as well.

But as I said this list has not been very active and we either need to spice it
up or get a CVS tree.

Heber


Reply | Threaded
Open this post in threaded view
|

Re: m-code

doolin
In reply to this post by doolin

Good.  I will definitely submit m-files to this
list.

I agree that there is a need to lighten jwe's load
w.r.t. to development.  Having a cvs tree would be
very helpful.

I propose the following:

1. Planning for eventual implementation of
anonymous cvs with write access to trusted
maintainers for octave source code development.
This should help a gui project develop
momentum.

2. Concurrent with source archive could be a
centralized repository of m-files, with a
coherent and descriptive file structure
(e.g. statistics/spatial, etc.) with code
that has not been vetted for release with octave,
but should be after being appropriately debugged.


Basically, I want someplace I can contribute code.
I can't run a repository, but I can and will
write code.  

For what its worth, I have done some gui coding
in win32 and in java.  I am just *itchin'* for
an excuse to learn GTK...

Regards from the left coast.

Dave Doolin





Reply | Threaded
Open this post in threaded view
|

speeding up Octave development (was: Re: m-code)

John W. Eaton-6
On  4-Mar-1999, [hidden email] <[hidden email]> wrote:

| I agree that there is a need to lighten jwe's load
| w.r.t. to development.  Having a cvs tree would be
| very helpful.

An anonymous CVS archive could be the catalyst that ignites an
explosion in the number of contributions, but I'm not holding my
breath.  Don't get me wrong -- I'm willing to try it out, and I agree
that anonymous access to the latest sources via CVS might help some
people, but I think there are several other things that can speed
development even more.

One thing that would help a lot would be a relatively small amount
of funding to make more of my time available for working on Octave
instead of other projects.  When I'm busy doing other things (which is
necessary from time to time in order for me to keep my job) progress
on Octave seems to stop.  Without some funding to free up more of my
time for Octave, I don't think this will change any time soon.  The
reason is that no one else has been doing enough work with the core of
Octave to really be able to take over maintaining it.

Another thing that would increase the speed of development is
*quality* contributions of *actual code* from many different people.
This includes bug reports with patches, not just an expectation that I
will fix the problem once it is reported.  Also, it is not enough to
submit long wish lists or partially and poorly implemented code.  It
takes too much time to clean things up to include them.

Eric Raymond has received a lot of attention for saying that the
`bazaar' method of free software development can make a project move
much faster.  He makes some compelling arguments, but he based his
conclusions on a relatively small sample of projects, and most of them
are projects that competent hackers think are cool.  Now I see people
claiming that progress on any project will be faster if it switches to
bazaar mode.  I just don't think it's true.

I think Octave's development is rather open, but progress has also
been relatively slow at times.  I certainly don't think we are in
`cathedral' mode.  There aren't any big secrets here.  Test releases
and snapshots of the development sources are publicly available (they
are not made automatically at random points in time because I don't
think that is really useful for most people, even other developers).
If you want to be on the octave-maintainers list, you can subscribe.
There are currently only 16 people subscribed and the traffic on that
list is nearly zero.

My experience has been that, for whatever reason, hackers seem to be
excited by C compilers, kernels, networking code, gui toolkits,
editors, and even some general purpose languages like Perl.  But they
don't seem to be too excited by spreadsheets or programs for matrix
algebra.  At the same time, I've seen lots of physicists and
mathematicians take an interest in Octave, but most of them are
interested in using it to solve some problem, not in extending it.  If
they do write new functions, it seems that they view their code as
something that not many people would be interested in, or that is not
polished enough for distribution (they are probably often right about
that :-), so they don't contribute their code.

I could go on, but I'll just point out an essay on this topic that
expresses ideas that are fairly close to what I've been thinking for a
while now:

  http://www.its.caltech.edu/~jafl/misc/bazaar_fizzle_fail.html

It was mentioned on this list a few weeks ago by Stefano Ghirlanda
<[hidden email]> (thanks!).  It's definitely worth reading if you
are at all interested in what can make some software projects take off
(Linux, Perl, the Gimp) and why others don't seem to go nearly as
fast.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development

John Logsdon-4


On Fri, 5 Mar 1999, John W. Eaton wrote:

> On  4-Mar-1999, [hidden email] <[hidden email]> wrote:
>
> | I agree that there is a need to lighten jwe's load
> | w.r.t. to development.  Having a cvs tree would be
> | very helpful.
>

[snip]

>
> My experience has been that, for whatever reason, hackers seem to be
> excited by C compilers, kernels, networking code, gui toolkits,
> editors, and even some general purpose languages like Perl.  But they
> don't seem to be too excited by spreadsheets or programs for matrix
> algebra.  At the same time, I've seen lots of physicists and
> mathematicians take an interest in Octave, but most of them are
> interested in using it to solve some problem, not in extending it.  If
> they do write new functions, it seems that they view their code as
> something that not many people would be interested in, or that is not
> polished enough for distribution (they are probably often right about
> that :-), so they don't contribute their code.
>

You (plural) might like to look at the way the statistical programming
language R is organised.  Apologies to those Octavists who also use R but
R is a GPL implementation of the new S language, from which S+ is also
developed.  In some ways, S+ has the advantage because it has a degree of
inertia built up but there are some features of R that are better.

The point is that up to about 2 years ago, R development was essentially
by Ross Ihaka and Robert Gentleman but then an R Core team was formed
comrpising about 12 luminaries who looked at different parts of the code
and implementation on different platforms.  Occasional other submissions
are made but the expertise level for really effective (guts-of-) R
programming is quite high.  There is improving HTML-based help
documentation and a number of libraries of useful functions.  These are
all stored at CRAN (Compresesd R Archive) which is mirrored at Statlib and
elsewhere.

Thus what appears to be a bazaar type development can actually be
formalised without descending to the cathedral model.

This may have occurred with R because statistical issues are more focussed
and academics tend to meet or at least know each other.  Matrices are such
a general tool with applications in almost all areas that this is less
likely to occur.  However, where there is a will, there is a way.

> I could go on, but I'll just point out an essay on this topic that
> expresses ideas that are fairly close to what I've been thinking for a
> while now:
>
>   http://www.its.caltech.edu/~jafl/misc/bazaar_fizzle_fail.html
>
> It was mentioned on this list a few weeks ago by Stefano Ghirlanda
> <[hidden email]> (thanks!).  It's definitely worth reading if you
> are at all interested in what can make some software projects take off
> (Linux, Perl, the Gimp) and why others don't seem to go nearly as
> fast.
>
> jwe
>

I behoves us all (and I am a fairly occasional user of Octave) to minimise
the load on JWE firstly by not having recourse to the list for some of the
smallest problems (gnuplot symbols seem to be irksome and come around
frequently).  Perhaps JWE should contain himself to the development list
and leave the answers to gnuplot problems to someone else, for example?  I
know that may prove difficult!
 
An Octave core group could enable the development, list and documentation
without putting such a load on one person.  On the point of finance, I was
once flamed (well quite gently and by only one person, so perhaps sparked
it a better description) for suggesting that the FSF should become a
formal avenue for channeling funds into projects.  Perhaps the Octave core
team could set up a Visa account (the easiest way for transmitting cash
internationally) and advertise this for support/development while
remaining strictly within the GPL.  Noting the email addresses of a number
of contributors as being major commercial engineering outfits, perhaps
these companies - plus the myriad of smaller technical businesses to whom
a Matlab licence is out of the window - could drop money into it from time
to time.  It is in the interests of all of us to keep Octave going and
none of us I expect will want to contribute to the marketing and other
junkets on which commercial software vendors spend the majority of their
income.

Just some thoughts.

John



Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

Jonathan King-2
In reply to this post by John W. Eaton-6


On Fri, 5 Mar 1999, John W. Eaton wrote:

> On  4-Mar-1999, [hidden email]
> <[hidden email]> wrote:
>
> | I agree that there is a need to lighten jwe's load
> | w.r.t. to development.  Having a cvs tree would be
> | very helpful.
>
> An anonymous CVS archive could be the catalyst that ignites an
> explosion in the number of contributions, but I'm not holding my
> breath.  Don't get me wrong -- I'm willing to try it out, and I agree
> that anonymous access to the latest sources via CVS might help some
> people, but I think there are several other things that can speed
> development even more.
>
> One thing that would help a lot would be a relatively small amount
> of funding to make more of my time available for working on Octave
> instead of other projects.  

I think everybody on this list should read that last sentence v e r y
s l o w l y.  I've been trying to nail down some funding for Octave
development this week, and I think I can score some.  But an even faster
way to get some money raised would be for people just to send some in.

I'll put it this way:

If I had an address in hand right now that I could send money to to
support Octave development, I'd reach into my pocket and do it.  I mean,
I've shelled out $40-something for Red Hat in January, and I sent $36 to
the Perl Journal at the end of February.  I don't have infinite petty cash
in my budget, but March is looking good enough that I can help feed my
Octave habit.  $50 is a nice round figure; where should I send it?

I know that's not a lot, but I can probably do it again reasonably soon,
and if everybody on the list (who isn't a starving grad student) did it,
I expect the total amount would be meaningful.

One other point:

> My experience has been that, for whatever reason, hackers seem to be
> excited by C compilers, kernels, networking code, gui toolkits,
> editors, and even some general purpose languages like Perl.  But they
> don't seem to be too excited by spreadsheets or programs for matrix
> algebra.  

It struck me recently that Octave doesn't get *nearly* the press it
deserves in the free software world.  At the Linux World Expo last
week, Slashdot reported that the "show favorite" in the category of
Science and Engineering was...

VA Research

Whee!  Withouth knowing more, I'd guess this was because they had a
Beowulf cluster up or something.  I don't know if the FSF people at
the show even had Octave running in their booth or not.  In my experience,
lots of people who *should* know that Octave exists in fact do not.  It's
a serious program.

But what might be a cheap and easy way to get more publicity for Octave
(and maybe even attract some more hacker interest) would be to write
an article about the frustrations of developing Octave up on the Octave
web site and get Slashdot to point to it and set up a discussion.

[munch]

> I could go on, but I'll just point out an essay on this topic that
> expresses ideas that are fairly close to what I've been thinking for a
> while now:
>
>   http://www.its.caltech.edu/~jafl/misc/bazaar_fizzle_fail.html

I'll have to take a look.  In the case of Octave, I'm afraid part of the
problem is that people don't even know it's out there.

jking


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

Daniel Heiserer
Hi,

>
> If I had an address in hand right now that I could send money to to
> support Octave development, I'd reach into my pocket and do it.  I mean,
> I've shelled out $40-something for Red Hat in January, and I sent $36 to
> the Perl Journal at the end of February.  I don't have infinite petty cash
> in my budget, but March is looking good enough that I can help feed my
> Octave habit.  $50 is a nice round figure; where should I send it?
>
> I know that's not a lot, but I can probably do it again reasonably soon,
> and if everybody on the list (who isn't a starving grad student) did it,
> I expect the total amount would be meaningful.

I would pay the same, but I don't know if we can finance some experts
by collecting money?
How many people are in the list.
n*$50=???

???/n=

> It struck me recently that Octave doesn't get *nearly* the press it
> deserves in the free software world.  At the Linux World Expo last
> week, Slashdot reported that the "show favorite" in the category of
> Science and Engineering was...
>
> VA Research

what is that?

>
> Whee!  Withouth knowing more, I'd guess this was because they had a
> Beowulf cluster up or something.  I don't know if the FSF people at
> the show even had Octave running in their booth or not.  In my experience,
> lots of people who *should* know that Octave exists in fact do not.  It's
> a serious program.

There are many intersting features Octave could step into, but currently
there
are some key things missing to attract enough human resource to be THE
scientifc platform:
o gui
o OGL plotting+viewing
o sparse matrices for FEM and other things
....
well that is what I miss.


bye daniel


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

heberf-2
In reply to this post by John W. Eaton-6
Several good points are being brought up here.  The example of R is particularly
interesting.  The main thing to notice is that Octave has several parts:

        1. Octave interpretter
        2. Functions (statistical, signal processing, ODE solvers, etc)
       
So far most work in both areas has been done by JWE (with several notable
exeptions like the work of Kurt Hornik and others).  Octave is approaching the
point where that is no longer feasible.  I recommend that we select people to
head up groups of function classes.  Please note that these people will not have
to be "hackers", just people who are competent in that field. By the way I think
these people ought to be in charge of the info pages for their toolbox as well
(thus addressing Thomas Hoffmann's question).  We should probably think about
several mailing lists or bug lists as well.  John has to answer some questions
that he really shouldn't have to bother with.

John's point about the need for hackers and the fact that we are unlikely to
attract such people to help develop the code is probably correct but I think it
applies to 1 rather than 2.  My C++ is pretty poor but I could tell an m-file or
.oct file that does time series statistics well from one that does it poorly.  
Similarly for those of you in other fields.  So let's not put all the Octave
sources in a CVS tree.  Just the functions (and documentation?).

As far as the interpretter goes it will still probably be mostly JWE so we need
to listen to what he says about funding.  The interpretter is the heart of it
after all.

Here is a question for JWE.  Many of us have some amout of control over how
research money is spent in our department or company.   But before we can write
a check we need something to tell the account payable people.  How do you
recommend we do that?  Could we call it support or consulting or something?  My
university is good about giving me research money but I need a purchase order or
something like that.  I recall reading that the guys working on GNOME get money
by supporting gnumeric or other things.  If you had a bill you could send me for
support I could send $X your way.


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

doolin
In reply to this post by John W. Eaton-6

If a repository is set up to handle .m files, it
probably would not be any more work to handle the
entire source.  Which would probably have to be done
at a later date anyway.

It really seems that the major impediment is
structural.  I think that coders will appear
if the mechanism to organize their contributions
is in place.  This is of course harder and
more time consuming than writing code.

Back to the salt mine...

Dave D


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

Andy Adler-5
In reply to this post by heberf-2
On Fri, 5 Mar 1999, heberf wrote:
> Here is a question for JWE.  Many of us have some amout of control over how
> research money is spent in our department or company.   But before we can write
> a check we need something to tell the account payable people.  How do you
> recommend we do that?    [text snipped]
> If you had a bill you could send me for
> support I could send $X your way.

This is a very good suggestion. At my company we use free software much
more than stuff we often shell out $1000 for. Octave is high on the list
of most used software (after linux, and vim). I could easily sign a PO
for $500-$1000 for software or support (more than that and I'd have to go
through more effort)

jwe has promptly fixed bugs and answered questions that have sped up my
work on numerous occasions, so I'd be more than ready to sign a PO.

andy
_____________________________________________________________________
Andy Adler      | American Biometric Company  | Tel:(613)736-5100x154
[hidden email] | 3429 Hawthorne Rd,Ottawa,ON | Fax:(613)736-1348


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

John W. Eaton-6
In reply to this post by Daniel Heiserer
On  5-Mar-1999, Daniel Heiserer <[hidden email]> wrote:

| > I know that's not a lot, but I can probably do it again reasonably soon,
| > and if everybody on the list (who isn't a starving grad student) did it,
| > I expect the total amount would be meaningful.
|
| I would pay the same, but I don't know if we can finance some experts
| by collecting money?
| How many people are in the list.
| n*$50=???
|
| ???/n=

There are currently about 350 addresses on the list.  A few of them
are mail exploders, but most are individuals.

I appreciate the offers of personal donations, but I too wonder
whether that would be sufficient or sustainable.

How much does your organization pay for software every year?  Would it
be possible to allocate some small percentage of that to Octave
development so that you could fund a small proposal?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

John W. Eaton-6
In reply to this post by Jonathan King-2
On  5-Mar-1999, Jonathan King <[hidden email]> wrote:

| It struck me recently that Octave doesn't get *nearly* the press it
| deserves in the free software world.  At the Linux World Expo last
| week, Slashdot reported that the "show favorite" in the category of
| Science and Engineering was...

As I mentioned in an earlier message, the help-octave mailing list now
has about 350 subscribers.  Would anyone like to sponsor a call for
votes on forming a new Usenet newsgroup for Octave?  That might make
Octave a bit more visible.

As for the group name, I suppose comp.soft-sys.math.octave would be
appropriate since scilab and mathematica are in the same category (I
don't know how the MathWorks got away with comp.soft-sys.matlab
instead of math.matlab).  In any case, we could probably set it up so
that messages sent to the help-octave mailing list are sent to the
usenet group.  I don't know about the reverse direction though.

Is anyone interested in pursuing this?  I don't have time to do it
myself.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development

John W. Eaton-6
In reply to this post by John Logsdon-4
On  5-Mar-1999, John Logsdon <[hidden email]> wrote:

| I behoves us all (and I am a fairly occasional user of Octave) to minimise
| the load on JWE firstly by not having recourse to the list for some of the
| smallest problems (gnuplot symbols seem to be irksome and come around
| frequently).  Perhaps JWE should contain himself to the development list
| and leave the answers to gnuplot problems to someone else, for example?  I
| know that may prove difficult!

I would be glad to not feel like I have to answer questions about
gnuplot on the help-octave list.  But for that to happen, I have to
see that someone is answering these questions publicly.  If people
just send responses to the person who asked the question, and that
person never sends a summary to the list, then I generally assume that
the question went unanswered.  And the answer doesn't show up in the
archives, so people who might want to search for an answer before
asking the list can't find anything.  So the same questions are asked
again and again.  That's why I generally try to answer things that
haven't been answered on the list, and to CC my replies to the list.
If more people started answering the easy questions publicly, I would
probably decide that I no longer needed to.

This also brings up the question of maintaining the FAQ.  I think
there's a lot of information in the mailing list archives that could
go in the FAQ, but I simply don't have time to extract it and format
it.  Would someone like to volunteer to work on that project?

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development

heberf-2
In reply to this post by John Logsdon-4
FAQ's are nice but what we don't want is to end up with the FAQ growing and the
info pages staying the same.  That way we can avoid future e-mail questions
asking the same question.

Actually if we end up assigning some toolbox maintainers then they ought to
maintain the info pages.

Heber

> On  5-Mar-1999, John Logsdon <[hidden email]> wrote:
>
> | I behoves us all (and I am a fairly occasional user of Octave) to minimise
> | the load on JWE firstly by not having recourse to the list for some of the
> | smallest problems (gnuplot symbols seem to be irksome and come around
> | frequently).  Perhaps JWE should contain himself to the development list
> | and leave the answers to gnuplot problems to someone else, for example?  I
> | know that may prove difficult!
>
> I would be glad to not feel like I have to answer questions about
> gnuplot on the help-octave list.  But for that to happen, I have to
> see that someone is answering these questions publicly.  If people
> just send responses to the person who asked the question, and that
> person never sends a summary to the list, then I generally assume that
> the question went unanswered.  And the answer doesn't show up in the
> archives, so people who might want to search for an answer before
> asking the list can't find anything.  So the same questions are asked
> again and again.  That's why I generally try to answer things that
> haven't been answered on the list, and to CC my replies to the list.
> If more people started answering the easy questions publicly, I would
> probably decide that I no longer needed to.
>
> This also brings up the question of maintaining the FAQ.  I think
> there's a lot of information in the mailing list archives that could
> go in the FAQ, but I simply don't have time to extract it and format
> it.  Would someone like to volunteer to work on that project?
>
> Thanks,
>
> jwe
>


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development

lash-5
In reply to this post by John W. Eaton-6
> I would be glad to not feel like I have to answer questions about
> gnuplot on the help-octave list.  But for that to happen, I have to
> see that someone is answering these questions publicly.  If people
> just send responses to the person who asked the question, and that
> person never sends a summary to the list, then I generally assume that
> the question went unanswered.  And the answer doesn't show up in the
> archives, so people who might want to search for an answer before
> asking the list can't find anything.  So the same questions are asked
> again and again.  That's why I generally try to answer things that
> haven't been answered on the list, and to CC my replies to the list.
> If more people started answering the easy questions publicly, I would
> probably decide that I no longer needed to.

John,

I usually try to reply to the list and the person if I can answer
someone's question, but one thing that sometimes gets in the way is
that by default replies will go to the person, since the From: line
is the person that sent the mail, and there is no Reply-To: line.
Some of the other mailing lists that I am on set the Reply-To: line
to the list address.  

I don't know if others feel the same way, but I have been bitten
by this a few times.

Bill


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

lash-5
In reply to this post by doolin
>
> It really seems that the major impediment is
> structural.  I think that coders will appear
> if the mechanism to organize their contributions
> is in place.  This is of course harder and
> more time consuming than writing code.
>

I am not sure that I agree that the problem is
structural.  I don't think John has been ignoring
any code that has been contributed to him.  I don't
think it can get much easier than:

        1. Develop wonderful, well documented functions
           for Octave.

        2. Create a diff file.

        3. Send it to John, and let him integrate it.

Having a CVS repository, or something similar only changes
step 2 a little bit.  Maybe I'm mistaken.


Bill


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development

John W. Eaton-6
In reply to this post by lash-5
On  5-Mar-1999, [hidden email] <[hidden email]> wrote:

| I usually try to reply to the list and the person if I can answer
| someone's question, but one thing that sometimes gets in the way is
| that by default replies will go to the person, since the From: line
| is the person that sent the mail, and there is no Reply-To: line.
| Some of the other mailing lists that I am on set the Reply-To: line
| to the list address.  
|
| I don't know if others feel the same way, but I have been bitten
| by this a few times.

I'd rather not add a Reply-To: header because I have seen embarrassing
things happen when people thought they were just replying to the
sender but they were actually replying to the list.  I'd rather avoid
that.  Doesn't your mail reader have a `follow-up' feature as well as
`reply'?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development (was: Re: m-code)

John W. Eaton-6
In reply to this post by lash-5
On  5-Mar-1999, [hidden email] <[hidden email]> wrote:

| I am not sure that I agree that the problem is
| structural.  I don't think John has been ignoring
| any code that has been contributed to him.  I don't
| think it can get much easier than:
|
| 1. Develop wonderful, well documented functions
|   for Octave.
|
| 2. Create a diff file.
|
| 3. Send it to John, and let him integrate it.
|
| Having a CVS repository, or something similar only changes
| step 2 a little bit.  Maybe I'm mistaken.

I think people have the idea that anonymous CVS access will provide
them with up-to-the-minute sources, and that it's a good thing for
everyone to be able to have that kind of access.  I'm not convinced,
though I might be willing to try it.

The reason that I'm not convinced is that a year or so ago, after Eric
Raymond made his paper available, people starting thinking that it was
important to have very frequent releases.  I decided to try that, so I
added the bleeding-edge directory on the ftp site.  Since then,
releases of the development sources haven't always been as often as I
had originally planned, mostly because the sources were not changing
all that fast and I thought it wasn't important to be putting up new
snapshots if they didn't have much new code in them.

Also, after creating the bleeding-edge releases, I didn't notice a
tremendous increase in the number of useful patches being submitted.
Instead, I started seeing a somewhat larger number of messages saying
`I tried your snapshot and it didn't work.  Tell me how to fix it.'
when what I was really hoping for were more messages that said `I
tried your snapshot and it didn't work.  Here is a fix for the
problem.  Can you please include it in the next snapshot?'

So, will anonymous CVS access mean more clueful developers or more
people who complain that they can't compile it because the sources are
temporarily in an inconsistent state?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: speeding up Octave development

John W. Eaton-6
In reply to this post by John Logsdon-4
On  5-Mar-1999, John Logsdon <[hidden email]> wrote:

| The point is that up to about 2 years ago, R development was essentially
| by Ross Ihaka and Robert Gentleman but then an R Core team was formed
| comrpising about 12 luminaries who looked at different parts of the code
| and implementation on different platforms.

That sounds fine to me.  Now where are those 12 or so people who could
form the team of developers for Octave?

Thanks,

jwe


12