Gsoc newbie interested to work with Improve buid farm lok and feel

[Jelmer Vernooij]

CC'ing mat at samba.org, who is listed as possible mentor for this project. Mat,
are you still interested in this?

I have got a lot of state on the build farm and am happy to comment, 
but it is unlikely I will end up mentoring this project.

Here is some quick feedback:

Updating to the new Samba style owuld be great. The link to the drives doc
does not actually seem to work for me.

Auto adjusting to screen size seems like a good idea.

I don't understand what you mean by "non-functional links at the top". The links
do work for me, though they are perhaps not very clear (if a particular
combination doesn't work the behaviour might be unexpected).

When you refer to an improved table style, which are you referring to?

Displaying the build logs in a more usable fashion will require more than
modifying the CSS. There is already some parsing of the build logs and using
that to improve what is displayed. We need more of that, like detecting the exact
line that caused a configure/build/test failure.  This will also be required to
do proper filtering out of errors to display in e.g. summary pages.

How would you use dulwich diff in the flaky test detection? One commit can fail
on one platform and succeed on another.

Improving the performance in particular would be very nice. I'm hesitant to see
it stated that the interpreter starting is a problem. There is overhead,
but I suspect it is not significant enough at the moment. Perhaps it'd be good
starting out the project by identifying what the performance pain points are.

Hope this helps,

Jelmer

On Tue, Mar 18, 2014 at 10:16:18PM +0530, Krishna Teja wrote:
> Based on your suggestions and some of my own ideas i have made a proposal
> can you please have a look at it and see if it can be implmented and if i
> miss something
> 
> https://drive.google.com/file/d/0B1XY2tARNnU5XzdveEpiTnBlcG8/edit?usp=sharing
> 
> 
> On Fri, Mar 14, 2014 at 9:27 AM, Jelmer Vernooij <jelmer at samba.org> wrote:
> 
> > +CC Matthieu Patou, who is listed as possible mentor for build farm
> > improvements.
> >
> > On Fri, Mar 14, 2014 at 07:38:49AM +0530, Krishna Teja wrote:
> > > 1.to show test coverage buildfarm uses lcov
> > > https://build.samba.org/lcov/data/coverage/ccache/ the display not so
> > > appealing can we use any other front end to display the statistics in
> > another
> > > way we can make our own code that does it without effecting build farm.
> > It would be nice to integrate the lcov results into the main build
> > farm UI. Personally I think the current display is okay for our
> > purposes, though there's always improvements that can be made.
> >
> > > 2.Well in the ideas they have given ajax to improve the page speed how
> > does
> > > ajax help in this situation. Ajax is "the method of exchanging data with
> > a
> > > server, and updating parts of a web page - without reloading the entire
> > > page."but buildfarm doesnt take any input,it is just hyperlinks. is
> > there any
> > > way to change the information even when there is no input like websites
> > show
> > > live score so whenever the new results are obtained by processing build
> > log
> > > files they are automatically reflected.
> > AJAX helps because it means we can load part of the page without
> > having to wait for all of the information to come in. E.g. for the
> > summary page we can display all the tables and fetch the actual build
> > results in the back ground and fill them in as they come in.
> >
> > > 3.well i guess the build farm is slow because starting and initialising
> > > application using cgi takes time.We can use fastcgi that uses persistent
> > > process so the overhead of starting new process is avoided.porting it
> > would
> > > be very essy from cgi
> > I think wsgi would be more appropriate than fastcgi here. That said, I
> > would be very surprised if the CGI overhead was a significant factor
> > in the page load time.
> >
> > > 4.You were talking about separate daemon that process build logs as soon
> > as
> > > they come and add to database then when a new request comes the already
> > > existing information in the database will be read without any
> > processing.but
> > > even here the overhead of starting will be there.is there any way of
> > doing it
> > > by combining with fastcgi
> > I'm not sure I understand this point.
> >
> > Cheers,
> >
> > Jelmer
> >
> > > On Thu, Mar 13, 2014 at 8:21 PM, krishna teja perannagari <
> > > krishnatejaperannagari at gmail.com> wrote:
> > >
> > > > 1.to show test coverage buildfarm uses lcov
> > > > https://build.samba.org/lcov/data/coverage/ccache/ the display not so
> > > > appealing can we use any other front end to display the statistics in
> > > > another
> > > > way we can make our own code that does it without effecting build farm.
> > > >
> > > > 2.Well in the ideas they have given ajax to improve the page speed how
> > does
> > > > ajax help in this situation. Ajax is "the method of exchanging data
> > with a
> > > > server, and updating parts of a web page - without reloading the entire
> > > > page."but buildfarm doesnt take any input,it is just hyperlinks. is
> > there
> > > > any
> > > > way to change the information even when there is no input like websites
> > > > show
> > > > live score so whenever the new results are obtained by processing
> > build log
> > > > files they are automatically reflected.
> > > >
> > > > 3.well i guess the build farm is slow because starting and initialising
> > > > application using cgi takes time.We can use fastcgi that uses
> > persistent
> > > > process so the overhead of starting new process is avoided.porting it
> > would
> > > > be very essy from cgi
> > > >
> > > > 4.You were talking about separate daemon that process build logs as
> > soon as
> > > > they come and add to database then when a new request comes the already
> > > > existing information in the database will be read without any
> > > > processing.but
> > > > even here the overhead of starting will be there.is there any way of
> > > > doing it
> > > > by combining with fastcgi
> > > >
> > > >
> > >
> > >
> > > --
> > > krishna teja perannagari
> >
> 
> 
> 
> -- 
> krishna teja perannagari