gitstat-devel Mailing List for gitstat

We are pleased to announce the release of gitstat 0.4.

Gitstat is a GPL’d, web-based git statistics and monitoring system.

This release is mainly a maintenance release with a lot of restructuring. This 
release also puts some groundwork in for future releases that will make the 
installation and configuration much more friendly.

New features:
- Automatic database updates on top of the base install
- Tag management on the admin page
- Multiple gitstat instances on one webserver
- More graphs can handle pages (back and forward in time)

Needless to say that there is still a lot to do.

You are welcome to try gitstat at http://tree.celinuxforum.org/gitstat

For any suggestion, bug report, or patches, please visit 
http://sourceforge.net/projects/gitstat

Cheers,

Paul.

Hi,

While playing with the new tag management I've discovered a bug with our 
implementation (See BUG 1807418) or a limitation in URL size or Apache or PHP.

What basically happens it that we pass to much data (URL length?) to our 
piechart.php. The current link for v2.6.22 of the kernel is already 7994 
characters long. For the v2.6.23 kernel it will be even longer as there were 
more participants (authors).

I've thought of several solution:

- do all the calculations before we go to piechart.php. We currently do the 
calculation and limiting in piechart.php. If we limit we assign 'etc' with the 
rest. We could do that of course before calling and sent only 21 values (20 real 
ones and the "etc").

- use the database as in intermediate step for passing the data:

In for example index.php or chart.php:
1. Generate the needed data strings and store it in a table
2. Retrieve the row where the data is stored
3. Pass the row number (unique id) to the graph generating script
In the graph generating script like piechart.php:
4. Retrieve the data identified by the given row
5. Draw the d*mn thing.

My preference is number 2 as it will also solve the huge URL's we are currently 
having. The downfall of number 2 is that we store stuff in the database and we 
have to remove it every now and then. We can't remove it straight away as that 
would mean the user can't click on the picture anymore. (Or we change the URL 
for the picture to point to index.php/chart.php with enough options to generate 
the chart again but that will mean performance).

I already had a working prototype of number 2 a few weeks ago. I didn't find a 
satisfying way to delete that data in the database though. I'm thinking of doing 
this via a batch job that deletes data older than 1 or 2 days.

This time I really like some input :-)

Cheers,

Paul.

Hi,

On my test/development box I have two 'instances' of gitstat. One that covers
the kernel and one that covers Wine.

We were using $_SESSION['apid'] to hold the email address of the users that's 
logged in. Needless to say that when I logged in to 'Kernel', 'Wine' also 
thought that I was logged in and looking at the email-address it shows the 
'Kernel' one. Confusion altogether.

I've fixed this by introducing:

$_SESSION[$GSTAT[GIT_PROJECT_NAME]] to hold the email address of the logged in 
user. I of course rely here on the fact that project names will most of the time 
be different.

I had to fix another problem after this. When I login to both everything is fine 
but when I logout of one I was also 'logged out' of the other because the 
session was destroyed.

I've fixed that by introducing:

$_SESSION['sessioncount'] that's incremented on login() and decremented on 
logout(). The session is only destroyed when $_SESSION['sessioncount'] reaches 0.

It's not perfect but it works for me.

Cheers,

Paul.

Of course we need to get more attention
by making more noises(?) to git or other
open source projects which use git for
their source code management tool. :-)

Every time I read your message, I am very
sorry that I and Jeongseong cannot spare
enough time these days.

We appreciate your effort very much and
I am sure we will be able to recruit more members
considering the uniqueness of our effort.

2007/10/2, Paul Vriens <pau...@gm...>:
> Hi,
>
> I've just committed a first change to index.php that makes use of the new
> visible flag.
>
> Currently you can change the visibility of a flag only through the admin page
> but I guess it has to be user specific at some point in time.
>
> Visibility means that instead of relying on some hardcoded check for the length
> of a version/tag name we now rely on this visible field. This makes sure that we
> are not kernel release centric anymore. The downside is that you have to make
> all the rc-version of the kernel in-visible to have the same output as before.
>
> The tag management can change of course to include some common queries instead
> of checking each single tag.
>
> Next patches will make sure we get rid of the "< 8" checks in the code and
> instead will rely on the visible flag.
>
> Comments/remarks/suggestions are welcome as always (but I think only 3 people
> read this list :-(, including me )
>
> Cheers,
>
> Paul.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


-- 
http://kldp.org/~kss

Hi,

I've just committed a first change to index.php that makes use of the new 
visible flag.

Currently you can change the visibility of a flag only through the admin page 
but I guess it has to be user specific at some point in time.

Visibility means that instead of relying on some hardcoded check for the length 
of a version/tag name we now rely on this visible field. This makes sure that we 
are not kernel release centric anymore. The downside is that you have to make 
all the rc-version of the kernel in-visible to have the same output as before.

The tag management can change of course to include some common queries instead 
of checking each single tag.

Next patches will make sure we get rid of the "< 8" checks in the code and 
instead will rely on the visible flag.

Comments/remarks/suggestions are welcome as always (but I think only 3 people 
read this list :-(, including me )

Cheers,

Paul.

Hi,

I want to change header.php so that the rest of the files have to include 
lib.php themselves instead of relying on the include via header.php. The intent 
of header.php is markup and should not be used otherwise I guess.

I guess just doing a: include_once "include/lib.php" in header.php would have 
that effect. We need the include_once as we check if the admin user is logged in.

Objections?

Cheers,

Paul.

Hi,

We currently have something like:

<div id=header>
<div class=content>
	<div id=articles>
		<div id=left>
		<div id=right>
	<div id=footer>

(so footer is part of content0

Wouldn't it make more sense to have:

<div id=header>
<div class=content>
	<div id=articles>
		<div id=left>
		<div id=right>
<div id=footer>

There is a comment in footer.php (<!--end of div content-->) but no associated 
/div with it.

Cheers,

Paul.