Hi all
Sorry for long mail, but I thing we should somehow face to future. Silence in mailing lists and CVS doesn't indicate anything good.
It looks like all current team members are quite busy with other stuff or don't have motivation to work on phpMyAdmin. We're way behind current MySQL features by not supporting views and stored procedures, which even can not be entered as SQL as changing delimiter completely chokes our SQL parser/spliter.
I myself hardly find time to do some work on phpMyAdmin when there are other project which attract me more and there is not only coding I want to do. Partly it is caused by me needs - I no longer require new features from phpMyAdmin for daily work, partly by lack of motivation for digging into quite complex parts of code.
We probably need fresh blood for team, but I don't see anybody who could be interested for this. Anyway fresh blood doesn't mean long time active developer. Our latest acquisition (Sebastian) was very active in first six months (or so, I don't recall exact numbers) and then he seems to run into same problems as all others. This seems to tell me there is something wrong with project. Is it it's code base? Are team members not enough supportive? Probably partly both, but I can't tell real reason.
There is need to move further, in current state we lack many needed features, which are requested. We won't loose our position in MySQL administration in near future as there is not much competence right now. However there are growing interesting projects like TurboDbAdmin [1] or even something like MySQL-Front [2] with PHP tunnel. They all have at least advantage of doing operations immediately and interactively and are not that limited by HTML/HTTP as phpMyAdmin.
Sorry I can't propose where to go. Maybe we should take part on SoC [3] with some larger stuff (eg. stored procedure functions), but it's too late for it right now.
1. http://turboajax.com/turbodbadmin/ 2. http://www.mysqlfront.de/ 3. http://code.google.com/soc/
Hi Michal and list,
I continue to be motivated to work on the project, but at my pace. I was gone for 3 weeks, this explains my slowdown. Silence in the lists and CVS is not necessarily bad, because there are some bug reports that result in no action after testing (but it takes time to analyse).
The development speed is reduced with more and more dormant developers on the team, and I can't force anyone to work :)
I get about 2 offers per month from new developers but when I redirect them to our FAQ (which says to first submit some code) no one seems interested.
About new features, maybe sponsoring developers for specific additions would help, with the limited donations we receive.
About bug tracking, we just need some people generous of their time...
Marc
Michal Čihař a écrit :
Hi all
Sorry for long mail, but I thing we should somehow face to future. Silence in mailing lists and CVS doesn't indicate anything good.
It looks like all current team members are quite busy with other stuff or don't have motivation to work on phpMyAdmin. We're way behind current MySQL features by not supporting views and stored procedures, which even can not be entered as SQL as changing delimiter completely chokes our SQL parser/spliter.
I myself hardly find time to do some work on phpMyAdmin when there are other project which attract me more and there is not only coding I want to do. Partly it is caused by me needs - I no longer require new features from phpMyAdmin for daily work, partly by lack of motivation for digging into quite complex parts of code.
We probably need fresh blood for team, but I don't see anybody who could be interested for this. Anyway fresh blood doesn't mean long time active developer. Our latest acquisition (Sebastian) was very active in first six months (or so, I don't recall exact numbers) and then he seems to run into same problems as all others. This seems to tell me there is something wrong with project. Is it it's code base? Are team members not enough supportive? Probably partly both, but I can't tell real reason.
There is need to move further, in current state we lack many needed features, which are requested. We won't loose our position in MySQL administration in near future as there is not much competence right now. However there are growing interesting projects like TurboDbAdmin [1] or even something like MySQL-Front [2] with PHP tunnel. They all have at least advantage of doing operations immediately and interactively and are not that limited by HTML/HTTP as phpMyAdmin.
Sorry I can't propose where to go. Maybe we should take part on SoC [3] with some larger stuff (eg. stored procedure functions), but it's too late for it right now.
Hi
On Thu, 25 May 2006 16:55:58 -0400 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I continue to be motivated to work on the project, but at my pace. I was gone for 3 weeks, this explains my slowdown.
It was nothing against you. Everybody needs to take holidays ;-).
Silence in the lists and CVS is not necessarily bad, because there are some bug reports that result in no action after testing (but it takes time to analyse).
Yes I know...
The development speed is reduced with more and more dormant developers on the team, and I can't force anyone to work :)
Of course we can not.
I get about 2 offers per month from new developers but when I redirect them to our FAQ (which says to first submit some code) no one seems interested.
What the hell did they want to do then? :-)
About new features, maybe sponsoring developers for specific additions would help, with the limited donations we receive.
How much we could afford spend without limiting money for conferences and other representation? Feel free to reply to private team list if you feel it should be private.
Michal Čihař a écrit :
Hi
On Thu, 25 May 2006 16:55:58 -0400 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I continue to be motivated to work on the project, but at my pace. I was gone for 3 weeks, this explains my slowdown.
It was nothing against you. Everybody needs to take holidays ;-).
Hmmm I was working during those 3 weeks :) Holidays are coming, though, on June 12.
Silence in the lists and CVS is not necessarily bad, because there are some bug reports that result in no action after testing (but it takes time to analyse).
Yes I know...
The development speed is reduced with more and more dormant developers on the team, and I can't force anyone to work :)
Of course we can not.
I get about 2 offers per month from new developers but when I redirect them to our FAQ (which says to first submit some code) no one seems interested.
What the hell did they want to do then? :-)
Maybe just be a member of the team, then (maybe) send code after. I really don't understand.
About new features, maybe sponsoring developers for specific additions would help, with the limited donations we receive.
How much we could afford spend without limiting money for conferences and other representation? Feel free to reply to private team list if you feel it should be private.
Not much, I'm afraid. But thinking of it, the first question is: who has time for this kind of sponsored work?
Marc
Hi there
On Fri, 26 May 2006 11:54:05 -0400 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Michal Čihař a écrit :
On Thu, 25 May 2006 16:55:58 -0400 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
About new features, maybe sponsoring developers for specific additions would help, with the limited donations we receive.
How much we could afford spend without limiting money for conferences and other representation? Feel free to reply to private team list if you feel it should be private.
Not much, I'm afraid. But thinking of it, the first question is: who has time for this kind of sponsored work?
Maybe I could arrange it in a way that I could do this, but not in short term (not sooner than in a half year).
On Thu, May 25, 2006 at 10:37:56PM +0200, Michal ??iha?? wrote:
Sorry for long mail, but I thing we should somehow face to future. Silence in mailing lists and CVS doesn't indicate anything good.
It's not a positive sign, but it's not entirely negative either - there have been periods of quiet in the past, just because everybody is busy.
I myself hardly find time to do some work on phpMyAdmin when there are other project which attract me more and there is not only coding I want to do. Partly it is caused by me needs - I no longer require new features from phpMyAdmin for daily work, partly by lack of motivation for digging into quite complex parts of code.
I think there is another side to this, that you are perhaps overlooking: Compared to existing functionality, how much do you actually NEED views and stored procedures? There are a great many proponents against stored procedures, claiming that business logic doesn't belong in the database (I agree with them, but only because stored procs make maintenance harder than it should be, you can't keep multiple versions).
Likewise, if your application is complex enough to actually require views, there are probably other parts of it beyond PMA.
It looks like all current team members are quite busy with other stuff or don't have motivation to work on phpMyAdmin. We're way behind current MySQL features by not supporting views and stored procedures, which even can not be entered as SQL as changing delimiter completely chokes our SQL parser/spliter.
As for changing the delimiter - I have tried to look into the mysqli interface for it, but I haven't found anything that seems to be correct for it.
We probably need fresh blood for team, but I don't see anybody who could be interested for this. Anyway fresh blood doesn't mean long time active developer. Our latest acquisition (Sebastian) was very active in first six months (or so, I don't recall exact numbers) and then he seems to run into same problems as all others. This seems to tell me there is something wrong with project. Is it it's code base? Are team members not enough supportive? Probably partly both, but I can't tell real reason.
Our original objectives do stifle some further innovation I agree, but the innovation is at odds with our objectives. It would be nice to have an AJAX based PMA, but that wouldn't work on old browsers.
There is need to move further, in current state we lack many needed features, which are requested. We won't loose our position in MySQL administration in near future as there is not much competence right
[snip]. As I said, it's a matter of demand for new features - none of us as developers have a real need for them, so while that continues, we are unlikely to develop support for them. In the past, I wrote the initial PHPDBG support, the initial query parsing, the Mimer SQL validator support, because I needed them.
Sorry I can't propose where to go. Maybe we should take part on SoC [3] with some larger stuff (eg. stored procedure functions), but it's too late for it right now.
From being involved with other projects that have partipated in SoC before, there has been one very specific complaint - after the SoC was over, they never heard from the students again in many cases - and this lead to bitrot, because nobody on the existing project could/wanted to maintain the student's code.
In terms of future stuff, I may be revisiting the SQL parser code soon, with an eye towards interoperability, because I've been using PostGreSQL at my job, and phpPgAdmin forked from us a long time ago, and as such, doesn't have some things that we do, while instead taking different paths to some functionality - they don't have an SQL parser, but they do have some support for stored procedures and views.
Hi
On Thu, 25 May 2006 14:16:26 -0700 "Robin H. Johnson" robbat2@users.sourceforge.net wrote:
It's not a positive sign, but it's not entirely negative either - there have been periods of quiet in the past, just because everybody is busy.
But this last period is taking almost year. With exception of Marc who is still doing his constant amount work, Sebastian who started to code and burn out and me who time to time finds time for really urgent things I need and make tons of commits per day then.
I think there is another side to this, that you are perhaps overlooking: Compared to existing functionality, how much do you actually NEED views and stored procedures?
We need at least some basic support - to allow work with those stuff through SQL window, to correctly export and import them to SQL. People do expect that dumps contain everything (see latest bug). Full GUI would be nice, but that's not that urgent.
Likewise, if your application is complex enough to actually require views, there are probably other parts of it beyond PMA.
You need to work directly with database even when creating complex applications.
As for changing the delimiter - I have tried to look into the mysqli interface for it, but I haven't found anything that seems to be correct for it.
We probably need to parse SQL to detect this case and then change delimiter in SQL splitter.
From being involved with other projects that have partipated in SoC before, there has been one very specific complaint - after the SoC was over, they never heard from the students again in many cases - and this lead to bitrot, because nobody on the existing project could/wanted to maintain the student's code.
I also saw that, however you can force them to make code readable and maintainable, otherwise they won't receive their reward.
In terms of future stuff, I may be revisiting the SQL parser code soon, with an eye towards interoperability, because I've been using PostGreSQL at my job, and phpPgAdmin forked from us a long time ago, and as such, doesn't have some things that we do, while instead taking different paths to some functionality - they don't have an SQL parser, but they do have some support for stored procedures and views.
Maybe it's time to merge back ;-). Feature sets of both databases are very close now....
Michal Čihař a écrit :
Hi
On Thu, 25 May 2006 14:16:26 -0700 "Robin H. Johnson" robbat2@users.sourceforge.net wrote:
As for changing the delimiter - I have tried to look into the mysqli interface for it, but I haven't found anything that seems to be correct for it.
We probably need to parse SQL to detect this case and then change delimiter in SQL splitter.
But this DELIMITER thing is not SQL syntax, it's for the command-line utility. Maybe we could have a small option in the query window that enables to specify which group of characters are the SQL delimiter, with ";" being the default; then inform the parser about it.
Marc
Hi
On Fri, 26 May 2006 12:01:12 -0400 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
But this DELIMITER thing is not SQL syntax, it's for the command-line utility. Maybe we could have a small option in the query window that enables to specify which group of characters are the SQL delimiter, with ";" being the default; then inform the parser about it.
Yes I know it's command-line util stuff, but people expect it will work. And so do I ;-). Changing delimiter to be configurable should be quite easy in SQL import plugin, however parsing SET DELIMITER would be also nice.
-
Marc Delisle -
Michal Čihař -
Robin H. Johnson