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

[Jelmer Vernooij]

+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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140326/792355cd/attachment.pgp>