You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(48) |
Oct
(7) |
Nov
(16) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(27) |
Feb
(4) |
Mar
(6) |
Apr
(9) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(1) |
2009 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
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. |
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-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-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-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: Paul V. <pau...@gm...> - 2008-02-14 09:21:10
|
Hi Lee, Can you explain the reasoning behind your changes in gitstat.pl. Is this to accommodate the 'no-user' version of gitstat that you mentioned (http://wilma.vub.ac.be/~se1_0708/Git-Statistics/) ? Cheers, Paul. |
From: Paul V. <pau...@gm...> - 2008-02-02 14:37:39
|
Lee jungseung wrote: > Hi, > > I modified some code related with time-zone (modified time() to gmtime()) > and committed it at sf.net. > Now, It looks like run well. > (Number of changesets (Day) and Number of changesets (Month)) > > > But there are another miss calculated statistics. > I have other kernel git-tree for gitstat testing. > > I made a graph and statistics for Top contributors (Kernel release v2.6.24) > > The results are... > > 56 David Woodhouse 41 (tree.celinuxforum.org) > 121 David Woodhouse 20 (my own gitstat) > > 16 Alan Cox 91 (tree.celinuxforum.org) > 14 Alan Cox 104 (my own gitstat) > > Of course, I am making up-to-date both gitstat. > > Our first mission for gitstat is that it should give accuracy statistics. > So, We should focus on that more than other issue. > Thanks, Hi Lee, I've setup a private kernel gitstat and see the same results as you do. We probably have to recreate the database on tree.celinuxforum.org. The tags on that site are also not correct. Remember that issue we had with the date of the tags? That was fixed but the database was never created again on that site. I agree a 100% with you that the statistics should be correct and that this should be our first goal. That's mainly the reason I'm working on moving all kind of calculations to one single place now. Once that is done we probably have to start comparing output from all kinds of different sources (including plain git commands) to the stuff we show on our pages. That doesn't prevent us from doing the minor tweaking to whatever we find though. Cheers, Paul. |
From: Lee j. <jun...@gm...> - 2008-02-01 11:33:39
|
Hi, I modified some code related with time-zone (modified time() to gmtime()) and committed it at sf.net. Now, It looks like run well. (Number of changesets (Day) and Number of changesets (Month)) But there are another miss calculated statistics. I have other kernel git-tree for gitstat testing. I made a graph and statistics for Top contributors (Kernel release v2.6.24) The results are... 56 David Woodhouse 41 (tree.celinuxforum.org) 121 David Woodhouse 20 (my own gitstat) 16 Alan Cox 91 (tree.celinuxforum.org) 14 Alan Cox 104 (my own gitstat) Of course, I am making up-to-date both gitstat. Our first mission for gitstat is that it should give accuracy statistics. So, We should focus on that more than other issue. Thanks, -----Original Message----- From: Paul Vriens [mailto:pau...@gm...] Sent: Friday, February 01, 2008 4:29 PM To: ??? Subject: Re: [Gitstat-devel] [gitstat-devel]Timezone problem Paul Vriens wrote: > Lee jungseung wrote: >> Hi, >> >> The gitstat use 'mktime()' for making time information. >> e.g. $cart_time_start=mktime(0,0,0,1,1,$_GET['chart_parameter2_year']); >> As you know, the $cart_time_start is something like '2008.1.1 '2008.12.31 >> (a kind of time standard?) >> >> According to server setting, Time zones are different. So, >> gitstat(using same git-tree) shows different statistics. >> >> In my opinion, We need to use same time standard. >> >> In case of using mktime(), How about to use gmmktime()? >> http://kr2.php.net/gmmktime >> With gmmmktime(), we could maintain some standard for making statistics. >> How about your opinion? >> >> Thanks, > > Hi Lee, > > I see you've started committing some of those timezone changes. You > accidentally reverted a change in index.php (moving stuff over to > libgather.php). Can you fix that? > > Cheers, > > Paul. > Hi, I also see that the current index.php (and chart.php) doesn't show the correct graph anymore for the 'commits per month'. When I go to http://tree.celinuxforum.org/gitstat/ I see that this graph end for Dec/07 where it should have been Jan/08. This wasn't the case before. Cheers, Paul. |
From: Paul V. <pau...@gm...> - 2008-01-30 09:38:16
|
Hi Lee, Lee jungseung wrote: > Hi, > > The gitstat use 'mktime()' for making time information. > e.g. $cart_time_start=mktime(0,0,0,1,1,$_GET['chart_parameter2_year']); > As you know, the $cart_time_start is something like '2008.1.1 '2008.12.31 > (a kind of time standard?) > > According to server setting, Time zones are different. > So, gitstat(using same git-tree) shows different statistics. > > In my opinion, We need to use same time standard. > > In case of using mktime(), How about to use gmmktime()? > http://kr2.php.net/gmmktime > With gmmmktime(), we could maintain some standard for making statistics. > How about your opinion? > > Thanks, > looks fine to me. I think it's definitely worth doing this. We also have some pieces of code that add a KST time. That has to be removed as well or changed to the current timezone of that server. Cheers, Paul. |
From: Lee j. <jun...@gm...> - 2008-01-30 09:06:03
|
Hi, The gitstat use 'mktime()' for making time information. e.g. $cart_time_start=mktime(0,0,0,1,1,$_GET['chart_parameter2_year']); As you know, the $cart_time_start is something like '2008.1.1 '2008.12.31 (a kind of time standard?) According to server setting, Time zones are different. So, gitstat(using same git-tree) shows different statistics. In my opinion, We need to use same time standard. In case of using mktime(), How about to use gmmktime()? http://kr2.php.net/gmmktime With gmmmktime(), we could maintain some standard for making statistics. How about your opinion? Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Wednesday, January 23, 2008 5:23 PM To: git...@li... Subject: Re: [Gitstat-devel] [gitstat-devel] Version numberfor theCVS version No problem. I will change the version in CVS to v0.4cvs (or something). I do think your remark about subversions is a good one. Next version will be v0.4.1 with everything up to now and the move of functions to libgather.php With subversions we should be able to release version much quicker. As said before I do like for us to go to 'git' as soon as possible. So when using subversions I think we have a few before v0.5 arrives and that one should be last from the CVS repository. Cheers, Paul. Lee jungseung wrote: > Oops, > Is that you said? > I misunderstand that you want to release new ver. > My English is fool. :-( > > I thought that new release was too early, so I mentioned sub-version. > To put a new version number into CVS is good choice. > > Thanks, > > -----Original Message----- > From: git...@li... [mailto:gitstat-devel- > bo...@li...] On Behalf Of Paul Vriens > Sent: Wednesday, January 23, 2008 4:10 PM > To: git...@li... > Subject: Re: [Gitstat-devel] [gitstat-devel] Version number for theCVS > version > > Hi, > > My intention was just to put a new version number into CVS without being > able to > download a full package of that version. > > What you are saying is to release a new version on sourceforge? > > Cheers, > > Paul. > > Lee jungseung wrote: >> Hi, >> >> How about to make subversion? >> For example 0.4.1 or 0.41 >> >> CVS v0.4 and live version on http://tree.celinuxforum.org/gitstat are >> different, exactly. and, It is needed that they could download latest >> version. >> >> In my opinion, It is good to release gitstat sub-version with your new >> include patch. >> >> Thanks, >> -----Original Message----- >> From: git...@li... [mailto:gitstat-devel- >> bo...@li...] On Behalf Of Paul Vriens >> Sent: Wednesday, January 23, 2008 4:50 AM >> To: git...@li... >> Subject: [Gitstat-devel] [gitstat-devel] Version number for the CVS > version >> Hi, >> >> As we are running a more-or-less live CVS version on >> http://tree.celinuxforum.org/gitstat/ people could be fooled by the >> 'Powered by gitstat v0.4'. They could think this is the version they >> downloaded. >> >> (On a side-note the downloads have started to increase). >> >> Maybe we should have a version number in CVS like v0.4CVS which turns >> into v0.5 once that is released. >> >> Remarks, ideas? >> >> 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 >> >> >> ------------------------------------------------------------------------- >> 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 >> > > > ------------------------------------------------------------------------- > 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 > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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: Lee j. <jun...@gm...> - 2008-01-29 08:26:38
|
Hi, I made local git-repository for gitstat, and tested gitstat for supporting CVS. But on the git-repository imported from CVS, couldn't run git-pull (it's not clone). How about this scenario for easy supporting CVS? 1. make git tree(cvs imported) cd /home/gitstat mkdir gstat_git_cvsimport cd gstat_git_cvsimport git-cvsimport -p x -v - d:pserver:ano...@gi...:/cvsroot/gitstat gitstat 2. make clone cd /home/gitstat git clone -l gstat_git_cvsimport/ gstat_git/ 3. If new changes are commited(and It should be added ./gstat_pl/gitstat.sh) cd /home/gitstat/gstat_git_cvsimport git-cvsimport -p x -v - d:pserver:ano...@gi...:/cvsroot/gitstat gitstat cd ../gstat_git/ git pull And the remainders are similar to gitstat way. Thanks, -----Original Message----- From: Lee jungseung [mailto:jun...@gm...] Sent: Friday, January 25, 2008 9:55 AM To: 'git...@li...' Subject: [gitstat-devel]Supporting CVS Hi, I heard that some guys want to use gitstat for CVS as well as git. There are many projects using CVS, and they want to receive E-mail reporting and search for their project easily, too. Supporting CVS feature makes gitstat more generally. It wouldn't be difficult stuff, As like your local git-repository for gitstat, using git-cvsimport and just using gitstat. But there are some configuration and installation issue, so It should be included in installation page and gitstat.pl. How about your opinion? Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Wednesday, January 23, 2008 5:23 PM To: git...@li... Subject: Re: [Gitstat-devel] [gitstat-devel] Version numberfor theCVS version No problem. I will change the version in CVS to v0.4cvs (or something). I do think your remark about subversions is a good one. Next version will be v0.4.1 with everything up to now and the move of functions to libgather.php With subversions we should be able to release version much quicker. As said before I do like for us to go to 'git' as soon as possible. So when using subversions I think we have a few before v0.5 arrives and that one should be last from the CVS repository. Cheers, Paul. Lee jungseung wrote: > Oops, > Is that you said? > I misunderstand that you want to release new ver. > My English is fool. :-( > > I thought that new release was too early, so I mentioned sub-version. > To put a new version number into CVS is good choice. > > Thanks, > > -----Original Message----- > From: git...@li... [mailto:gitstat-devel- > bo...@li...] On Behalf Of Paul Vriens > Sent: Wednesday, January 23, 2008 4:10 PM > To: git...@li... > Subject: Re: [Gitstat-devel] [gitstat-devel] Version number for theCVS > version > > Hi, > > My intention was just to put a new version number into CVS without being > able to > download a full package of that version. > > What you are saying is to release a new version on sourceforge? > > Cheers, > > Paul. > > Lee jungseung wrote: >> Hi, >> >> How about to make subversion? >> For example 0.4.1 or 0.41 >> >> CVS v0.4 and live version on http://tree.celinuxforum.org/gitstat are >> different, exactly. and, It is needed that they could download latest >> version. >> >> In my opinion, It is good to release gitstat sub-version with your new >> include patch. >> >> Thanks, >> -----Original Message----- >> From: git...@li... [mailto:gitstat-devel- >> bo...@li...] On Behalf Of Paul Vriens >> Sent: Wednesday, January 23, 2008 4:50 AM >> To: git...@li... >> Subject: [Gitstat-devel] [gitstat-devel] Version number for the CVS > version >> Hi, >> >> As we are running a more-or-less live CVS version on >> http://tree.celinuxforum.org/gitstat/ people could be fooled by the >> 'Powered by gitstat v0.4'. They could think this is the version they >> downloaded. >> >> (On a side-note the downloads have started to increase). >> >> Maybe we should have a version number in CVS like v0.4CVS which turns >> into v0.5 once that is released. >> >> Remarks, ideas? >> >> 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 >> >> >> ------------------------------------------------------------------------- >> 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 >> > > > ------------------------------------------------------------------------- > 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 > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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-01-25 06:52:13
|
Hi, Lee jungseung wrote: > Hi, > > I heard that some guys want to use gitstat for CVS as well as git. > There are many projects using CVS, and they want to receive E-mail > reporting and search for their project easily, too. > Supporting CVS feature makes gitstat more generally. We can hardly call it gitstat then ;-). > > It wouldn't be difficult stuff, > As like your local git-repository for gitstat, using git-cvsimport and just > using gitstat. That's certainly possible I guess but the interface (web) and the email will all be in a git-based format. Not sure if CVS people want that. We could always give it a try and see how it works out. We can even use our own gitstat as a testbed. This is however not something I'm going to work on soon, so let us put this at least on the TODO list. > But there are some configuration and installation issue, so It should be > included in installation page and gitstat.pl. > > How about your opinion? > > Thanks, > Cheers, Paul. |
From: Lee j. <jun...@gm...> - 2008-01-25 00:54:57
|
Hi, I heard that some guys want to use gitstat for CVS as well as git. There are many projects using CVS, and they want to receive E-mail reporting and search for their project easily, too. Supporting CVS feature makes gitstat more generally. It wouldn't be difficult stuff, As like your local git-repository for gitstat, using git-cvsimport and just using gitstat. But there are some configuration and installation issue, so It should be included in installation page and gitstat.pl. How about your opinion? Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Wednesday, January 23, 2008 5:23 PM To: git...@li... Subject: Re: [Gitstat-devel] [gitstat-devel] Version numberfor theCVS version No problem. I will change the version in CVS to v0.4cvs (or something). I do think your remark about subversions is a good one. Next version will be v0.4.1 with everything up to now and the move of functions to libgather.php With subversions we should be able to release version much quicker. As said before I do like for us to go to 'git' as soon as possible. So when using subversions I think we have a few before v0.5 arrives and that one should be last from the CVS repository. Cheers, Paul. Lee jungseung wrote: > Oops, > Is that you said? > I misunderstand that you want to release new ver. > My English is fool. :-( > > I thought that new release was too early, so I mentioned sub-version. > To put a new version number into CVS is good choice. > > Thanks, > > -----Original Message----- > From: git...@li... [mailto:gitstat-devel- > bo...@li...] On Behalf Of Paul Vriens > Sent: Wednesday, January 23, 2008 4:10 PM > To: git...@li... > Subject: Re: [Gitstat-devel] [gitstat-devel] Version number for theCVS > version > > Hi, > > My intention was just to put a new version number into CVS without being > able to > download a full package of that version. > > What you are saying is to release a new version on sourceforge? > > Cheers, > > Paul. > > Lee jungseung wrote: >> Hi, >> >> How about to make subversion? >> For example 0.4.1 or 0.41 >> >> CVS v0.4 and live version on http://tree.celinuxforum.org/gitstat are >> different, exactly. and, It is needed that they could download latest >> version. >> >> In my opinion, It is good to release gitstat sub-version with your new >> include patch. >> >> Thanks, >> -----Original Message----- >> From: git...@li... [mailto:gitstat-devel- >> bo...@li...] On Behalf Of Paul Vriens >> Sent: Wednesday, January 23, 2008 4:50 AM >> To: git...@li... >> Subject: [Gitstat-devel] [gitstat-devel] Version number for the CVS > version >> Hi, >> >> As we are running a more-or-less live CVS version on >> http://tree.celinuxforum.org/gitstat/ people could be fooled by the >> 'Powered by gitstat v0.4'. They could think this is the version they >> downloaded. >> >> (On a side-note the downloads have started to increase). >> >> Maybe we should have a version number in CVS like v0.4CVS which turns >> into v0.5 once that is released. >> >> Remarks, ideas? >> >> 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 >> >> >> ------------------------------------------------------------------------- >> 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 >> > > > ------------------------------------------------------------------------- > 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 > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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-01-23 08:22:38
|
No problem. I will change the version in CVS to v0.4cvs (or something). I do think your remark about subversions is a good one. Next version will be v0.4.1 with everything up to now and the move of functions to libgather.php With subversions we should be able to release version much quicker. As said before I do like for us to go to 'git' as soon as possible. So when using subversions I think we have a few before v0.5 arrives and that one should be last from the CVS repository. Cheers, Paul. Lee jungseung wrote: > Oops, > Is that you said? > I misunderstand that you want to release new ver. > My English is fool. :-( > > I thought that new release was too early, so I mentioned sub-version. > To put a new version number into CVS is good choice. > > Thanks, > > -----Original Message----- > From: git...@li... [mailto:gitstat-devel- > bo...@li...] On Behalf Of Paul Vriens > Sent: Wednesday, January 23, 2008 4:10 PM > To: git...@li... > Subject: Re: [Gitstat-devel] [gitstat-devel] Version number for theCVS > version > > Hi, > > My intention was just to put a new version number into CVS without being > able to > download a full package of that version. > > What you are saying is to release a new version on sourceforge? > > Cheers, > > Paul. > > Lee jungseung wrote: >> Hi, >> >> How about to make subversion? >> For example 0.4.1 or 0.41 >> >> CVS v0.4 and live version on http://tree.celinuxforum.org/gitstat are >> different, exactly. and, It is needed that they could download latest >> version. >> >> In my opinion, It is good to release gitstat sub-version with your new >> include patch. >> >> Thanks, >> -----Original Message----- >> From: git...@li... [mailto:gitstat-devel- >> bo...@li...] On Behalf Of Paul Vriens >> Sent: Wednesday, January 23, 2008 4:50 AM >> To: git...@li... >> Subject: [Gitstat-devel] [gitstat-devel] Version number for the CVS > version >> Hi, >> >> As we are running a more-or-less live CVS version on >> http://tree.celinuxforum.org/gitstat/ people could be fooled by the >> 'Powered by gitstat v0.4'. They could think this is the version they >> downloaded. >> >> (On a side-note the downloads have started to increase). >> >> Maybe we should have a version number in CVS like v0.4CVS which turns >> into v0.5 once that is released. >> >> Remarks, ideas? >> >> 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 >> >> >> ------------------------------------------------------------------------- >> 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 >> > > > ------------------------------------------------------------------------- > 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 > > > ------------------------------------------------------------------------- > 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: Lee j. <jun...@gm...> - 2008-01-23 07:21:23
|
Oops, Is that you said? I misunderstand that you want to release new ver. My English is fool. :-( I thought that new release was too early, so I mentioned sub-version. To put a new version number into CVS is good choice. Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Wednesday, January 23, 2008 4:10 PM To: git...@li... Subject: Re: [Gitstat-devel] [gitstat-devel] Version number for theCVS version Hi, My intention was just to put a new version number into CVS without being able to download a full package of that version. What you are saying is to release a new version on sourceforge? Cheers, Paul. Lee jungseung wrote: > Hi, > > How about to make subversion? > For example 0.4.1 or 0.41 > > CVS v0.4 and live version on http://tree.celinuxforum.org/gitstat are > different, exactly. and, It is needed that they could download latest > version. > > In my opinion, It is good to release gitstat sub-version with your new > include patch. > > Thanks, > -----Original Message----- > From: git...@li... [mailto:gitstat-devel- > bo...@li...] On Behalf Of Paul Vriens > Sent: Wednesday, January 23, 2008 4:50 AM > To: git...@li... > Subject: [Gitstat-devel] [gitstat-devel] Version number for the CVS version > > Hi, > > As we are running a more-or-less live CVS version on > http://tree.celinuxforum.org/gitstat/ people could be fooled by the > 'Powered by gitstat v0.4'. They could think this is the version they > downloaded. > > (On a side-note the downloads have started to increase). > > Maybe we should have a version number in CVS like v0.4CVS which turns > into v0.5 once that is released. > > Remarks, ideas? > > 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 > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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-01-23 07:10:07
|
Hi, My intention was just to put a new version number into CVS without being able to download a full package of that version. What you are saying is to release a new version on sourceforge? Cheers, Paul. Lee jungseung wrote: > Hi, > > How about to make subversion? > For example 0.4.1 or 0.41 > > CVS v0.4 and live version on http://tree.celinuxforum.org/gitstat are > different, exactly. and, It is needed that they could download latest > version. > > In my opinion, It is good to release gitstat sub-version with your new > include patch. > > Thanks, > -----Original Message----- > From: git...@li... [mailto:gitstat-devel- > bo...@li...] On Behalf Of Paul Vriens > Sent: Wednesday, January 23, 2008 4:50 AM > To: git...@li... > Subject: [Gitstat-devel] [gitstat-devel] Version number for the CVS version > > Hi, > > As we are running a more-or-less live CVS version on > http://tree.celinuxforum.org/gitstat/ people could be fooled by the > 'Powered by gitstat v0.4'. They could think this is the version they > downloaded. > > (On a side-note the downloads have started to increase). > > Maybe we should have a version number in CVS like v0.4CVS which turns > into v0.5 once that is released. > > Remarks, ideas? > > 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 > > > ------------------------------------------------------------------------- > 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: Lee j. <jun...@gm...> - 2008-01-23 00:09:41
|
Hi, Your patches are simple and make our code more beautiful. go ahead :) Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Wednesday, January 23, 2008 4:45 AM To: git...@li... Subject: [Gitstat-devel] [gitstat-devel] Start of new include file Hi, Before committing these new changes I thought of just throwing them in here to get some feedback (if any). I've created a new include/libgather.php (attached). This will be used (for now) by both chart.php and index.php as they both contain almost the same pieces of code. I've also attached the diff's for both mentioned files. All data gathering stuff will be moved to libbgather.php. Once that is done we have at least cleaned up some of the main pages. The idea is to remove all MySQL specific stuff from the main pages and put this in include files. Once that's done we can start thinking of introducing other means of storing/gathering information (i.e. SQLite or direct git access without any DB kind of thing). Silence will be taken as 'go ahead' :-). Cheers, Paul. |
From: Lee j. <jun...@gm...> - 2008-01-23 00:05:48
|
Hi, How about to make subversion? For example 0.4.1 or 0.41 CVS v0.4 and live version on http://tree.celinuxforum.org/gitstat are different, exactly. and, It is needed that they could download latest version. In my opinion, It is good to release gitstat sub-version with your new include patch. Thanks, -----Original Message----- From: git...@li... [mailto:gitstat-devel- bo...@li...] On Behalf Of Paul Vriens Sent: Wednesday, January 23, 2008 4:50 AM To: git...@li... Subject: [Gitstat-devel] [gitstat-devel] Version number for the CVS version Hi, As we are running a more-or-less live CVS version on http://tree.celinuxforum.org/gitstat/ people could be fooled by the 'Powered by gitstat v0.4'. They could think this is the version they downloaded. (On a side-note the downloads have started to increase). Maybe we should have a version number in CVS like v0.4CVS which turns into v0.5 once that is released. Remarks, ideas? 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-01-22 19:50:30
|
Hi, As we are running a more-or-less live CVS version on http://tree.celinuxforum.org/gitstat/ people could be fooled by the 'Powered by gitstat v0.4'. They could think this is the version they downloaded. (On a side-note the downloads have started to increase). Maybe we should have a version number in CVS like v0.4CVS which turns into v0.5 once that is released. Remarks, ideas? Cheers, Paul. |
From: Paul V. <pau...@gm...> - 2008-01-22 19:45:23
|
Hi, Before committing these new changes I thought of just throwing them in here to get some feedback (if any). I've created a new include/libgather.php (attached). This will be used (for now) by both chart.php and index.php as they both contain almost the same pieces of code. I've also attached the diff's for both mentioned files. All data gathering stuff will be moved to libbgather.php. Once that is done we have at least cleaned up some of the main pages. The idea is to remove all MySQL specific stuff from the main pages and put this in include files. Once that's done we can start thinking of introducing other means of storing/gathering information (i.e. SQLite or direct git access without any DB kind of thing). Silence will be taken as 'go ahead' :-). Cheers, Paul. |
From: Paul V. <pau...@gm...> - 2008-01-14 19:03:21
|
Hi, Does anybody have a nice logo lying around or finds himself/herself to be the artist he/she never knew he/she was? Cheers, Paul. |
From: Paul V. <pau...@gm...> - 2008-01-14 07:00:10
|
Hi, 이정승 wrote: > Hi, > > I applied Paul's patch on CELF server. > It looks pretty good. but, I modified it a bit. > $GSTAT[GIT_TREE_DESC] has long words, generally. so it is too long to > use on title. > In my opinion, title name 'Git statistics + $GSTAT[GIT_PROJECT_NAME]' > would it be ok. > How do u think about it? Yes, that looks better. While testing I also had "Linus' kernel tree" in there and it introduced some line wrapping. The html/css code does take care of that but I think your solution is better although I would add the "2.6" to it. As said before, we probably need a config page (for the administrator) to be able to added these kind of fields. It's much easier to work with (I think) and we are able to introduce some checking (lengths of strings and such) immediately. > > and, I ran Installation page. > It is easy to make DB and DB schema. and It gave many informaton to > gitstat administrator. > If it is written all, It would be helpfulness. > The main difference is of course that you now need a gstat_rw/config directory that's owned by the account that runs the webserver. I don't think that's an issue. > Thanks, > Two other things about the references to gitstat: 1. The grey 'Monitor gitstat' (above the join link). We should probably turn this into "Monitor $GSTAT[GIT_PROJECT_NAME]" or get rid off it. 2. The text "What is Gitstat". This should be replaced by a small piece of information related to the project, not gitstat. The only pages that should reference gitstat a lot would be a gitstat page for gitstat itself :-). And on a side-note, any reason you didn't apply the latest header.php and include/lib.php changes? I changed the cut_str function to do an exact cutoff and introduced some links for cut off strings when you hover over them (subject and author in the changelog). The current page on the CELF server shows the reason I've changed it (look for example at the author "Jeremy Kerr .j.. I must say that we still have an issue with the top author per release. I'm still working on that (slowly). I have a feeling that it's either a git-issue or the way we read/store some of the entries. It's not the calculation. Cheers, Paul. |
From: <jun...@gm...> - 2008-01-14 01:21:18
|
SGksCgpJIGFwcGxpZWQgUGF1bCdzIHBhdGNoIG9uIENFTEYgc2VydmVyLgpJdCBsb29rcyBwcmV0 dHkgZ29vZC4gYnV0LCBJIG1vZGlmaWVkIGl0IGEgYml0LgokR1NUQVRbR0lUX1RSRUVfREVTQ10g aGFzIGxvbmcgd29yZHMsIGdlbmVyYWxseS4gc28gaXQgaXMgdG9vIGxvbmcgdG8KdXNlIG9uIHRp dGxlLgpJbiBteSBvcGluaW9uLCB0aXRsZSBuYW1lICdHaXQgc3RhdGlzdGljcyArICRHU1RBVFtH SVRfUFJPSkVDVF9OQU1FXScKd291bGQgaXQgYmUgb2suCkhvdyBkbyB1IHRoaW5rIGFib3V0IGl0 PwoKYW5kLCBJIHJhbiBJbnN0YWxsYXRpb24gcGFnZS4KSXQgaXMgZWFzeSB0byBtYWtlIERCIGFu ZCBEQiBzY2hlbWEuIGFuZCBJdCBnYXZlIG1hbnkgaW5mb3JtYXRvbiB0bwpnaXRzdGF0IGFkbWlu aXN0cmF0b3IuCklmIGl0IGlzIHdyaXR0ZW4gYWxsLCBJdCB3b3VsZCBiZSBoZWxwZnVsbmVzcy4K ClRoYW5rcywKCk9uIEphbiAxMywgMjAwOCA0OjM3IEFNLCBQYXVsIFZyaWVucyA8cGF1bC52cmll bnMuZ2l0c3RhdEBnbWFpbC5jb20+IHdyb3RlOgo+IEhpLAo+Cj4g7J207KCV7Iq5IHdyb3RlOgo+ ID4gSGksCj4gPgo+ID4gSSBzYXcgYXR0YXRjaGVkIHNjcmVlbnNob3QuCj4gPiBJdCBsb29rcyBn b29kIGFuZCBpdCBtYWtlcyBnaXRzdGF0IGhhdmUgYSBwb2ludCBvZiBkaWZmZXJuZWNlIGxvb2tz Cj4gPiB3aXRoIG90aGVyIGdpdHN0YXQuCj4gPiBHb29kIGpvYiwgY29tbWl0IGl0IHBsZWFzZS4K Pgo+IENoYW5nZXMgYXJlIGNvbW1pdHRlZC4gVGhlIGNoYW5nZWQgZmlsZXMgYXJlIChmb3IgYWxs IG9mIHRoZSBjaGFuZ2VzIEkKPiBkaWQgdG8gdGhlIHBhZ2VzIHJlY2VudGx5KToKPgo+IGhlYWRl ci5waHAKPiBmb290ZXIucGhwCj4gaW1hZ2VzL3N0eWxlLmNzcwo+IGltYWdlcy9oZWFkZXIuZ2lm Cj4KPiBJdCdzIHN0aWxsIG5vdCBwZXJmZWN0IHlldCBhbmQgc2hvdWxkIHVzZSBhIGJpdCBtb3Jl IGNzcyBhcyBzYWlkLiBBbHNvCj4gYmVjYXVzZSB0aGVtaW5nIGlzIG9uIHRoZSBUT0RPIGxpc3Qu Cj4KPiA+Cj4gPiBJZiB5b3UgYXJlIHdvcmtpbmcgb24gSW5zdGFsbGF0aW9uIHBhZ2UsIEkgaGF2 ZSBzb21lIHN1Z2dlc3Rpb24uCj4gPiB0aGF0IGlzIGFkZGluZyBzb21lIGZ1bmN0aW9uLgo+ID4K PiA+IC0gQ2hlY2tpbmcgREIgc2V0dGluZyBhbmQgbGlua2FnZSB0ZXN0KG15c3FsICsgcGVybCkg b24gSW5zdGFsbGF0aW9uIHBhZ2UuCj4KPiBUaGUgcGFnZSBJJ20gd29ya2luZyBvbiAoYXR0YWNo ZWQpIGFsc28gaW5jbHVkZSBzb21lIHRlc3RzLgo+Cj4gPgo+ID4gSW4gbXkgb3BpbmlvbiwgSXQg d291bGQgYmUgaGVscCBwZW9wbGUgd2hvIHRyeSB0byBpbnN0YWxsLgo+ID4gaG93IGFib3V0IHRo YXQ/Cj4gPgo+ID4gVGhhbmtzLAo+Cj4gQ2hlZXJzLAo+Cj4gUGF1bC4KPgo+Cg== |
From: Paul V. <pau...@gm...> - 2008-01-12 19:38:05
|
Hi, 이정승 wrote: > Hi, > > I saw attatched screenshot. > It looks good and it makes gitstat have a point of differnece looks > with other gitstat. > Good job, commit it please. Changes are committed. The changed files are (for all of the changes I did to the pages recently): header.php footer.php images/style.css images/header.gif It's still not perfect yet and should use a bit more css as said. Also because theming is on the TODO list. > > If you are working on Installation page, I have some suggestion. > that is adding some function. > > - Checking DB setting and linkage test(mysql + perl) on Installation page. The page I'm working on (attached) also include some tests. > > In my opinion, It would be help people who try to install. > how about that? > > Thanks, Cheers, Paul. |
From: <jun...@gm...> - 2008-01-11 00:42:58
|
SGksCgpJIHNhdyBhdHRhdGNoZWQgc2NyZWVuc2hvdC4KSXQgbG9va3MgZ29vZCBhbmQgaXQgbWFr ZXMgZ2l0c3RhdCBoYXZlIGEgcG9pbnQgb2YgZGlmZmVybmVjZSBsb29rcwp3aXRoIG90aGVyIGdp dHN0YXQuCkdvb2Qgam9iLCBjb21taXQgaXQgcGxlYXNlLgoKSWYgeW91IGFyZSB3b3JraW5nIG9u IEluc3RhbGxhdGlvbiBwYWdlLCBJIGhhdmUgc29tZSBzdWdnZXN0aW9uLgp0aGF0IGlzIGFkZGlu ZyBzb21lIGZ1bmN0aW9uLgoKLSBDaGVja2luZyBEQiBzZXR0aW5nIGFuZCBsaW5rYWdlIHRlc3Qo bXlzcWwgKyBwZXJsKSBvbiBJbnN0YWxsYXRpb24gcGFnZS4KCkluIG15IG9waW5pb24sIEl0IHdv dWxkIGJlIGhlbHAgcGVvcGxlIHdobyB0cnkgdG8gaW5zdGFsbC4KaG93IGFib3V0IHRoYXQ/CgpU aGFua3MsCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQou L3Rlc3QucGVybC5teXNxbC5wbAoKREJJIGNvbm5lY3QoJ2hvc3RuYW1lPWxvY2FsaG9zdDtwb3J0 PTMzMDY7ZHNuPWRiaTpnaXRzdGF0X2tlcm5lbCcsJ2dpdHN0YXRfa2VybmVsJywuLi4pCmZhaWxl ZDogQ2FuJ3QgY29ubmVjdCB0byBsb2NhbCBNeVNRTCBzZXJ2ZXIgdGhyb3VnaCBzb2NrZXQKJy92 YXIvbGliL215c3FsL215c3FsLnNvY2snICgyKSBhdCAuL3Rlc3QucGVybC5teXNxbC5wbCBsaW5l IDkKCkNhbid0IGNhbGwgbWV0aG9kICJkbyIgb24gYW4gdW5kZWZpbmVkIHZhbHVlIGF0IC4vdGVz dC5wZXJsLm15c3FsLnBsIGxpbmUgMTAuCgpbcm9vdEBMaW1HZXVuU2lrIGdzdGF0X3BsXSMKClty b290QExpbUdldW5TaWsgZ3N0YXRfcGxdIyBjYXQgLi90ZXN0LnBlcmwubXlzcWwucGwKCiMhIC91 c3IvYmluL3BlcmwKCnVzZSBEQkk7CgpteSAkaG9zdCA9J2xvY2FsaG9zdCc7CgpteSAkcG9ydCA9 ICczMzA2JzsKCm15ICRkc24gPSAnZGJpOmdpdHN0YXRfa2VybmVsJzsKCm15ICR1c2VyID0gJ2dp dHN0YXRfa2VybmVsJzsKCm15ICRwYXNzID0gJ2dpdHN0YXRfa2VybmVscGFzcyc7CgoKCm15ICRk Ymg9REJJLT5jb25uZWN0KCJkYmk6bXlzcWw6aG9zdG5hbWU9JGhvc3Q7cG9ydD0kcG9ydDtkc249 JGRzbiIsJHVzZXIsJHBhc3MpOwoKJGRiaC0+ZG8oIklOU0VSVCBJTlRPIFBPUFMgKGhvc3RuYW1l KSBWQUxVRVMgKCdoYWhhaGFoYScpIik7CgokZGJoLT5kaXNjb25uZWN0OwotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKT24gMS8x MS8wOCwgUGF1bCBWcmllbnMgPHBhdWwudnJpZW5zLmdpdHN0YXRAZ21haWwuY29tPiB3cm90ZToK PiBIaSwKPgo+IOydtOygleyKuSB3cm90ZToKPiA+IFRob3VnaCB0aGV5IGFyZSBvdGhlciBnaXRz dGF0IGZvciBvdGhlciBnaXQtdHJlZSwKPiA+IHRoZXkgaGF2ZSBzYW1lIGV4dGVybmVscy4gYW5k IEl0IG1ha2VzIHVzIGNvbmZ1c2UuCj4gPiBCZWNhdXNlIG9mIHRoYXQgcmVhc29uLCBJIGFkZGVk IHN1Yi10aXRsZSBhcyBleHBlZGllbnQuCj4gPgo+ID4gQnV0LCB5b3VyIElkZWEgaXMgYmV0dGVy IHRoYW4gbXkgZXhwZWRpZW50IGZ1bmRtZW50YWxseS4KPiA+IEFzIGV4cGVjdGVkLCAgSW4gbW9z dCBjYXNlICx1bmNvbWZvcnRhYmxlbmVzcyB0byBtZSBpcyB1bmNvbWZvciB0bwo+ID4gb3RoZXJz LHRvby4gOikKPiA+IElmIHlvdSBoYXZlIGdvb2Qgd29yZCAobGlrZSBhcyB5b3UgbWVudGlvbmVk KSBhYm91dCB0aGF0LCBjb21taXQgaXQgcGx6Lgo+ID4KPiBMZXQgbWUga25vdyB3aGF0IHlvdSB0 aGluayBvZiB0aGUgYXR0YWNoZWQgc2NyZWVuc2hvdCBvZiB0aGUgaGVhZGVyLiBJZgo+IHlvdSBs aWtlIGl0IEkgd2lsbCBjb21taXQgdGhvc2UgY2hhbmdlcy4gKFRoZSAiR2l0IHN0YXRpc3RpY3Mg Zm9yIFdpbmUiCj4gaXMgYmx1ZSBiZWNhdXNlIEkgaG92ZXJlZCBvdmVyIGl0IHdoaWxlIGNyZWF0 aW5nIHRoZSBzY3JlZW5zaG90KS4KPgo+IFRoZSBjb2RlIGNvdWxkIGJlIGEgYml0IGNsZWFuZXIg KG1vcmUgY3NzKSBidXQgeW91IHdpbGwgZ2V0IG15IGRyaWZ0LiBXZQo+IGNhbiBhbHdheXMgd29y ayBmcm9tIHRoZXJlLgo+Cj4gQnR3IEkgYWxzbyB0aGluayB0aGF0IHRoZSAiTW9uaXRvciBnaXRz dGF0IiwganVzdCBhYm92ZSB0aGUgIkpvaW4iIGxpbmsKPiBzaG91bGQgYmUgY2hhbmdlZCBpbnRv ICJNb25pdG9yIDxwcm9qZWN0PiIuCj4KPiBPbmUgb2YgdGhlIHRoaW5ncyB3ZSBzaG91bGQgcHJv YmFibGUgaGF2ZSBpcyBzaG9ydCBhbmQgYSBsb25nCj4gZGVzY3JpcHRpb24gb2YgdGhlIHByb2pl Y3QuIEFzIHNhaWQsIHRoZSBpZGVhIGlzIHRvIGhhdmUgdGhlIGNvbmZpZwo+IHNldHRpbmdzIG9u IHRoZSBhZG1pbiBwYWdlIHNvIHdlIGNhbiBpbmZsdWVuY2UgdGhlIG1heGltdW0gc2l6ZSBvZiB0 aGUKPiBsb25nL3Nob3J0IGRlc2NyaXB0aW9uLgo+Cj4gQ2hlZXJzLAo+Cj4gUGF1bC4KPgo+Cg== |