Thread: [Gitstat-devel] Were are we going

Hi,

As you may have noticed, the number of patches is slowing down quite 
drastically. The time I can spent on the project is more limited currently. I 
hope it will change in the (nearby) future though.

There are several issues that still need to be solved but I'm currently focusing 
on two (2) items:

- Getting an installation.php (almost finished)
- Splitting of the data gathering from the main pages (started the thinking)

The reason for item one is obviously to ease the installation part. Once that's 
done I'll continue with making the configuration a bit easier. Both these items 
are intended to get rid of the hand-written config files.

Currently some of our pages (noticeably index.php and chart.php) contain a lot 
of duplicate code to fetch data from the MySQL database.
I think we should generate this data via separate 'library' functions and have 
the index/chart pages call these functions. The major benefits are that we have 
one source for gathering data and that we split the layout a little bit more 
from the content.

Putting the data gathering part into separate functions will also make it easier 
to implement other data sources. So instead of just having MySQL we could have 
SQLite, MS SQL or even no database at all (just call the needed git functions 
directly).
The above is not something I plan to do but was just another thought.

I think the 2 mentioned items is something for version 0.5 but I also want to 
throw in a few extra's, just to make it worthwhile upgrading. Obviously we have 
to fix some of the outstanding issue. The most important one is the 'author per 
release' which is still not correct.

Hope to hear for other suggestions, remarks etc..

Cheers,

Paul.

Hi,

Sorry about late reply. I took a vacation for my private work.

I absoulutely sympathize with your mail. As we know, we didn't take
any commit for gitstat thesedays. The reasons are my lazy and my
business.

Anyway, We should progress our gistat project. Many people are waiting
for next release.
We have urgent issue and some bugs.
But, in a way,  I thought that most of gitstat function is working well, now .

I want to progress this project as a side job with long time,
And I want to keep this gitstat developer's relationship, untiringly.

I don't know about  SQLite wll, but It could be to makes our gitstat
more slim and usable.
Good suggestion.

Thanks.

p.s)
I found some gitstat :)
http://git.koha.org/gitstat/

On Dec 10, 2007 6:30 PM, Paul Vriens <pau...@gm...> wrote:
> Hi,
>
> As you may have noticed, the number of patches is slowing down quite
> drastically. The time I can spent on the project is more limited currently. I
> hope it will change in the (nearby) future though.
>
> There are several issues that still need to be solved but I'm currently focusing
> on two (2) items:
>
> - Getting an installation.php (almost finished)
> - Splitting of the data gathering from the main pages (started the thinking)
>
> The reason for item one is obviously to ease the installation part. Once that's
> done I'll continue with making the configuration a bit easier. Both these items
> are intended to get rid of the hand-written config files.
>
> Currently some of our pages (noticeably index.php and chart.php) contain a lot
> of duplicate code to fetch data from the MySQL database.
> I think we should generate this data via separate 'library' functions and have
> the index/chart pages call these functions. The major benefits are that we have
> one source for gathering data and that we split the layout a little bit more
> from the content.
>
> Putting the data gathering part into separate functions will also make it easier
> to implement other data sources. So instead of just having MySQL we could have
> SQLite, MS SQL or even no database at all (just call the needed git functions
> directly).
> The above is not something I plan to do but was just another thought.
>
> I think the 2 mentioned items is something for version 0.5 but I also want to
> throw in a few extra's, just to make it worthwhile upgrading. Obviously we have
> to fix some of the outstanding issue. The most important one is the 'author per
> release' which is still not correct.
>
> Hope to hear for other suggestions, remarks etc..
>
> Cheers,
>
> Paul.
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>

Thanks for the email, now I know I'm not the only one reading this list ;-).

Although several features are needed/wanted I'm still not pleased with the 
foundation of gitstat. So I will keep concentrating on that part and of course 
the installation stuff I started with.

One of the new ideas I'm having is to modularize a bit more (just in the 
thinking process currently). The idea is for example when looking at the index 
page that we currently have all the code in there. The new idea would be:

index.php:

header.php
   <module 1>
   <module 2>
   <module 3>
footer.php

Whereby the modules are standalone scripts that only perform a specific task, 
like showing the commits per day etc...

That way we have a very simple index.php with very easey means to add/change 
stuff. The same can be done to all other pages if needed.

As said, this is still in the 'thinking' phase.

You see I have plenty time to think but hardly time to code.

Cheers,

Paul.


??? wrote:
> Hi,
> 
> Sorry about late reply. I took a vacation for my private work.
> 
> I absoulutely sympathize with your mail. As we know, we didn't take
> any commit for gitstat thesedays. The reasons are my lazy and my
> business.
> 
> Anyway, We should progress our gistat project. Many people are waiting
> for next release.
> We have urgent issue and some bugs.
> But, in a way,  I thought that most of gitstat function is working well, now .
> 
> I want to progress this project as a side job with long time,
> And I want to keep this gitstat developer's relationship, untiringly.
> 
> I don't know about  SQLite wll, but It could be to makes our gitstat
> more slim and usable.
> Good suggestion.
> 
> Thanks.
> 
> p.s)
> I found some gitstat :)
> http://git.koha.org/gitstat/
> 
> On Dec 10, 2007 6:30 PM, Paul Vriens <pau...@gm...> wrote:
>> Hi,
>>
>> As you may have noticed, the number of patches is slowing down quite
>> drastically. The time I can spent on the project is more limited currently. I
>> hope it will change in the (nearby) future though.
>>
>> There are several issues that still need to be solved but I'm currently focusing
>> on two (2) items:
>>
>> - Getting an installation.php (almost finished)
>> - Splitting of the data gathering from the main pages (started the thinking)
>>
>> The reason for item one is obviously to ease the installation part. Once that's
>> done I'll continue with making the configuration a bit easier. Both these items
>> are intended to get rid of the hand-written config files.
>>
>> Currently some of our pages (noticeably index.php and chart.php) contain a lot
>> of duplicate code to fetch data from the MySQL database.
>> I think we should generate this data via separate 'library' functions and have
>> the index/chart pages call these functions. The major benefits are that we have
>> one source for gathering data and that we split the layout a little bit more
>> from the content.
>>
>> Putting the data gathering part into separate functions will also make it easier
>> to implement other data sources. So instead of just having MySQL we could have
>> SQLite, MS SQL or even no database at all (just call the needed git functions
>> directly).
>> The above is not something I plan to do but was just another thought.
>>
>> I think the 2 mentioned items is something for version 0.5 but I also want to
>> throw in a few extra's, just to make it worthwhile upgrading. Obviously we have
>> to fix some of the outstanding issue. The most important one is the 'author per
>> release' which is still not correct.
>>
>> Hope to hear for other suggestions, remarks etc..
>>
>> Cheers,
>>
>> Paul.
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Gitstat-devel mailing list
>> Git...@li...
>> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>>
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> 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
>