From: Paul V. <pau...@gm...> - 2008-02-28 19:53:24
|
Hi, I was playing with the "Top contributor's domain (Date)" charts. 2008 was selected and I could see month 1 and 2 in the month list. If you now select 2007 you will see that the month list has 1...12 plus the old 1 and 2. Likewise if you start and have 2008 in the year list you will have 1 and 2 in the month list. If you now select 1 in the month list and check the month list again it will contain 1 2 and 1 2. Just wanted to let you know that I'm still active :-) Cheers, Paul. |
From: Lee j. <jun...@gm...> - 2008-03-03 06:56:07
|
Hi, Paul I saw your commit on gitstat. I has following up your works on gitstat! :) Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Friday, February 29, 2008 4:53 AM To: git...@li... Subject: [Gitstat-devel] Fixed a nice bug in chart.php Hi, I was playing with the "Top contributor's domain (Date)" charts. 2008 was selected and I could see month 1 and 2 in the month list. If you now select 2007 you will see that the month list has 1...12 plus the old 1 and 2. Likewise if you start and have 2008 in the year list you will have 1 and 2 in the month list. If you now select 1 in the month list and check the month list again it will contain 1 2 and 1 2. Just wanted to let you know that I'm still active :-) Cheers, Paul. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Gitstat-devel mailing list Git...@li... https://lists.sourceforge.net/lists/listinfo/gitstat-devel |
From: Paul V. <pau...@gm...> - 2008-03-03 07:23:18
|
Lee jungseung wrote: > Hi, Paul > > I saw your commit on gitstat. > I has following up your works on gitstat! :) > Thanks, > Hi Lee, I'm now busy with the 'Per-directory changeset' chart. It's a lot of code that can be simplified greatly. Another thing is that this code has a few bugs as well :-). Next things I'm going to do: - Fix 'Per-directory changeset (Date)' - Move 'Per-direcory changeset (Date)' to libgather.php - Introduce 'Per-directory changes (Release)' - Use 'Per-directory changes (Release)' in chart.php - Introduce installation.php - Release 0.5 After 0.5: - Do more abstraction work to get all MySQL stuff to include files - Group functions together in libgather.php if possible. - Start being more object oriented as far a data gathering is concerned - Introduce a few more chart types - Release 0.5.1 I want the above release to be fairly quickly after 0.5 so people actually see something changing. Most of the work until now has been 'behind the scenes'. After 0.5.1: - Move the chart data generation (chart.php/index.php using libgather.php of course) directly to the chart generating php's. This means we don't pass data as we do now but rather specify something like "charttype=author_by_release&release=???". This would solve the problems we have with passing huge amount of data and gets rid of those awfully long links. - The rest of the TODO list :-) One thing I see when browsing the web searching for gitstat (or related stuff) is that people seem to be very interested in things like: - number of lines changed in a release - number of files changed in a release One thing I'm interested in is: - number of commits for 1 particular user over the total project (per release/date). This is an easy one I think so I may throw that in 0.5 or 0.5.1. We should also start having a clearer TODO list maybe even with timelines (ouch) ? Any other idea, remarks, suggestions? I want 0.5 to come out soon so if suggestions are simple we can do that for 0.5 otherwise it has to wait. Cheers, Paul. |
From: Lee j. <jun...@gm...> - 2008-03-04 01:11:34
|
Hi, Paul Nice arrangement for our TODO! I saw Greg KH's mail at kenreltrap.org, it contains some category like you mentioned. Turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did: lines added per day: 4945 lines removed per day: 2006 lines modified per day: 1702 http://kerneltrap.org/Linux/Kernel_Rate_of_Change There has been no such statistics, so just like information (restrictive at specific kernel version) are useful. I think both his and yours are valuable. And.. Actually, we need clearer TODO list with timeline. But it is not easy to make a plan and decision. ;-< Let's talk about it later. Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Monday, March 03, 2008 4:23 PM To: git...@li... Subject: Re: [Gitstat-devel] Fixed a nice bug in chart.php Lee jungseung wrote: > Hi, Paul > > I saw your commit on gitstat. > I has following up your works on gitstat! :) > Thanks, > Hi Lee, I'm now busy with the 'Per-directory changeset' chart. It's a lot of code that can be simplified greatly. Another thing is that this code has a few bugs as well :-). Next things I'm going to do: - Fix 'Per-directory changeset (Date)' - Move 'Per-direcory changeset (Date)' to libgather.php - Introduce 'Per-directory changes (Release)' - Use 'Per-directory changes (Release)' in chart.php - Introduce installation.php - Release 0.5 After 0.5: - Do more abstraction work to get all MySQL stuff to include files - Group functions together in libgather.php if possible. - Start being more object oriented as far a data gathering is concerned - Introduce a few more chart types - Release 0.5.1 I want the above release to be fairly quickly after 0.5 so people actually see something changing. Most of the work until now has been 'behind the scenes'. After 0.5.1: - Move the chart data generation (chart.php/index.php using libgather.php of course) directly to the chart generating php's. This means we don't pass data as we do now but rather specify something like "charttype=author_by_release&release=???". This would solve the problems we have with passing huge amount of data and gets rid of those awfully long links. - The rest of the TODO list :-) One thing I see when browsing the web searching for gitstat (or related stuff) is that people seem to be very interested in things like: - number of lines changed in a release - number of files changed in a release One thing I'm interested in is: - number of commits for 1 particular user over the total project (per release/date). This is an easy one I think so I may throw that in 0.5 or 0.5.1. We should also start having a clearer TODO list maybe even with timelines (ouch) ? Any other idea, remarks, suggestions? I want 0.5 to come out soon so if suggestions are simple we can do that for 0.5 otherwise it has to wait. Cheers, Paul. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Gitstat-devel mailing list Git...@li... https://lists.sourceforge.net/lists/listinfo/gitstat-devel |
From: Paul V. <pau...@gm...> - 2008-03-04 07:47:18
|
Lee jungseung wrote: > Hi, Paul > > Nice arrangement for our TODO! > > I saw Greg KH's mail at kenreltrap.org, it contains some category like you > mentioned. > > Turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did: > lines added per day: 4945 > lines removed per day: 2006 > lines modified per day: 1702 > http://kerneltrap.org/Linux/Kernel_Rate_of_Change > > There has been no such statistics, so just like information (restrictive at > specific kernel version) are useful. I think both his and yours are > valuable. > > And.. Actually, we need clearer TODO list with timeline. > But it is not easy to make a plan and decision. ;-< > Let's talk about it later. > > Thanks, But even Linus has to do stuff by himself: http://lwn.net/Articles/270658/ Linux 2.6.25-rc3: 2.5% arch/h8300/ 13.9% arch/mips/configs/ 14.6% arch/mips/ 6.7% arch/powerpc/configs/ 7.5% arch/powerpc/ 2.5% arch/x86/ 6.1% arch/xtensa/kernel/ 6.2% arch/xtensa/ 37.0% arch/ 3.5% drivers/ata/ 6.0% drivers/hwmon/ 2.3% drivers/media/radio/ 6.1% drivers/media/video/ 9.0% drivers/media/ 3.1% drivers/net/ 13.0% drivers/scsi/ 5.1% drivers/watchdog/ 47.6% drivers/ 2.4% fs/ 2.9% include/asm-xtensa/ 5.1% include/ 2.0% net/ This is obviously something we already (more-or-less) have. Maybe that way of presenting is nicer? Cheers, Paul. |