octave-maintainers
[Top][All Lists]
Advanced

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

Re: Octave Forge -- Looking for a new leader


From: Julien Bect
Subject: Re: Octave Forge -- Looking for a new leader
Date: Sun, 8 Jan 2017 20:41:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0

Le 08/01/2017 à 17:31, c. a écrit :
On 8 Jan 2017, at 16:59, Julien Bect <address@hidden> wrote:
My opinion about the second option (transforming OF into a collection of 
externally hosted repos and/or tarballs) : this would be very drastic change of 
philosophy,
I think this is one moment where we have the opportunity to make "drastic" 
changes ...

Sure, it is.

But this is in my opinion a case where a slightly more formalized decisional structure could help. Because, here, once all the arguments will have been exposed in this (or other) threads, who is supposed to make a decision?


2) And again, I believe that it requires as above a comprehensive set of tools 
for automated checking of formal correctness (unless we accept the idea that OF 
is a collection of links without any garantee of quality ?).
Is this really that bad an option?

No, I am not saying that this necessarily is a bad option. Just trying to understand the implications.


In what way do we "garantee" quality right now?

Because the person handling the releases (currently, the OF leader) does at least some basic tests of formal correctness of the package.


And how exactly do we define "quality" now?

Right, tricky question. There are certainly several aspects to the "quality" of a package. But a first layer is made of these "formal correctness" tests I was referring to.

What these tests are exactly, currently, I think that only Carnë knows for sure. (And this should change if we want to share this job between several people.)

But I assume, among other things :

a) checking that the package can be installed using pkg,

b) checking that the release tarball can be reproduced from the source repo,

c) checking that there are no duplicated functions names in OF,

d) ... (to be continued)

Most of these things can be automated (in the spirit of "R CMD check --as-cran" for R packages on CRAN [1]), but that doesn't mean that there shouldn't be someone reading the output (warning, errors, info, etc.).


@++
Julien


[1] https://cran.r-project.org/submit.html




reply via email to

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