Menu
▾
▴
gitstat-devel — for developers
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...> - 2007-09-09 13:33:39
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-09 13:29:46
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-08 16:36:51
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-08 16:05:42
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-08 13:57:31
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-08 13:56:35
|
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. |
|
From: Soon-Son Kwon(Shawn) <ks...@kl...> - 2007-09-08 13:49:04
|
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 |
|
From: Soon-Son Kwon(Shawn) <ks...@kl...> - 2007-09-08 13:47:29
|
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 |
|
From: Paul V. <pau...@gm...> - 2007-09-08 13:27:17
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-07 11:40:38
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-07 11:03:46
|
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. |
|
From: Paul V. <pau...@gm...> - 2007-09-07 05:55:07
|
??? wrote: >> `Top contributor's domain' still looks at the domain of the committer, not > at the domain of the author (cfr. `git show --pretty=raw'). >> Hence domains of people who email patches are not taken into account. >> >> This is a significant number: for v2.6.22, there were 6840 commits. >> Of these only 1258 changes were committed into a git tree by their author. >> The other 5582 changes (+80%) end up with an incorrect contributor's >> domain. >> >> And that's why it looks like Linus did 23% of the work for 2.6.22 himself >> :-) >> >> Is there any chance you can fix this? Thanks! > > I received above mail. > I took a mistake in code of gitstat that chart of contributor's domain > shows commiter's not author's. > I modified this problem right now, and applied to > tree.celinuxform.org/gitstat and CVS. > > btw, I found Paul's commit in CVS. > We had a some bugs in gitstat that show the number of commits per day > incorrectly > With Paul's, the numbers of commit shows right one,precisely. Good job! > > Thanks, > > ------------------------------------------------------------------------- > 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 > It looks like we're getting a bit more attention! I've changed index.php btw as we don't use prevperiod and/or setybase there. Cheers, Paul. |
|
From: <jun...@gm...> - 2007-09-07 03:24:40
|
>`Top contributor's domain' still looks at the domain of the committer, not at the domain of the author (cfr. `git show --pretty=raw'). >Hence domains of people who email patches are not taken into account. > >This is a significant number: for v2.6.22, there were 6840 commits. >Of these only 1258 changes were committed into a git tree by their author. >The other 5582 changes (+80%) end up with an incorrect contributor's >domain. > >And that's why it looks like Linus did 23% of the work for 2.6.22 himself >:-) > >Is there any chance you can fix this? Thanks! I received above mail. I took a mistake in code of gitstat that chart of contributor's domain shows commiter's not author's. I modified this problem right now, and applied to tree.celinuxform.org/gitstat and CVS. btw, I found Paul's commit in CVS. We had a some bugs in gitstat that show the number of commits per day incorrectly With Paul's, the numbers of commit shows right one,precisely. Good job! Thanks, |
|
From: Paul V. <pau...@gm...> - 2007-09-05 08:48:42
|
Soon-Son Kwon(Shawn) wrote: > 2007/9/5, Paul Vriens <pau...@gm...>: >> Soon-Son Kwon(Shawn) wrote: >>> 2007/9/5, Paul Vriens <pau...@gm...>: >>>> Soon-Son Kwon(Shawn) wrote: >>>>> Hi Paul, >>>>> Jeongseong and I decided to give you CVS write access. >>>>> Now you may commit to CVS at your own will. >>>>> Feel free to add / modify gitstat. >>>>> We think that will speed up the development. :-) >>>>> >>>>> Thanks very much. >>>> Hi, >>>> >>>> Thanks for the confidence. I will make sure that I test everything on at least >>>> the kernel-git and Wine-git. If possible I'll add some other projects that use >>>> git to my testing suite. I think it's the best way to guarantee that changes are >>>> correct. >>>> >>>> I can't tell you the amount of time I can spent on this project as I do have a >>>> day job. >>> We decided to give you full access to the project >>> by giving you admin role. Now you can see that you >>> can do anything with the project. >>> >>> We also have daily job and within a few weeks we >>> are unable to contribute very much due to reorganization....etc. >>> >>> So we want to request you to accept our offer to be >>> project admin and keep evolving gitstat in the future. >>> Of course this does not mean that we will leave completely. >>> But it is evident that we cannot focus on it very much in the future. >>> >>> Jeongseong and I are very happy to find someone we can trust who can keep >>> working on it and hope you will be that person whom we were looking for. >>> >>> Our rough roadmap is written at revised TODO file >>> and we hope that dream can come true with you. :-) >>> >>> Thanks very much. >> Hi, >> >> Thanks again for the offer. I don't have an issue becoming one of the project >> admins (and I really mean 'one of'). I think I have more or less the same time >> constraints with respect to this project as you do and my primary focus (when >> doing open source stuff) will be Wine. >> >> I thought this was a nice small project which I'm able and willing to contribute >> (it will also extend my skills in MySQL and php). I can't however take over more >> responsibility than just being another admin/developer for this project. >> >> Hope to not disappoint you too much, >> >> Paul > > Thanks for your understanding. > I understand your point and we will remain > as one of the admin too. :-) > > Giving you admin role does not mean you > take the whole responsibility but showing > that we are okay with your activity without > our permission(?). You do not need to ask > before you do something...because I think the > current gitstat has not much or no possibility for > design/implementation conflict within us. > > Thanks again. Ok, from your previous email I had the feeling you were stepping back severely from the project. Good to hear it's not the case :-). Btw. Just did my first commit, hurray!!! Cheers, Paul. |
|
From: Soon-Son Kwon(Shawn) <ks...@kl...> - 2007-09-05 08:06:13
|
2007/9/5, Paul Vriens <pau...@gm...>: > Soon-Son Kwon(Shawn) wrote: > > 2007/9/5, Paul Vriens <pau...@gm...>: > >> Soon-Son Kwon(Shawn) wrote: > >>> Hi Paul, > >>> Jeongseong and I decided to give you CVS write access. > >>> Now you may commit to CVS at your own will. > >>> Feel free to add / modify gitstat. > >>> We think that will speed up the development. :-) > >>> > >>> Thanks very much. > >> Hi, > >> > >> Thanks for the confidence. I will make sure that I test everything on at least > >> the kernel-git and Wine-git. If possible I'll add some other projects that use > >> git to my testing suite. I think it's the best way to guarantee that changes are > >> correct. > >> > >> I can't tell you the amount of time I can spent on this project as I do have a > >> day job. > > > > We decided to give you full access to the project > > by giving you admin role. Now you can see that you > > can do anything with the project. > > > > We also have daily job and within a few weeks we > > are unable to contribute very much due to reorganization....etc. > > > > So we want to request you to accept our offer to be > > project admin and keep evolving gitstat in the future. > > Of course this does not mean that we will leave completely. > > But it is evident that we cannot focus on it very much in the future. > > > > Jeongseong and I are very happy to find someone we can trust who can keep > > working on it and hope you will be that person whom we were looking for. > > > > Our rough roadmap is written at revised TODO file > > and we hope that dream can come true with you. :-) > > > > Thanks very much. > Hi, > > Thanks again for the offer. I don't have an issue becoming one of the project > admins (and I really mean 'one of'). I think I have more or less the same time > constraints with respect to this project as you do and my primary focus (when > doing open source stuff) will be Wine. > > I thought this was a nice small project which I'm able and willing to contribute > (it will also extend my skills in MySQL and php). I can't however take over more > responsibility than just being another admin/developer for this project. > > Hope to not disappoint you too much, > > Paul Thanks for your understanding. I understand your point and we will remain as one of the admin too. :-) Giving you admin role does not mean you take the whole responsibility but showing that we are okay with your activity without our permission(?). You do not need to ask before you do something...because I think the current gitstat has not much or no possibility for design/implementation conflict within us. Thanks again. -- http://kldp.org/~kss |
|
From: Paul V. <pau...@gm...> - 2007-09-05 08:01:24
|
Soon-Son Kwon(Shawn) wrote: > Ah that's a good idea. We wanted to > use sourceforge's existing infrastructure > because we do not have dedicated server > to host our code with running git inside. > > I think it is natural to move to git in the future. > > > 2007/9/5, Paul Vriens <pau...@gm...>: >> Hi, >> >> This is something I'm wondering about (and some people with me I guess). Why are >> we using CVS and not git? >> >> Wouldn't it make perfect sense to use git for gitstat? We can even have our own >> project gitstat-ed (althouhg it will be a small project). >> >> Where there already thoughts about doing this? >> >> 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 >> > > Hi Shawn, http://repo.or.cz/ is a public git repository site. We can put the source there and leave http://tree.celinuxforum.org/gitstat/ as the frontend. I don't know much about this server but could it host more gitstat's? Like: gitstat-kernel gitstat-wine Did you see/hear about gitstats (http://sourceforge.net/forum/forum.php?forum_id=728427)? Cheers, Paul. |
|
From: Paul V. <pau...@gm...> - 2007-09-05 07:53:37
|
Soon-Son Kwon(Shawn) wrote: > 2007/9/5, Paul Vriens <pau...@gm...>: >> Soon-Son Kwon(Shawn) wrote: >>> Hi Paul, >>> Jeongseong and I decided to give you CVS write access. >>> Now you may commit to CVS at your own will. >>> Feel free to add / modify gitstat. >>> We think that will speed up the development. :-) >>> >>> Thanks very much. >> Hi, >> >> Thanks for the confidence. I will make sure that I test everything on at least >> the kernel-git and Wine-git. If possible I'll add some other projects that use >> git to my testing suite. I think it's the best way to guarantee that changes are >> correct. >> >> I can't tell you the amount of time I can spent on this project as I do have a >> day job. > > We decided to give you full access to the project > by giving you admin role. Now you can see that you > can do anything with the project. > > We also have daily job and within a few weeks we > are unable to contribute very much due to reorganization....etc. > > So we want to request you to accept our offer to be > project admin and keep evolving gitstat in the future. > Of course this does not mean that we will leave completely. > But it is evident that we cannot focus on it very much in the future. > > Jeongseong and I are very happy to find someone we can trust who can keep > working on it and hope you will be that person whom we were looking for. > > Our rough roadmap is written at revised TODO file > and we hope that dream can come true with you. :-) > > Thanks very much. Hi, Thanks again for the offer. I don't have an issue becoming one of the project admins (and I really mean 'one of'). I think I have more or less the same time constraints with respect to this project as you do and my primary focus (when doing open source stuff) will be Wine. I thought this was a nice small project which I'm able and willing to contribute (it will also extend my skills in MySQL and php). I can't however take over more responsibility than just being another admin/developer for this project. Hope to not disappoint you too much, Paul |
|
From: Soon-Son Kwon(Shawn) <ks...@kl...> - 2007-09-05 07:32:41
|
2007/9/5, Paul Vriens <pau...@gm...>: > Soon-Son Kwon(Shawn) wrote: > > Hi Paul, > > Jeongseong and I decided to give you CVS write access. > > Now you may commit to CVS at your own will. > > Feel free to add / modify gitstat. > > We think that will speed up the development. :-) > > > > Thanks very much. > Hi, > > Thanks for the confidence. I will make sure that I test everything on at least > the kernel-git and Wine-git. If possible I'll add some other projects that use > git to my testing suite. I think it's the best way to guarantee that changes are > correct. > > I can't tell you the amount of time I can spent on this project as I do have a > day job. We decided to give you full access to the project by giving you admin role. Now you can see that you can do anything with the project. We also have daily job and within a few weeks we are unable to contribute very much due to reorganization....etc. So we want to request you to accept our offer to be project admin and keep evolving gitstat in the future. Of course this does not mean that we will leave completely. But it is evident that we cannot focus on it very much in the future. Jeongseong and I are very happy to find someone we can trust who can keep working on it and hope you will be that person whom we were looking for. Our rough roadmap is written at revised TODO file and we hope that dream can come true with you. :-) Thanks very much. -- http://kldp.org/~kss |
|
From: Soon-Son Kwon(Shawn) <ks...@kl...> - 2007-09-05 07:10:29
|
Ah that's a good idea. We wanted to use sourceforge's existing infrastructure because we do not have dedicated server to host our code with running git inside. I think it is natural to move to git in the future. 2007/9/5, Paul Vriens <pau...@gm...>: > Hi, > > This is something I'm wondering about (and some people with me I guess). Why are > we using CVS and not git? > > Wouldn't it make perfect sense to use git for gitstat? We can even have our own > project gitstat-ed (althouhg it will be a small project). > > Where there already thoughts about doing this? > > 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 |
|
From: Paul V. <pau...@gm...> - 2007-09-05 06:41:25
|
Hi, This is something I'm wondering about (and some people with me I guess). Why are we using CVS and not git? Wouldn't it make perfect sense to use git for gitstat? We can even have our own project gitstat-ed (althouhg it will be a small project). Where there already thoughts about doing this? Cheers, Paul. |
|
From: Paul V. <pau...@gm...> - 2007-09-05 06:22:07
|
Soon-Son Kwon(Shawn) wrote: > Hi Paul, > Jeongseong and I decided to give you CVS write access. > Now you may commit to CVS at your own will. > Feel free to add / modify gitstat. > We think that will speed up the development. :-) > > Thanks very much. Hi, Thanks for the confidence. I will make sure that I test everything on at least the kernel-git and Wine-git. If possible I'll add some other projects that use git to my testing suite. I think it's the best way to guarantee that changes are correct. I can't tell you the amount of time I can spent on this project as I do have a day job. Cheers, Paul. |
|
From: Soon-Son Kwon(Shawn) <ks...@kl...> - 2007-09-05 06:04:24
|
Hi Paul, Jeongseong and I decided to give you CVS write access. Now you may commit to CVS at your own will. Feel free to add / modify gitstat. We think that will speed up the development. :-) Thanks very much. -- http://kldp.org/~kss |
|
From: Paul V. <pau...@gm...> - 2007-09-04 11:03:33
|
Paul Vriens wrote: > Hi, > > Attached is patch (proof of concept !) that put's the results for one of > the > charts in the database and only transfers the id of the table-entry to > bargraph.pl. > > Remember that you have to create the table: > > CREATE TABLE `Results` (`id` int(10) unsigned NOT NULL auto_increment, > `data` > text, PRIMARY KEY (`id`)); > > We can't delete the table-entry from bargraph.pl as the user can still > have the > chart in his browser and should be able to click on it or save it. > > The best way to get rid of the table entries (TRUNCATE Results;) is > probably > with the same cron-job that loads the database. > > As said, this is just a proof of concept, so feel free to shoot at it. > > Cheers, > > Paul. > It would help to sent the right patch ;-) Cheers, Paul. |
|
From: Paul V. <pau...@gm...> - 2007-09-04 10:28:16
|
Hi, Attached is patch (proof of concept !) that put's the results for one of the charts in the database and only transfers the id of the table-entry to bargraph.pl. Remember that you have to create the table: CREATE TABLE `Results` (`id` int(10) unsigned NOT NULL auto_increment, `data` text, PRIMARY KEY (`id`)); We can't delete the table-entry from bargraph.pl as the user can still have the chart in his browser and should be able to click on it or save it. The best way to get rid of the table entries (TRUNCATE Results;) is probably with the same cron-job that loads the database. As said, this is just a proof of concept, so feel free to shoot at it. Cheers, Paul. |
|
From: Paul V. <pau...@gm...> - 2007-09-04 06:50:02
|
??? wrote: > I used domain name instead of 'chart.php' at tree.celinuxforum.org. > I made some plan to make variable for domain name in config.php and to > check that variable. > and I tested on MSIE and firefox 2.0 and 1.0. > but, so it seems to be some problem. As has been mentioned it cannot be trusted. > Hi, yes this work also at my 'site' now. Thanks. > I have read your e-mail about a solution with DB, > but, there is some downside. > if 'chart.php' takes long time or server have traffic, some user > could leave chart page. > in case of that, chart-table had been created and and couldn't be removed . > but I thought that it works fine in many case . > As said, it was just a brainwave. I'll have a look again so see how/if we can deal with leftover table entries. > If you could make patch for this ,it could be better solution. > could u make it for gitstat user? > Thanks, > What do mean with 'gitstat user'? Is that compared to 'gitstat admin' or just to say everyone that uses gitstat? Cheers, Paul. |
2 messages has been excluded from this view by a project administrator.
