gitstat-devel Mailing List for gitstat

Hi Shawn,

I know that we should probably advertise more. The problem is that currently 
there are some issues with http://tree.celinuxforum.org/gitstat/. The site 
doesn't act as it should (I think Lee has asked someone to look into this) and 
isn't a good example site anymore.

Cheers,

Paul.

Soon-Son Kwon(Shawn) wrote:
> I am sure the number of people involved
> is because few people knows about gitstat
> not because nobody cares.
> 
> It is a unique tool with nice features
> but we need try harder to get more people
> know about gitstat.
> 
> Posting the release news to more relevant
> lists/websites or announcing a weekly stat
> based on gitstat to lkml will certainly help
> get more attention which will follow more
> developers get involved.
> 
> My problem is I can no longer work on gitstat
> but I still want you / other people enjoy this project
> and attract more people.
> 
> 
> 2008/4/24, Paul Vriens <pau...@gm...>:
>> Hi,
>>
>>  I've just released v0.5 of gitstat. No major changes from a visual
>>  perspective but again a lot of restructuring and refactoring.
>>
>>  I try and be quicker with new releases but also try and put in more new
>>  features so it's worth upgrading.
>>
>>  I must admit that I'm a bit disappointed in the number of people that
>>  want to get involved in gitstat. Is this because nobody knows about
>>  gitstat or nobody cares?
>>
>>  My time will be limited the coming months so don't expect a lot in a
>>  short timeframe.
>>
>>  The main goal for a next release is accuracy and more stats.
>>
>>  Cheers,
>>
>>  Paul.
>>
>>  -------------------------------------------------------------------------
>>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>  Don't miss this year's exciting event. There's still time to save $100.
>>  Use priority code J8TL2D2.
>>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>  _______________________________________________
>>  Gitstat-devel mailing list
>>  Git...@li...
>>  https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>>
> 
> 

I am sure the number of people involved
is because few people knows about gitstat
not because nobody cares.

It is a unique tool with nice features
but we need try harder to get more people
know about gitstat.

Posting the release news to more relevant
lists/websites or announcing a weekly stat
based on gitstat to lkml will certainly help
get more attention which will follow more
developers get involved.

My problem is I can no longer work on gitstat
but I still want you / other people enjoy this project
and attract more people.


2008/4/24, Paul Vriens <pau...@gm...>:
> Hi,
>
>  I've just released v0.5 of gitstat. No major changes from a visual
>  perspective but again a lot of restructuring and refactoring.
>
>  I try and be quicker with new releases but also try and put in more new
>  features so it's worth upgrading.
>
>  I must admit that I'm a bit disappointed in the number of people that
>  want to get involved in gitstat. Is this because nobody knows about
>  gitstat or nobody cares?
>
>  My time will be limited the coming months so don't expect a lot in a
>  short timeframe.
>
>  The main goal for a next release is accuracy and more stats.
>
>  Cheers,
>
>  Paul.
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Gitstat-devel mailing list
>  Git...@li...
>  https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


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

Hi,

I've just released v0.5 of gitstat. No major changes from a visual 
perspective but again a lot of restructuring and refactoring.

I try and be quicker with new releases but also try and put in more new 
features so it's worth upgrading.

I must admit that I'm a bit disappointed in the number of people that 
want to get involved in gitstat. Is this because nobody knows about 
gitstat or nobody cares?

My time will be limited the coming months so don't expect a lot in a 
short timeframe.

The main goal for a next release is accuracy and more stats.

Cheers,

Paul.

Hi,

While finishing off the installation and admin pages and getting ready 
for the new release (yeah) I've run into an issue.

It's not an issue I want to solve right away as it needs some (a lot 
of?) thought.

I've made a local gitstat site for Git itself.

The problem is that there appears to be 3 lines/streams of development 
in this tree:

development of 1.5.5 (with several release candidates, rc3 being the latest)
1.5.4 and further work on this (1.5.4.5 being the latest)
gitgui (0.9.3) being the latest.

So we need something to be able to tell these streams apart.

Is this something we want/need to do on the admin side?

Without any inner knowledge of a project it will be very hard to tell 
which is which so I'm afraid it will be up to the admin?

As said this is not a v0.5 or probably v0.6 thing but needs to be tackled.

Cheers,

Paul.

Lee jungseung wrote:
> Hi,
> 
> First of all, Thanks for your contribution.
> Actually, I couldn't focus on gitstat these days, sorry for that.
> 
> I don't know the way of using dbconfig.php and gitstatconfig.php.
> So, I couldn't tell about that well, but if it is needed to separate config.
> php, your idea could be good solution.

The idea behind this is that:

dbconfig.php holds the database configuration stuff (like GSTAT['ID'])
gitstatconfig.php holds all other configuration paramaters.

For people who are updating they can just copy their config.php to these new 
files. The functions in lib.php will make sure only the relevant stuff is extracted.

The dbconfig.php is always needed somewhere on the disk whereas the other stuff 
can reside anywhere we want.

gitstatconfig.php will be removed in the future and those parameters will reside 
in a/the database.

> 
> With some perl code it could be separated easily. But it doesn't care a
> whoop.

I actually thought about changing config.pl to do that but decided generating it 
from the admin page was so much easier. Especially as this will be moved partly 
to the database I didn't feel like touching config.pl.

This does however mean that the dbconfig.php has to change into a different kind 
of file/format so it can be read easily by both php and perl without too much 
hassle.

> 
> I'm waiting for new installation page. Someone said that gitstat is too
> complex to install and use. If it is done, gitstat could be used by more
> people.

I totally agree. I didn't know it would take this much effort though :-)
I will stop beautifying the installation and admin page, that's something we can 
do afterwards.

Cheers,

Paul.

Hi,

First of all, We should concentrate on making accurate data :-)

Thanks, 

-----Original Message-----
From: git...@li... [mailto:gitstat-devel-
bo...@li...] On Behalf Of Paul Vriens
Sent: Wednesday, April 02, 2008 5:52 PM
To: git...@li...
Subject: [Gitstat-devel] Linux Kernel Development

Hi,

Just found this one:

https://www.linux-foundation.org/publications/linuxkerneldevelopment.php

The numbers are a bit different from what we currently show. So this means
some 
work to get our numbers right or prove the other numbers are wrong ;-)

Cheers,

Paul.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Gitstat-devel mailing list
Git...@li...
https://lists.sourceforge.net/lists/listinfo/gitstat-devel

Hi,

First of all, Thanks for your contribution.
Actually, I couldn't focus on gitstat these days, sorry for that.

I don't know the way of using dbconfig.php and gitstatconfig.php.
So, I couldn't tell about that well, but if it is needed to separate config.
php, your idea could be good solution.

With some perl code it could be separated easily. But it doesn't care a
whoop.

I'm waiting for new installation page. Someone said that gitstat is too
complex to install and use. If it is done, gitstat could be used by more
people.

Thanks,

 -----Original Message-----
From: git...@li... [mailto:gitstat-devel-
bo...@li...] On Behalf Of Paul Vriens
Sent: Wednesday, April 02, 2008 3:52 PM
To: git...@li...
Subject: [Gitstat-devel] New installation and configuration pages

Hi,

Soon (I promise) I will commit the new installation page and the changed
admin page.

This makes it possible to have a more-or-less graphical installation
procedure. 
Next to that you should be able to create and change a configuration file
from 
within the admin page.

The admin page will write out a new configuration file in gstat_rw/config/
and 
also create a template perlconfig.pl file. This file can then be copied and
used 
in the gstat_pl part.

This is all nice for people that install from scratch. I'm currently
struggling 
with how to approach this for people who upgrade. Any advise?

The old config.php file will be gone. We can of course ask the upgrader to
copy 
the config.php file to:

1. gstat_rw/config/dbconfig.php
AND
2. gstat_rw/config/gitstatconfig.php

That should do the trick. As long as the account for the webserver has full 
access to those files (and that config directory). The config file will
have to 
much information in them but that's not important anymore.

The step after this while installation/config stuff is to move the
configuration 
piece to the database. That's post v0.5 however.

I don't need to tell you that we need a v0.5 soon but I don't want to rush
this 
and have at least something halfway decent in place.

Cheers,

Paul.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Gitstat-devel mailing list
Git...@li...
https://lists.sourceforge.net/lists/listinfo/gitstat-devel

Hi,

Just found this one:

https://www.linux-foundation.org/publications/linuxkerneldevelopment.php

The numbers are a bit different from what we currently show. So this means some 
work to get our numbers right or prove the other numbers are wrong ;-)

Cheers,

Paul.

Hi,

Soon (I promise) I will commit the new installation page and the changed admin page.

This makes it possible to have a more-or-less graphical installation procedure. 
Next to that you should be able to create and change a configuration file from 
within the admin page.

The admin page will write out a new configuration file in gstat_rw/config/ and 
also create a template perlconfig.pl file. This file can then be copied and used 
in the gstat_pl part.

This is all nice for people that install from scratch. I'm currently struggling 
with how to approach this for people who upgrade. Any advise?

The old config.php file will be gone. We can of course ask the upgrader to copy 
the config.php file to:

1. gstat_rw/config/dbconfig.php
AND
2. gstat_rw/config/gitstatconfig.php

That should do the trick. As long as the account for the webserver has full 
access to those files (and that config directory). The config file will have to 
much information in them but that's not important anymore.

The step after this while installation/config stuff is to move the configuration 
piece to the database. That's post v0.5 however.

I don't need to tell you that we need a v0.5 soon but I don't want to rush this 
and have at least something halfway decent in place.

Cheers,

Paul.