gitstat-devel Mailing List for gitstat

Hi

I've added the 'infrastructure' to update the schema of the db. This makes it 
possible to create the initial database (not used yet) and also to update to the 
latest schema. The updatedb() function takes care of all intermediate steps.

This means that all additions to the schema should go via the newly created 
libdb.php and not via single sql-scripts. For now we should add the complete 
schema also to install/sql/gitstat.sql but this file will be removed in the 
(nearby) future to be replaced by a installation 'infrastructure'.

(reminder to self to add gitstat_settings to gitstat.sql)

Next thing I will do is add a field to the v_tag table to indicate whether a tag 
should be visible or not in the graph creation. This will be a major step away 
from the current kernel-centric gitstat.

Once the installation infrastructure is there I think we should launch a new 
version, 0.4.

As always, comments/remarks/suggestions are welcome.

Cheers,

PAul.

I think it is good to have more flexibility
so that people can configure gitstat for more
than two projects!


2007/9/29, Paul Vriens <pau...@gm...>:
> Hi,
>
> This 'apid' (which is a fixed name) is bothering me more and more. For testing
> purposes I have 2 gitstat instances running on my box (2.6 Kernel and Wine).
> When I login to one the other also shows 'Logged in' which is of course not
> correct but is due to this single variable.
>
> I'm think of embedding the project name into this variable. Or maybe even the
> database name.
>
> Any other/better ideas?
>
> 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,

This 'apid' (which is a fixed name) is bothering me more and more. For testing 
purposes I have 2 gitstat instances running on my box (2.6 Kernel and Wine). 
When I login to one the other also shows 'Logged in' which is of course not 
correct but is due to this single variable.

I'm think of embedding the project name into this variable. Or maybe even the 
database name.

Any other/better ideas?

Cheers,

Paul.

Hi,

Just wanted to let people know that I've created a new directory "include" that 
is now holding lib.php. We've lost the history for lib.php but I don't think 
that's a great loss yet.

This new "include" directory will also contain libdb.php which is solely for 
database stuff (which also means moving dbconnect from lib.php to libdb.php).

I'm also thinking of move the graph generating stuff to there (linegraph, 
bargraph and piegraph).

Cheers,

Paul.

Hi,

As you can probably see from the CVS statistics I didn't have much time to play 
with gitstat the last weeks. That certainly won't change in the nearby future 
unfortunately.

My last patches were mostly about cleanups. I've been busy for the last week to 
create an installation.php. The idea is that this (together with some library 
stuff) is going to replace the manual installation of the database.

This is what installation.php currently does:

1. Asks for the servername/username/password and verifies this.
2. Asks for new databasename and checks if it exists (it won't work currently 
with an existing one).
3. Write the above parameters to a new config file 'dbconfig.php' in a new 
config directory.
4. Creates the database.
5. Fills the database with the latest schema.
6. Adds the first admin user.

The idea is that this installation.php will be presented to the user as long as 
there is no database and dbconfig.php but also if all is correct but the 
installation.php file still exists. The administrator/installer of gitstat 
should remove installation.php on completion of the database creation.

The next steps an administrator/installer should peform:

7. Log in as an admin user.
8. Configure the rest of gitstat (the stuff that's currently in the config.php).

To accomplish the filling of the database I've started working on a new 
libdb.php that should cover all db related functions in the future. It currently 
install the base schema (the one when gitstat started V0.1) and updates the db 
with all schema changes:

- the one that adds 'filename' for single file tracking (V0.1 -> V0.2)
- a new one that creates a table 'gitstat_settings' that for now only holds the 
version of the schema (being '2' after this one).

The update routine of the schema will of course check the current state against 
the new one, hence the addition of the gitstat_settings table. The only 
parameter in there (for now) is 'dbver' (or something like that).

The idea is that we will will only have a limited amount of configuration 
parameters in a file. Most of them should be in the table giststat_settings. 
This will be done by a new 'module' in admin.php (in the future).

The first change to the schema will be to add some information about the 
visibility of tags. This visibility flag will tell if a tag needs to be 
considered in our graph creating routines. This is needed to overcome some 
hardcoded settings that only are true for the linux kernel.

I also need to find the best way to make sure we don't have the (more-or-less) 
same configuration steps for the perl-side of things.

So bottom line is that I'm still working on gitstat but in a slow pace. I also 
think we have to wait for the above changes to come out with a new release. My 
first estimate is that this will take a week or 2. Expect the first new patches 
in a few days.

If you need more information don't hesitate to contact me.

Any suggestion/remark is welcome. Please also respond if you are currently 
working on something.

Cheers,

Paul.

I saw some commits in header.php
It was modified for admin menu.
So, admin link had been added and cleaned up some codes.

But there is a trifle problem.
For getting respected design(?), it should not have any whitespace between
each link( e.g <a href=....></a>'here'<a href>).
If there are any whitespace, link would get unexpecting padding.
I modified some code for this reason.

Thanks,

Hi,

Just wanting to let you know that I did a huge cleanup of chart.php (I must say 
a bit more to my liking now).

- removed some whitespace (empty lines with only tabs replaced by empty lines).
- more consistent indentation
- more consistent use of "while(){" and "if(){", sometimes the bracket were on 
the next line

I did find one very small bug where a </a> and </center> where in the wrong order.

Now it's time to do some real hacking on chart.php as there are some things that 
needs changing because of bugs.

Cheers,

Paul.

P.S I will do the same cleanup to other files once I start really working on them.

Soon-Son Kwon(Shawn) wrote:
> Please go ahead anything first without asking... :-)
> 
> Jeongseong is currently out of office and I cannot work on it
> so you do not need to ask to us. As long as you leave the
> log message well, we will be able to catch up quickly.
> 
> 
> 2007/9/11, Paul Vriens <pau...@gm...>:
>> Hi,
>>
>> We do a lot of duplicate things in index.php and chart.php. Would it be
>> worthwhile to move some common code to a new file (chartfunc.php) or even
>> include it in lib.php?
>>
>> 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
>>
> 
> 
That explains why I don't get any reactions on my emails :-).

Cheers,

Paul.

Please go ahead anything first without asking... :-)

Jeongseong is currently out of office and I cannot work on it
so you do not need to ask to us. As long as you leave the
log message well, we will be able to catch up quickly.


2007/9/11, Paul Vriens <pau...@gm...>:
> Hi,
>
> We do a lot of duplicate things in index.php and chart.php. Would it be
> worthwhile to move some common code to a new file (chartfunc.php) or even
> include it in lib.php?
>
> 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,

We do a lot of duplicate things in index.php and chart.php. Would it be 
worthwhile to move some common code to a new file (chartfunc.php) or even 
include it in lib.php?

Cheers,

Paul.

Paul Vriens wrote:
> Paul Vriens wrote:
>> Hi,
>>
>> I just committed a change (temp. fix) to chart.php. With the change 
>> from 'committer' to 'author' the amount of data passed to horizbar.php 
>> changed.
>>
>> If you (without the patch) go to:
>>
>> http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=v2.6.22&submit=1&chart_parameter2_year=2007&chart_parameter2_month=0&submit=1 
>>
>>
>> you'll see what I mean, no graph at all.
>>
>> There is currently a hardcoded limit of 10 entries in horizbar.php but 
>> that wasn't the issue. The real issue is that we pushed to much data 
>> to horizbar.php.
>>
>> Any idea of the limits? Maybe I should be starting harder to think of 
>> not passing the data via the URL but doing it via the database as I've 
>> tried to do a few days ago (and which was working btw).
>>
>> Cheers,
>>
>> Paul.
>>
> Hi,
> 
> It looks the problem is a little different as I thought. If you look at 
> the mentioned page you see one strange entry for the Group:
> 
> Fernando Luis [** ISO-8859-1 charset **] VázquezCao
> 
> I'll have a check later on. For now the patch doesn't do any harm though.
> 
> Cheers,
> 
> Paul.
> 
Hi,

It seems that these commits are already 'wrong' in git:

commit 45ae5e968ea01d8326833ca2863cec5183ce1930
Author: Fernando Luis [** ISO-8859-1 charset **] V<E1>zquezCao <fer...@os...
Date:   Wed May 2 19:27:18 2007 +0200

     [PATCH] i386: __send_IPI_dest_field - i386

So we should either filter them out on insertion to the DB or when retrieving.

What is the best approach?

Cheers,

Paul.

Paul Vriens wrote:
> Hi,
> 
> I just committed a change (temp. fix) to chart.php. With the change from 
> 'committer' to 'author' the amount of data passed to horizbar.php changed.
> 
> If you (without the patch) go to:
> 
> http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=v2.6.22&submit=1&chart_parameter2_year=2007&chart_parameter2_month=0&submit=1 
> 
> 
> you'll see what I mean, no graph at all.
> 
> There is currently a hardcoded limit of 10 entries in horizbar.php but 
> that wasn't the issue. The real issue is that we pushed to much data to 
> horizbar.php.
> 
> Any idea of the limits? Maybe I should be starting harder to think of 
> not passing the data via the URL but doing it via the database as I've 
> tried to do a few days ago (and which was working btw).
> 
> Cheers,
> 
> Paul.
> 
Hi,

It looks the problem is a little different as I thought. If you look at the 
mentioned page you see one strange entry for the Group:

Fernando Luis [** ISO-8859-1 charset **] VázquezCao

I'll have a check later on. For now the patch doesn't do any harm though.

Cheers,

Paul.

Hi,

I just committed a change (temp. fix) to chart.php. With the change from 
'committer' to 'author' the amount of data passed to horizbar.php changed.

If you (without the patch) go to:

http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=v2.6.22&submit=1&chart_parameter2_year=2007&chart_parameter2_month=0&submit=1

you'll see what I mean, no graph at all.

There is currently a hardcoded limit of 10 entries in horizbar.php but that 
wasn't the issue. The real issue is that we pushed to much data to horizbar.php.

Any idea of the limits? Maybe I should be starting harder to think of not 
passing the data via the URL but doing it via the database as I've tried to do a 
few days ago (and which was working btw).

Cheers,

Paul.

Good suggestion.
I agree that we need to move some scripts.
e.g. graph related scripts.

but I don't know what means 'include'?
I think that It looks good, we could see most of files when we extract
.tgz file.

Thanks,


On 9/9/07, Paul Vriens <pau...@gm...> wrote:
> Hi,
>
> Currently most of our php scripts are in the root of the project. What about
> introducing some directories where we move stuff, for example:
>
> include - for most of our php-scripts
> gstat_graph - for the graph related scripts (like piegraph.php)
>
> I again welcome ideas/remarks/suggestions.
>
> 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
>

Hi,

Currently most of our php scripts are in the root of the project. What about 
introducing some directories where we move stuff, for example:

include - for most of our php-scripts
gstat_graph - for the graph related scripts (like piegraph.php)

I again welcome ideas/remarks/suggestions.

Cheers,

Paul.

Hi,

Because of the stuff I'm currently doing for tag management I need to add a 
visible item to the v_tag table.

This is of course easy but it's already the second update to the database and 
more are likely to come and we should prepare for this.

What about some kind of version control for the database tables? We need 
something in the database that tells us the current version of the schema. 
lib.php (most likely candidate) should have a variable set to the needed/current 
version. If these 2 don't match do a bunch of updates.
The above is like mythtv does it currently and sounds like a good approach.

Comments? Remarks? Suggestions?

Cheers,

Paul.

Hi,

I've just committed a change to admin.php that shows the way I'm going with some 
sort of tag management. (not functional yet)

The basic idea is that the administrator (and only the administrator currently) 
should be able to mark tags as 'visible'.

Once that part is done (adding a button and some code to write stuff to the 
database), I will replace all the hardcoded checking for size of the tagname by 
checking this new 'visible' flag.

The above will mean a 'major leap' into being not kernel centric anymore.

Comment? Remarks? Suggestions?

Cheers,

Paul.

Hi,

This has been briefly touched before.

I think it's a good idea to put some of the items that are currently in the 
configuration files (config.php and config.pl) into the database.

It lessens the burden on the poor guy who has to add similar changes to 2 files. 
This has become even more 'important' after the changes to get less kernel centric.

The only thing we can't put on the admin page is the configuration of the 
database settings. We could do it a bit like Joomla is doing this:

- Start with a configuration/installation page with the sole intent to add 
configuration parameters for the database to a config file.
- After the above step is done, this configuration/installation page should be 
deleted by the administrator.
- If the file is not deleted the user should not be able to touch any of the pages.
- We now have the database configuration and the administrator can add all the 
necessary stuff via admin.php.

The benefit is that the configfile will only hold database settings, the rest 
(all?) of the settings will be in the database.

Comments? Remarks? Suggestions?

Cheers,

Paul.

Soon-Son Kwon(Shawn) wrote:
> That is suggested but not required.
> If you want, go ahead~ We have no objection. :-)
> 
> 
> 2007/9/8, Paul Vriens <pau...@gm...>:
>> Hi,
>>
>> The FSF suggests to put the GPL license in every source file:
>>
>> http://www.fsf.org/licensing/licenses/gpl.html
>>
>> Do we want to do that as well?
>>
>> 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
>>
> 
> 
I think I'll first stick to the cleanup/fixing ;-)

Cheers,

Paul.

Soon-Son Kwon(Shawn) wrote:
> I think so.
> That is the only difference between admin / normal user.
> 
> 
> 2007/9/7, Paul Vriens <pau...@gm...>:
>> Hi,
>>
>> Just saw that we already have a admin.php. The problem is however that the only
>> way to become an admin is to change a field (privilege from 5 to 1) in the
>> database. Is that correct? (at least for the first admin).
>>
>> Cheers,
>>
>> Paul.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Gitstat-devel mailing list
>> Git...@li...
>> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>>
> 
> 
I'm currently fixing up the admin page a little bit.

Cheers,

Paul.

That is suggested but not required.
If you want, go ahead~ We have no objection. :-)


2007/9/8, Paul Vriens <pau...@gm...>:
> Hi,
>
> The FSF suggests to put the GPL license in every source file:
>
> http://www.fsf.org/licensing/licenses/gpl.html
>
> Do we want to do that as well?
>
> 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

I think so.
That is the only difference between admin / normal user.


2007/9/7, Paul Vriens <pau...@gm...>:
> Hi,
>
> Just saw that we already have a admin.php. The problem is however that the only
> way to become an admin is to change a field (privilege from 5 to 1) in the
> database. Is that correct? (at least for the first admin).
>
> Cheers,
>
> Paul.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


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

Hi,

The FSF suggests to put the GPL license in every source file:

http://www.fsf.org/licensing/licenses/gpl.html

Do we want to do that as well?

Cheers,

Paul.

Hi,

Just saw that we already have a admin.php. The problem is however that the only 
way to become an admin is to change a field (privilege from 5 to 1) in the 
database. Is that correct? (at least for the first admin).

Cheers,

Paul.

Hi,

Currently a lot of graphs have still a hardcoded length check on the tags (<8). 
This is used to get rid of the release candidates for the linux kernel. This 
hardcoded check has to be removed if we want to be able to use all kind of 
git-repositories.

The idea is:

- have the ability to create 'Admin' users
- create one or more administration pages (only for the administrator not (yet) 
for users)
- add the ability to add a 'visibility' flag to the tags
- change all php files to get rid of the '<8' and instead check for the above flag.

I think the 'Admin' user is something we have to do anyway. This also in light 
of adding a configuration/installation page (Feature Request 1784591).

For now having the ability to mark the tags should be with the administrator. In 
next versions we could maybe have the user decide as well(cookies?).

Any thoughts on this or remarks/suggestions?

Cheers,

Paul.