'Otherwise we are just stuck with a code we do not understand'

[Jakob Kroeker]

'Otherwise we are just stuck with a code we do not understand'

This is a citation from Nathan,
https://groups.google.com/d/msg/sage-devel/WXNmH3PL7kY/rFQlnvv9wkYJ

Question:
are the sage development policies not sufficient to ensure project maintainability,
or is Nathan's statement just caused by his frustration and is not objective?

Jakob

Remark: I do not have enough credit yet in the sage community to start a discussion like this,
so feel free to ignore it for now.

[rjf]

This seems to have come from some squabble on sage-devel.

I doubt that any "policy"  can ensure project maintainability unless

perhaps the policy comes with a large among of funding to pay people

to spend time on maintenance.  (Meaning fixing bugs, adding features

that are requested, making new releases for new versions of

operating systems and other packages.)

Nothing new here.

[Nathann Cohen]

are the sage development policies not sufficient to ensure project maintainability,
or is Nathan's statement just caused by his frustration and is not objective?

What is for sure is that we are stuck with a code that nobody is (willing AND able) to fix.

Nathann

[Bill Hart]

Sometimes rewriting code from scratch is the only way to ensure it remains maintainable.

Flint 2 is a complete rewrite of flint 1 from scratch (flint 1 had 120,000 lines of code).

At 250,000 lines of code, flint 2 is probably a little large to ever rewrite entirely from scratch. But I would not hesitate for a moment to rewrite an entire flint module from scratch if I could substantially improve it.

Be warned though. People will publicly complain you didn't maintain backwards compatibility and even after you rewrite it, they will still publicly complain about the old code as though it was still in use:

http://trac.sagemath.org/ticket/17090#comment:31 (see point 3 which refers to a bug found in flint1 in the FFT, which I personally completely rewrote from scratch without even referring to the old code).

Bill.

--
You received this message because you are subscribed to the Google Groups "sage-flame" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-flame+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-flame.
For more options, visit https://groups.google.com/d/optout.

[rjf]

What I find interesting about this thread is that it is also relevant to discussions

that open source is necessary for proofs, or correctness, or whatever.

If no one is willing or able to look at the code,  it is tantamount to being

unreadable.   and of course even closed-source code is in some sense

readable in principle because a computer reads and executes it.  And

I suppose it can usually be disassembled for closer-to-human consumption.

Anyway, if something is broken and no one can fix it, that's ok until someone

shows up and cares about it.  Then it is potentially up to that person to

fix it.

I thought that parts of Mathematica were broken and wouldn't ever be fixed,

and so I wrote MockMMA to try out my own ideas of alternatives.  That's

one way to go.  Other people fork code, and Bill rewrites his own stuff.

I've written some large number of programs to multiply polynomials.

Seems like a simple task, but there are lots of ways to do it; sometimes

you have to adapt to new kinds of computers -- e.g. multi-level caches.

parallel floating-point units.  GPUs.  whatever.

RJF

On Saturday, October 4, 2014 2:16:57 PM UTC-7, Bill Hart wrote:

Sometimes rewriting code from scratch is the only way to ensure it remains maintainable.

Flint 2 is a complete rewrite of flint 1 from scratch (flint 1 had 120,000 lines of code).

At 250,000 lines of code, flint 2 is probably a little large to ever rewrite entirely from scratch. But I would not hesitate for a moment to rewrite an entire flint module from scratch if I could substantially improve it.

Be warned though. People will publicly complain you didn't maintain backwards compatibility and even after you rewrite it, they will still publicly complain about the old code as though it was still in use:

http://trac.sagemath.org/ticket/17090#comment:31 (see point 3 which refers to a bug found in flint1 in the FFT, which I personally completely rewrote from scratch without even referring to the old code).

Bill.

On 4 October 2014 22:54, Nathann Cohen <nathan...@gmail.com> wrote:

are the sage development policies not sufficient to ensure project maintainability,
or is Nathan's statement just caused by his frustration and is not objective?

What is for sure is that we are stuck with a code that nobody is (willing AND able) to fix.

Nathann

--
You received this message because you are subscribed to the Google Groups "sage-flame" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-flame+unsubscribe@googlegroups.com.

[Jakob Kroeker]

I doubt that any "policy"  can ensure project maintainability unless

perhaps the policy comes with a large among of funding to pay people

to spend time on maintenance. 

@rjf

in my opinion it is not that simple here: as far as I know from the discussion,
some module routines return incorect results, so

1. it looks like  that the QA failed in this case

I looked at the source and at the first sight it seems that routines are documented and doctested.
But when trusting Nathann's comments, it is not enough to grasp the complete picture and understand
the interplay of the single routines (=> 100% doctest is not sufficient)

Summarizing the comments, there at least four options

- rewriting from scratch
- get the missing information from the previous authors
- do source code archaeology
- convince the initial authors to fix the problem

Jakob


 

[rjf]

It should be clear that the presence of documentation, doctest, and QA hardly guarantees correctness. 

In fact, I have seen cases in which correct programs properly documented were misunderstood,

the code replaced with other code with different specifications, now incorrect, but passing new

and also incorrect QA.

This is a potential downside of open source.  Like lying or misinformed Wikipedia contributors,

[Nathann Cohen]

> It should be clear that the presence of documentation, doctest, and QA hardly guarantees correctness.
>
> In fact, I have seen cases in which correct programs properly documented were misunderstood,
> the code replaced with other code with different specifications, now incorrect, but passing new
> and also incorrect QA.
>
> This is a potential downside of open source. Like lying or misinformed Wikipedia contributors,

I don't see a single reason why this would happen in open-source
software and not in proprietary software.

Nathann

[rjf]

Presumably it would not be so easy for random uninformed or malicious persons to

insert code into proprietary software. There are many people who could change Sage

(for example, anyone who can change Maxima can also change Sage)

 

[Nathann Cohen]

> Presumably it would not be so easy for random uninformed or malicious
> persons to
> insert code into proprietary software. There are many people who could
> change Sage
> (for example, anyone who can change Maxima can also change Sage)

I do not think that we seriously have to worry about "malicious users"
implementing wrong mathematical features on purpose.

So unless you have a reason to believe that contributors to an
open-source project misread the doc more frequently than others ?...
O_o

Nathann

[Nathann Cohen]

> I do not think that we seriously have to worry about "malicious users"
> implementing wrong mathematical features on purpose.

Well. Except from Mathematica developpers who may be afraid of who is
about to eat them of course :-D

Nathann

[rjf]

On Saturday, October 4, 2014 4:03:45 PM UTC-7, Nathann Cohen wrote:

> Presumably it would not be so easy for random uninformed or malicious
> persons to
> insert code into proprietary software. There are many people who could
> change Sage
> (for example, anyone who can change Maxima can also change Sage)

I do not think that we seriously have to worry about "malicious users"
implementing wrong mathematical features on purpose.

It is not likely but it is certainly possible.  Mathematicians can be

nasty.

Much more likely is that an ignorant person will make a change 

and another ignorant person will do some kind of QA. This is sometimes

even done automatically, and can be as innocent as changing a

compile-time flag.

some people might have in their code   y = (1.0+x)-1.0, and a

compiler will optimize this to  y= x.   

This is (in at least some languages)  wrong.

So unless you have a reason to believe that contributors to an
open-source project misread the doc more frequently than others ?...

Well yes, I do, esp. Sage. I understand that William welcoms contributors to Sage 

who are high school students just learning python,( because it is

so easy to learn)  and are pretty much uninformed, mathematically.

RJf

[William Stein]

Sadly, so far the high school contributors have not contributed
mathematically interesting code included in Sage; they contribute
non-mathematical code.
For example, in about 2009 Timothy Dumol, while a 16 year old high
school student in the Philippines, did an enormous amount of high
quality work on the Sage notebook UI. Other high school students
have made educational materials available that rely on Sage, but
aren't included with it...

-- William

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[rjf]

I suppose that the background needed to write UI code is more easily

accessible to a high school student than the background needed to reverse-engineer

a piece of Magma.

On the other hand, perhaps a better UI would come from a student who has,

for example, taken a UI course in college and has more experience in programming.

If you have one piece of code in Sage from one programmer from 2009, that

sounds like slim pickings.  Maybe it is a tribute to how careful you are in

including code, or a commentary on how duplicative, defective,  or otherwise useless most

Sage "contributions" from high schoolers really are??

(reminder; we are on sage flame :)   ...)

[Dima Pasechnik]

On 2014-10-04, rjf <fat...@gmail.com> wrote:
> What I find interesting about this thread is that it is also relevant to
> discussions
> that open source is necessary for proofs, or correctness, or whatever.

necessary, but not sufficient (cf. Shellshock aka Bashdoor)

> If no one is willing or able to look at the code, it is tantamount to being
> unreadable.

no, it's not. It is just lack of resources.

> and of course even closed-source code is in some sense
> readable in principle because a computer reads and executes it. And
> I suppose it can usually be disassembled for closer-to-human consumption.

Except that, depending on where you live, it might be illegal to disassemble,
or it might be legal to disassemble, but illegal to publish your findings...
What often happens when someone tries to publish results of disassembling Windows
internals, is well known.

>>> email to sage-flame+...@googlegroups.com.

[William Stein]

On Mon, Oct 6, 2014 at 7:03 AM, Dima Pasechnik <dim...@gmail.com> wrote:

On 2014-10-04, rjf <fat...@gmail.com> wrote:
> What I find interesting about this thread is that it is also relevant to
> discussions
> that open source is necessary for proofs, or correctness, or whatever.
necessary, but not sufficient (cf. Shellshock aka Bashdoor)

> If no one is willing or able to look at the code,  it is tantamount to being
> unreadable.

no, it's not. It is just lack of resources.

Something similar sometimes happens with mathematical results.  Somebody writes or publishes a correct proof, but nobody is willing or able to look at it at a given point in time.  It doesn't mean it is unreadable or wrong, though.   There are many historical examples of this happening, e.g., Heegner and his proof of Gauss class number 1, where it was years before it was properly read and found to be fully correct.   Abel (long ago) had similar issues at some point...

[rjf]

On Monday, October 6, 2014 7:03:27 AM UTC-7, Dima Pasechnik wrote:

On 2014-10-04, rjf <fat...@gmail.com> wrote:
> What I find interesting about this thread is that it is also relevant to
> discussions
> that open source is necessary for proofs, or correctness, or whatever.
necessary, but not sufficient (cf. Shellshock aka Bashdoor)

> If no one is willing or able to look at the code,  it is tantamount to being
> unreadable.  

no, it's not. It is just lack of resources.

I suppose that is the pure mathematics viewpoint.

Establishing a human colony on mars in the next 10 years is not possible.
No, it is just a lack of resources.
 

 

> and of course even closed-source code is in some sense
> readable in principle because a computer reads and executes it.  And
> I suppose it can usually be disassembled for closer-to-human consumption.

Except that, depending on where you live,  it might be illegal to disassemble,
or it might be legal to disassemble, but illegal to publish your findings...
What often happens when someone tries to publish results of disassembling Windows
internals, is well known.

I think that saying  "I disassembled and verified by human eyeball that this code is correct"
and "I read the hugely difficult open-source code and verified by human eyeball that this code is correct"
are similar,

I am not aware of anyone publishing results of disassembling Windows and getting in to trouble.
But then I never even thought about it.   I suspect that if I had ever needed it, as an academic
I could get source code.  Maybe not.
 

[Nathann Cohen]

Hello !

> I think that saying "I disassembled and verified by human eyeball that this code is correct"
> and "I read the hugely difficult open-source code and verified by human eyeball that this code is correct"
> are similar,

O_o

It is good that we are on sage-flame, I almost believed that you were
serious for a while.

Nathann

[Bill Hart]

He was being serious for sure. Of course he's thinking of lisp and machine code. 

((()())((()())))(())))((()))() vs 101000100010111100100001

All semantic content missing.

Bill.

[Dima Pasechnik]

On 2014-10-06, rjf <fat...@gmail.com> wrote:
>
>
> On Monday, October 6, 2014 7:03:27 AM UTC-7, Dima Pasechnik wrote:
>>
>> On 2014-10-04, rjf <fat...@gmail.com> wrote:
>> > What I find interesting about this thread is that it is also relevant to
>> > discussions
>> > that open source is necessary for proofs, or correctness, or whatever.
>> necessary, but not sufficient (cf. Shellshock aka Bashdoor)
>>
>> > If no one is willing or able to look at the code, it is tantamount to
>> being
>> > unreadable.
>>
>> no, it's not. It is just lack of resources.
>>
>
> I suppose that is the pure mathematics viewpoint.
>
> Establishing a human colony on mars in the next 10 years is not possible.
> No, it is just a lack of resources.

Oh come on... Pay me something in the range of US$30K, and I'd fix this bug.
Hell, I'd even do this for US$15K.
I am sure there are well-qualified people around who would do this for
US$5K!

>>
>> > and of course even closed-source code is in some sense
>> > readable in principle because a computer reads and executes it. And
>> > I suppose it can usually be disassembled for closer-to-human
>> consumption.
>>
>> Except that, depending on where you live, it might be illegal to
>> disassemble,
>> or it might be legal to disassemble, but illegal to publish your
>> findings...
>> What often happens when someone tries to publish results of disassembling
>> Windows
>> internals, is well known.
>>
>
> I think that saying "I disassembled and verified by human eyeball that
> this code is correct"
> and "I read the hugely difficult open-source code and verified by human
> eyeball that this code is correct"
> are similar,
>
> I am not aware of anyone publishing results of disassembling Windows and
> getting in to trouble.
> But then I never even thought about it. I suspect that if I had ever
> needed it, as an academic
> I could get source code. Maybe not.

maybe you could descend from your ivory tower and google
for examples of this. Try e.g. looking up Bowers vs. Baystate Technologies.
If you agree to EULA then you cannot disassemble...



>
>
>>
>>
>>
>>
>

[rjf]

On Monday, October 6, 2014 8:13:37 AM UTC-7, Bill Hart wrote:

He was being serious for sure. Of course he's thinking of lisp and machine code. 

((()())((()())))(())))((()))() vs 101000100010111100100001

All semantic content missing.

With a certain viewpoint, it can be (as has been) argued that all that a computer can do is
syntactically derived.  (Philosopher John Searle).  On this basis there is no semantics for
anything that a computer does.  Searle also concludes, along with some others like
Roger Penrose, that  (very roughly speaking) a computer can neither be conscious or
intelligent.  
An unintended slight to Mathematicians if they believe that computers can do all
mathematics;   while being unconscious and unintelligent.


Nevertheless,  I am closer to Bill's perspective on this.  I find it difficult enough to
find bugs in programs that I have written myself.  I am supposed to find a bug in
a program (or a proof) written by someone else?  Is that really so much easier than looking
at the output of a disassembler  (or de-compiler ??)


There is a long computer science literature on finding bugs in programs that were proved correct.

Here's a recent item that I found via google ...
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

 

[rjf]

On Monday, October 6, 2014 8:55:29 AM UTC-7, Dima Pasechnik wrote:

On 2014-10-06, rjf <fat...@gmail.com> wrote:
>
>
> On Monday, October 6, 2014 7:03:27 AM UTC-7, Dima Pasechnik wrote:
>>
>> On 2014-10-04, rjf <fat...@gmail.com> wrote:
>> > What I find interesting about this thread is that it is also relevant to
>> > discussions
>> > that open source is necessary for proofs, or correctness, or whatever.
>> necessary, but not sufficient (cf. Shellshock aka Bashdoor)
>>
>> > If no one is willing or able to look at the code,  it is tantamount to
>> being
>> > unreadable.  
>>
>> no, it's not. It is just lack of resources.
>>
>
> I suppose that is the pure mathematics viewpoint.
>
> Establishing a human colony on mars in the next 10 years is not possible.
> No, it is just a lack of resources.

Oh come on... Pay me something in the range of US$30K, and I'd fix this bug.
Hell, I'd even do this for US$15K.

Put humans on mars?

Oh, I see, write some program.
Frankly, it is not worth even US$1.00 to me.
 

I am sure there are well-qualified people around who would do this for
US$5K!

I suppose you could try to crowd-source fund this.
 

>>
>> > and of course even closed-source code is in some sense
>> > readable in principle because a computer reads and executes it.  And
>> > I suppose it can usually be disassembled for closer-to-human
>> consumption.
>>
>> Except that, depending on where you live,  it might be illegal to
>> disassemble,
>> or it might be legal to disassemble, but illegal to publish your
>> findings...
>> What often happens when someone tries to publish results of disassembling
>> Windows
>> internals, is well known.
>>
>
> I think that saying  "I disassembled and verified by human eyeball that
> this code is correct"
> and "I read the hugely difficult open-source code and verified by human
> eyeball that this code is correct"
> are similar,
>
> I am not aware of anyone publishing results of disassembling Windows and
> getting in to trouble.
> But then I never even thought about it.   I suspect that if I had ever
> needed it, as an academic
> I could get source code.  Maybe not.

maybe you could descend from your ivory tower and google
for examples of this. Try e.g. looking up Bowers vs. Baystate Technologies.
If you agree to EULA then you cannot disassemble...

I was looking for cases where Microsoft was suing.  I couldn't find any, but maybe there are cases?
My understanding of EULA is that there are still controversies about it, and in
particular a EULA that attempts to restrict fair use of a purchased item is
questionable.  (cf.  EULAs that are 56 pages long, have a clause that transfers souls
to the licensor, etc. according to today's Wikipedia...

RJF
 

>  
>
>>
>>
>>
>>
>

[Dima Pasechnik]

On 2014-10-06, rjf <fat...@gmail.com> wrote:
>
>

sure, it is much easier, as bugs are often at the level of type declarations.

[rjf]

Bugs that are at the level of a type error are usually caught at the first compilation
and therefore you won't find these easy fixes later.   (That is, there are no
visible type bugs left.) 
I would expect that the absence of comments from a disassembled program would
be more of a hazard, though sometimes the comments can be a distraction when
they are wrong / misleading / left over from older code...

For Lisp programs, most type information is optional, so one spends time
debugging the algorithms instead of the type declarations :)

[Dima Pasechnik]

surely, type bugs are not always caught by a compiler.
If you run your code on things that fit into 32 bits, and 5 years later
you try this code on something a bit bigger, then, oops,
you get errors happening.
Fixing this if you have source is easy, but if you don't,
then good luck...

[Nathann Cohen]

> surely, type bugs are not always caught by a compiler.
> If you run your code on things that fit into 32 bits, and 5 years later
> you try this code on something a bit bigger, then, oops,
> you get errors happening.
> Fixing this if you have source is easy, but if you don't,
> then good luck...

Give it up. A guy who tells you that it is better to disassemble a
proprietary software rather than read the comments of an open-source
one because they are misleading is already doing enough fighting
against himself.

Nathann

[rjf]

I suppose it is easier to make up something to ridicule it.  What I said was..

I would expect that the absence of comments from a disassembled program would

be more of a hazard,

But what is more important than keeping the flame burning.\?

 

Nathann

[Bill Hart]

I'm not sure I agree that disassembly of proprietary software is as good as open source software, commented or not and whether or not there are legal restrictions on reverse engineering in your locale.

Typically disassembly will result in code which is devoid of things like:

* label names

* function names

* variable names

* rich type information

* macros

The disassembly will also only show the code after optimisation by the compiler, which may completely obfuscate it, or even omit parts of the source code which aren't needed.

Therefore, I think it is perfectly clear that even an uncommented open source program is vastly preferable to a disassembly of a closed source one.

I think a programmer would have to be unbelievably crafty to write source code that is as obfuscated as machine code.

Bill.

--

[rjf]

On Tuesday, October 7, 2014 3:05:25 PM UTC-7, Bill Hart wrote:

I'm not sure I agree that disassembly of proprietary software is as good as open source software

I agree, however the open source advocates generally view this as a black/white situation.

open source --> can be used because it can be verified.  Even if  no one has ever verified it. Whatever that
might entail.

closed source --> cannot be used.

I'm just pointing out that (unless your CPU runs with encrypted RAM or some such thing) such
code can be examined by humans (as well as machines).

How we got out on this limb --- um, I think I mentioned open source somewhere above..

RJF

To unsubscribe from this group and stop receiving emails from it, send an email to sage-flame+unsubscribe@googlegroups.com.

[Bill Hart]

On 8 October 2014 00:25, rjf <fat...@gmail.com> wrote:

How we got out on this limb --- um, I think I mentioned open source somewhere above..

I don't know, but I think I saw someone happily sawing the limb a bit further in.

By the way, I'd be pretty surprised if the major players didn't use some kind of encryption to prevent decompiling binaries, and various other nasty tricks to trip up debuggers. For example, they can take checksums and self-modify the code depending on the value of the checksum. This ensures the code has not been modified. Then they make sure that debuggers will not run without modifying the code. Of course, with persistence, one can always work around such things. But it is certainly more effort than most people would be prepared to put in to learn how something works. Not to mention, illegal, because CFAA.

Bill.

[Richard Fateman]

On 10/7/2014 4:20 PM, Bill Hart wrote:

On 8 October 2014 00:25, rjf <fat...@gmail.com> wrote:

How we got out on this limb --- um, I think I mentioned open source somewhere above..

I don't know, but I think I saw someone happily sawing the limb a bit further in.

By the way, I'd be pretty surprised if the major players didn't use some kind of encryption to prevent decompiling binaries

I've never tried it.  Apparently there are lots of "crackers" who give away or sell programs with
the licensing bypassed (e.g. Mathematica)  and maybe some malware inserted.
So they figure out at least some of the code, whether it is self-modifying or obfuscated
somehow.

Even if  a binary file is obscured, once it is loaded into memory and executing,
there are fewer opportunities to hide.

Oh, just thinking.. If you want Sage to succeed and to do that it needs money,
why not use it for mining bitcoins?  :)

, and various other nasty tricks to trip up debuggers. For example, they can take checksums and self-modify the code depending on the value of the checksum. This ensures the code has not been modified. Then they make sure that debuggers will not run without modifying the code. Of course, with persistence, one can always work around such things. But it is certainly more effort than most people would be prepared to put in to learn how something works. Not to mention, illegal, because CFAA.

Bill.

--
You received this message because you are subscribed to the Google Groups "sage-flame" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-flame+...@googlegroups.com.

[Bill Hart]

On 8 October 2014 02:07, Richard Fateman <fat...@berkeley.edu> wrote:

On 10/7/2014 4:20 PM, Bill Hart wrote:

On 8 October 2014 00:25, rjf <fat...@gmail.com> wrote:

How we got out on this limb --- um, I think I mentioned open source somewhere above..

I don't know, but I think I saw someone happily sawing the limb a bit further in.

By the way, I'd be pretty surprised if the major players didn't use some kind of encryption to prevent decompiling binaries

I've never tried it.  Apparently there are lots of "crackers" who give away or sell programs with
the licensing bypassed (e.g. Mathematica)  and maybe some malware inserted.
So they figure out at least some of the code, whether it is self-modifying or obfuscated
somehow.

Even if  a binary file is obscured, once it is loaded into memory and executing,
there are fewer opportunities to hide.

Oh, just thinking.. If you want Sage to succeed and to do that it needs money,
why not use it for mining bitcoins?  :)

Mining bitcoins is about hardware, not software. I can only suggest that William's cunning plan to write the best bitcoin mining software in the world was not successful, so now he's moved on to bitcoin mining in the cloud with cloud.sagemath.com

I should imagine that open source hardware will be his next move.

[maldun.fin...@gmail.com]

In fact I recently had a case where this happened: Some years ago I programmed a new version for the Chebyshev polynomials

which allowed non integer first arguments since one can use the Hypergeometric Representation to give a sense to this expression.

The next developer and reviewer thought they could drop non-integer input since it does not make sense from their opinion, till I pointed

out this alternative representation.

@open vs closed source: Actually this happens a lot more often in the closed source world, than one would think.

Especially if Team/Teamleader changes are involved, orif one Company buys the source and start new development.

Concerning your Wikipedia example: Everone can also see the history of the changes. This also applies to open source.

Since everyone can look at these changes Linus' Law applies here, while in the closed source world the history changes are not visible to others.

It is not so black and white, than you may think. 

On Sunday, October 5, 2014 12:43:09 AM UTC+2, rjf wrote:

It should be clear that the presence of documentation, doctest, and QA hardly guarantees correctness. 

In fact, I have seen cases in which correct programs properly documented were misunderstood,

the code replaced with other code with different specifications, now incorrect, but passing new

and also incorrect QA.

This is a potential downside of open source.  Like lying or misinformed Wikipedia contributors,

On Saturday, October 4, 2014 3:29:10 PM UTC-7, Jakob Kroeker wrote:

I doubt that any "policy"  can ensure project maintainability unless

perhaps the policy comes with a large among of funding to pay people

to spend time on maintenance. 

@rjf

in my opinion it is not that simple here: as far as I know from the discussion,
some module routines return incorect results, so

1. it looks like  that the QA failed in this case

I looked at the source and at the first sight it seems that routines are documented and doctested.
But when trusting Nathann's comments, it is not enough to grasp the complete picture and understand
the interplay of the single routines (=> 100% doctest is not sufficient)

Summarizing the comments, there at least four options

- rewriting from scratch
- get the missing information from the previous authors
- do source code archaeology
- convince the initial authors to fix the problem

Jakob


 

Am Donnerstag, 2. Oktober 2014 18:50:43 UTC+2 schrieb rjf:

This seems to have come from some squabble on sage-devel.

I doubt that any "policy"  can ensure project maintainability unless

perhaps the policy comes with a large among of funding to pay people

to spend time on maintenance.  (Meaning fixing bugs, adding features

that are requested, making new releases for new versions of

operating systems and other packages.)

Nothing new here.

On Thursday, October 2, 2014 8:30:06 AM UTC-7, Jakob Kroeker wrote:

'Otherwise we are just stuck with a code we do not understand'

This is a citation from Nathan,
https://groups.google.com/d/msg/sage-devel/WXNmH3PL7kY/rFQlnvv9wkYJ

Question:

are the sage development policies not sufficient to ensure project maintainability,
or is Nathan's statement just caused by his frustration and is not objective?

Jakob

Remark: I do not have enough credit yet in the sage community to start a discussion like this,
so feel free to ignore it for now.