Skip to content

[Bioc-devel] Updated check results page

16 messages · Seth Falcon, Byron Ellis, Robert Gentleman +5 more

Original
Seth Falcon
# 
Hi All,

First off, I would like to introduce Herve Pages, a new member of our
group here in Seattle.

Herve has been working on some improvements to the package build/check
system including a face-lift for the check results page.

Our goal is a more reliable build system with results that are easier
for you as package developers to use.

Please have a look at the two proposed report formats and tell us what
you think.

http://www.bioconductor.org/checkResults/checkResults.html


Best Wishes,

+ seth
Kasper Daniel Hansen
# 
I like format B because it gives you a better overview of a single  
package. But I suspect that people who want a more general overview  
(like you Seth :) likes format A.

In addition I would really, really like the page to link to  
compilation messages (the 00install.out file - like the stuff you  
sent me some time ago, that was very helpful). I hope to see that as  
well.

Kasper
On Nov 10, 2005, at 5:09 PM, Seth Falcon wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Seth Falcon
    

    

      
      #
    

  


  

      
On 10 Nov 2005, khansen at stat.berkeley.edu wrote:

        

            

      
      
      
    

        
Yes, there are two use cases, but I'm most interested in making the
check results useful for package developers.  The easier it is for
package maintainers to review the status of their package(s) and fix
problems as they arise, well, the easier things are on our end here.

            

      
      
      
    

        
We are now capturing more output.  Click on the OK next to RBGL under
the BUILD column and you will see compilation messages.

But I think we are only capturing output from R CMD build (not
INSTALL).  *If* the package has a vignette, then R CMD build will
trigger a local install.

So perhaps our new setup provides an incentive for adding vignettes?
;-)

We'll look into adding installation logs.

Thanks for the feedback.

+ seth

  
  


  


      

    

    

      
      

        


  

        

      Robert Gentleman
    

    

      
      #
    

  


  

      
Hi,
  one preference I have is for the ERROR and WARNING glyphs to be like 
the MISSING ones, red with white letters. I find that easier to read 
(and wonder if OK should not also be green with white letters?)

I see a single svn value on the page, is that maintainable? Are all 
platforms built off the same checkout?


otherwise a nice change

Robert

        
Seth Falcon wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
I prefer Style B, though I think that the Error and Missing should be  
reversed---Error is often more interesting than Missing and Missing's  
styling stands out much better.

        
On Nov 10, 2005, at 5:09 PM, Seth Falcon wrote:

        

            

      
      
      
    

        

      
      
    

        
---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian

  
  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Hi Kasper,

We provide the complete output of the "R CMD build" and "R CMD INSTALL 
--build"
commands. This includes compilation messages.
For example:
    
http://www.bioconductor.org/checkResults/1.8/html2/lemming/affxparser.buildbin.html
shows all the g++ warnings.
And:
    
http://www.bioconductor.org/checkResults/1.8/html1/gopher5/Rredland.buildsrc.html
shows a ld error.
Regards,

Herv?

        
Kasper Daniel Hansen wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Hi Robert,

        
Robert Gentleman wrote:

        

            

      
      
      
    

        
I've changed the CSS file for format A to have the "OK" glyphs
white on green background. Do you like it better?
I can do the same kind of change for the "ERROR" and "WARNINGS"
glyphs too.

            

      
      
      
    

        
Yes, all packages are built off the same checkout.
And all the builds/checks on all nodes are made with the same R (same 
rev. numer
too). I'm not sure I understand what you mean by "is it maintainable?"...

            

      
      
      
    

        
Glad you like it. Thanks!

Herv?

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Robert Gentleman
    

    

      
      #
    

  


  

      
Herve Pages wrote:

            

      
      
      
    

        
I do - and would like ERROR and WARNING to change - at least for me, I 
find them hard to read as they are now

            

      
      
      
    

        
can we keep all in sync? Sometimes we may want to report a Linux 
build off a new checkout, but have not finished the windows build etc? 
So then what do we do? Keep the new builds off line until we can build 
on all platforms?

            

      
      
      
    

        
I do - there is a lot more detail in the outputs and hopefully 
developers will find this useful

  Robert

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Robert Gentleman wrote:

        

            

      
      
      
    

        
I changed them. All the glyphs are now written in white on a dark 
background. There
are subtle variations in the different backgrounds though.

            

      
      
      
    

        
Yes, we have to wait that all builds are done on all platforms before we can
generate this cross report.

Herv?

PS: BTW, do you have a preference between formats A and B?

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Keith Satterley
    

    

      
      #
    

  


  

      
Welcome Herve,

I prefer format B as it is more compact.

I would like the glyphs to more distinctive. I think a change of color, 
similar to the old check results would help, or the way they were 
done(changed whilst I as writing this!) in format B.

 I would suggest

ERROR => Red background,  contrasting font color, white or maybe black.
WARNINGS => Yellow background,  contrasting font color,
MISSING => Blue background, contrasting font color,
OK => Green background, white font color

cheers,

Keith Satterley

        
Herve Pages wrote:

        

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Kasper Daniel Hansen
    

    

      
      #
    

  


  

      
Ok, but as far as I understand your and Seth's email, I can only see  
the compilation log if
   1) I am building a package vignette
or
   2) A binary is being build (windows)

Would it be possible to add the compilation log for every "instance"  
of every package?

And to derail the discussion: what are you actually doing wrt. binary  
mac packages?

Kasper

        
On Nov 10, 2005, at 6:26 PM, Herve Pages wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Vincent Carey
    

    

      
      #
    

  


  

      
Hi, I've finally had a look at this.  It's very impressive.

A few comments

1) indexing the tables by hostname is peculiar to me.  i can
look up the hostname or i can learn the right to left sequence,
but i would prefer something qualitative: linux 64, linux 32,
sparc, windows 64?  if i need to know details i can look in the
table

2) MISSING is a strange tag -- in general, it would be good for
the page to give an indicator of when the developer should
do something to get a more favorable status; edd is MISSING
for lemming, but i don't know how to make it OK

3) Purely for the convenience of authors of multiple packages,
it would be good to put the author name somewhere on the page, maybe
in the rightmost column so that one can do browser finds

as for A vs B -- i find that the distinction of BUILD BIN is
more prominent in B and again i don't know what the developer should
do for a package whose BUILD BIN status on windows differs from
its CHECK status there.  i prefer A but not strongly.

so perhaps there could be some descriptive text accessible via
linked at the top (e.g., what to do if your package is not OK)
which gives general suggestions on how to improve status

thanks again
vince

  
  


  


      

    

    

      
      

        


  

        

      Jeff Gentry
    

    

      
      #
    

  


  

          

      
      
      
    

        
They both look very nice.  My two comments are that first I have always
found it very helpful to have the maintainer name next to the package
name.  This has a practical effect beyond visual in that one can do a
'find' on your name to immediately get to your package(s).  Also, IMHO it
would be better to have the column names for the different platforms to
list the platform and not the hostname (and perhaps some combination of
arch & OS, eg 'x86_64 Linux').  These immediately have more meaning to me
then a hostname, and while the table does exist at the top there would be
less cross referencing if it went the other way around.

In terms of visuals, I feel that format A looks nicer and is easier to
immediately parse but format B does contain more information.

  
  


  


      

    

    

      
      

        


  

        

      Seth Falcon
    

    

      
      #
    

  


  

      
On 11 Nov 2005, khansen at stat.berkeley.edu wrote:

        

            

      
      
      
    

        
What's that?  I thought all Bioconductor packages have vignettes ;-)

            

      
      
      
    

        
Possible, yes.

I think it is the case that if there is a vignette, then the logs we
capture are going to be identical to what we'll capture by providing
the INSTALL output.

If that isn't the case, I'm willing to move INSTALL log capture up on
the priority list.  There are other improvements I would like to see
as well, but there are also other parts of the project that need our
attention.

            

      
      
      
    

        
Right now, we are not building OS X binaries ourselves.  We plan to
add such a build, but I don't have an ETA.

Simon Urbanek and Stefano Iacus have been very generous with their
time in producing OS X binaries.

+ seth

  
  


  


      

    

    

      
      

        


  

        

      Seth Falcon
    

    

      
      #
    

  


  

      
On 11 Nov 2005, stvjc at channing.harvard.edu wrote:

        

            

      
      
      
    

        
That's a good point.

            

      
      
      
    

        
That is what we are aiming for and perhaps ERROR would suffice.  One
can receive WARNINGS on R CMD build and still get a tarball.  Can one
get ERROR messages and still get a (usable) tarball?  

The MISSING label indicates that no tarball was produced from R CMD
build.

For the case of edd, there is info when you click:
http://www.bioconductor.org/checkResults/1.8/html2/lemming/edd.buildsrc.html

Looks like a build system issue where we've run out of tempdirs :-(

            

      
      
      
    

        
Another good point that Jeff also raised.  We will add maintainer
info.

            

      
      
      
    

        
Good idea.  Perhaps a Bioconductor package bug fixing How To.  Are you
volunteering to draft something ;-)

Thanks for the useful feedback.

Best,

+ seth

  
  


  


      

    

    

      
      

        


  

        

      Vincent Carey
    

    

      
      #
    

  


  

          

      
      
      
    

        
I would be willing to start on this.  This isn't truly about bug
fixing, though, it is primarily about responding to the findings on the
package check page.  This involves

1) understanding the vocabulary of check status results
 - "WARNINGS/ERROR":  i need to look through some examples to see what
kind of documentation would be helpful here -- we should write
up what to do for the most prevalent problems
 - builds but doesn't pass check ... this is a somewhat
obscure situation, may relate to platform or java dependencies.
We want to help developers avoid this.
 - "OK" -- i guess this is what we are shooting for, but there
may be a need for more refinement here -- some conditions like
vignette lacks keywords, or package lacks vignette, or too many
functions are aliased without proper pages/examples, can be present
with packages in OK status.  such packages are OK by a very
particular criterion, but in reality need more development.

2) understanding relationship between platform used and check
status results.  i suppose that we get between-platform discrepancies
when portable coding is not used, and we can give pointers on that
in a document.  we should provide clear guidance to people on
how they can build and check their own packages on windows machines --
if it looks like people are just avoiding that superficially.
(we could assemble the links to the required tools and quick
installation notes in one of our pages for this purpose).

Perhaps what we really need is to put some information about this
in the "How to create Bioconductor packages" document --
we have some links that relate to this on the developer page
but we may need something much more concrete, along the lines
of Writing R Extensions, and this would point developers directly
to the check status page -- which really needs to be as self-documenting
as possible.