Hi, just to ask confirmation of what was discussed previously: feature freeze and -rc1 on May 9th?
Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi
On Monday 03 of May 2004 17:00, Marc Delisle wrote:
just to ask confirmation of what was discussed previously: feature freeze and -rc1 on May 9th?
No problem for me. I originally wanted to make import tab and related changes, but I probably won't have time for that. But postponing feature freeze will not make it better :-)
- -- Regards Michal Čihař http://cihar.com
Hi there,
Marc Delisle wrote:
just to ask confirmation of what was discussed previously: feature freeze and -rc1 on May 9th?
No objections from my side.
I was working on bug #945784 for 2.6.0, but I think that this one goes much deeper than the problem described here. I've polluted my tesing system with about 230,000 databases. In fact, pma is not able to handle this.
Of course, 230,000 databases on a single MySQL server is kind of stupid, but pma already gets problems with about 5,000 databases or even less...
As this problem should have been existing for a long time, I think it's okay to postpone the fix for 2.6.1, but in this case I need the "frozen" code to be branched out.
Let's have a clean 2.6.1,
Hi again,
Alexander M. Turek wrote:
Marc Delisle wrote:
just to ask confirmation of what was discussed previously: feature freeze and -rc1 on May 9th?
No objections from my side.
Personally, I'd like to have patch #947190 in 2.6.0... Porting it to 2.6.0 shouldn't be that hard, so if we waited just a few more days with the feature freeze... ... ... :-)
Regards,
On 05.05.2004 10:03 +0200, Alexander M. Turek wrote:
Hi again,
Alexander M. Turek wrote:
Marc Delisle wrote:
just to ask confirmation of what was discussed previously: feature freeze and -rc1 on May 9th?
No objections from my side.
Personally, I'd like to have patch #947190 in 2.6.0... Porting it to 2.6.0 shouldn't be that hard, so if we waited just a few more days with the feature freeze... ... ... :-)
I don't like way how the design is achieved (many nested tables), but it looks really nice :-). This will IMHO need more work to get nicer code, so I vote for postponing this patch after 2.6.0 (or postponing 2.6.0 for longer time). Meging into 2.6.0 is also not trivial, more than half of changes need manual merging.
Hi All!
Personally, I'd like to have patch #947190 in 2.6.0... Porting it to 2.6.0 shouldn't be that hard, so if we waited just a few more days with the feature freeze... ... ... :-)
I really love that patch, but I do think some work needs to be done to integrate it seemlessy and most of all backwards-compatible. I agree it's not that hard, but I also think it may take up to 2-3 weeks to solve all issues.
So either we postpone a lot and get it done good, or we don't postpone and integrate it for 2.6.x as nijel also said.
I don't know how advanced the mysqli-stuff is (don't have mysqli available here currently), but I guess it's more important for the people out there to have mysqli support than a PMA-redesign. So I think we shouldn't postpone the release, which means we should use the patch for 2.6.1 -> $0.02. :-)
Regards, Garvin.
Garvin Hicking a écrit:
Hi All!
Personally, I'd like to have patch #947190 in 2.6.0... Porting it to 2.6.0 shouldn't be that hard, so if we waited just a few more days with the feature freeze... ... ... :-)
I really love that patch, but I do think some work needs to be done to integrate it seemlessy and most of all backwards-compatible. I agree it's not that hard, but I also think it may take up to 2-3 weeks to solve all issues.
So either we postpone a lot and get it done good, or we don't postpone and integrate it for 2.6.x as nijel also said.
I don't know how advanced the mysqli-stuff is (don't have mysqli available here currently), but I guess it's more important for the people out there to have mysqli support than a PMA-redesign. So I think we shouldn't postpone the release, which means we should use the patch for 2.6.1 -> $0.02. :-)
Regards, Garvin.
I have read your opinions, and I must say that they all make sense!
I vote for merging the new patch for a delayed 2.6.0-rc1. First I was thinking that we are late in 2.6.0 cycle, but now I think:
- people that need mysqli already have 2.6.0-alpha1, or the daily snapshot - for a 2.6.0 release, maybe it's important to have a new look. Most users do not even have the server infrastructure to benefit from our mysqli support, so the main thing they will notice is the look :)
However I am concerned about the size of this patch. I have some time to devote to this and I hope other devs also have some time. Fortunately, Michael seems motivated and will surely cooperate to help on this.
Marc
On 05.05.2004 08:48 -0400, Marc Delisle wrote:
I have read your opinions, and I must say that they all make sense!
I vote for merging the new patch for a delayed 2.6.0-rc1. First I was thinking that we are late in 2.6.0 cycle, but now I think:
- people that need mysqli already have 2.6.0-alpha1, or the daily snapshot
Maybe releasing aplha2 before we start new look merging?
- for a 2.6.0 release, maybe it's important to have a new look. Most
users do not even have the server infrastructure to benefit from our mysqli support, so the main thing they will notice is the look :)
I absolutely agree.
However I am concerned about the size of this patch.
There are tons of unneeded (and unwanted) changes like removing echo "\n";, meging of more lines onto one and so on. It needs huge cleanup...
Hi All!
I vote for merging the new patch for a delayed 2.6.0-rc1. First I was thinking that we are late in 2.6.0 cycle, but now I think:
I can live with that. You are right about people being able to user 2.6.0, but alpha may sound way unstable to users, so I was thinking that many will only migrate as soon as it leaves the 'alpha' cycle.
However I am concerned about the size of this patch. I have some time to devote to this and I hope other devs also have some time. Fortunately, Michael seems motivated and will surely cooperate to help on this.
As you maybe can see from my last work on PMA I'm getting a new grip and time to spend on it. So if the patch will be delivered in time I surely offer to work on it; just as Michal said, we need to apply our coding style to the patch and most of all try to maintain some backwards-compatibility for the 'old' look.
I was already thinking of splitting up the configuration file into a ".design" php file where one could apply the many optical directives. But doing so would mean huge work on the config_import utility...
Regards, Garvin.
Hi there,
Marc Delisle wrote:
I vote for merging the new patch for a delayed 2.6.0-rc1. First I was thinking that we are late in 2.6.0 cycle, but now I think:
- people that need mysqli already have 2.6.0-alpha1, or the
daily snapshot
- for a 2.6.0 release, maybe it's important to have a new
look. Most users do not even have the server infrastructure to benefit from our mysqli support, so the main thing they will notice is the look :)
That's what I thought, too.
Michal Cihar wrote:
Maybe releasing aplha2 before we start new look merging?
+1 from my side. We fixed some bugs and merged some smaller changes since alpha1.
There are tons of unneeded (and unwanted) changes like removing echo "\n";, meging of more lines onto one and so on. It needs huge cleanup...
Can you estimate how long this might take?
Garvin Hicking wrote:
I can live with that. You are right about people being able to user 2.6.0, but alpha may sound way unstable to users, so I was thinking that many will only migrate as soon as it leaves the 'alpha' cycle.
Yes, but people who are afraid of alphas usually don't deal with MySQLi and MySQL 4.1 either, do they? MySQLi is a very yound php extension, bundled with php5 which is still beta - just like MySQL 4.1.
When we started working on 2.6.0, we branched out 2.5.x because we expected the development of 2.6.0 to take longer than usual. As far as I know, there are no critical bugs that would require a fast release and even if there was one: we could still merge a fix to the 2.5.x branch.
The main features of 2.6.0 (MySQLi and full MySQL 4.1 / 5.0 support) affect php and MySQL versions that should be handled at least as carefully as a phpMyAdmin alpha version.
As you maybe can see from my last work on PMA I'm getting a new grip and time to spend on it. So if the patch will be delivered in time I surely offer to work on it; just as Michal said, we need to apply our coding style to the patch and most of all try to maintain some backwards-compatibility for the 'old' look.
What do you mean by "backwards-compatibility"?
I was already thinking of splitting up the configuration file into a ".design" php file where one could apply the many optical directives. But doing so would mean huge work on the config_import utility...
No, it won't. Trust me. :-)
Regards,
Hi Alexander!
Michal said, we need to apply our coding style to the patch and most of all try to maintain some backwards-compatibility for the 'old' look.
What do you mean by "backwards-compatibility"?
I have not yet looked at the code of the redesign, only the live-demo. There are lots and lots of icons, which I tend to like personally and for newebie users. But as we all know from the several angry users after adding icons in first place, I guess many users do not want to have those buttons, so they need to be optional. And any other improvements, if making a definite difference in the UI should be tweakable.
I think PMA benefits from long-term users who gotten used to it and who we might annoy by forcing a new UI upon them.
I was already thinking of splitting up the configuration file into a ".design" php file where one could apply the many optical directives. But doing so would mean huge work on the config_import utility...
No, it won't. Trust me. :-)
So you're doing this? :)
Today I was thinking of how we could make preferences toggle-able for users based on a DB-config. There are two approaches:
1. The "DB"-way.
You'd have a new panel inside PMA where you can see a list of all tweakable settings and toggle them as you like. Those preferences get stored inside a new PMA table. After PMA reads the config.inc.php it overrides any settings stored in the table. Each user will get a cookie to identify him with the personal ID stored in the table.
So a user could have one or even more "profiles" available by extending the ID values (as an serialized array) inside his cookie. If he has more than one ID cookie he can choose the profile he wants to have applied.
Once we have a GUI for adjusting options (maybe we could use dropdown/enum code from our tbl_change already and just take care of a global PHP file defining possible and default values plus short/long descriptions) this should be fairly easy to implement. There could also be a way to share profiles which can be marked as profile.
2. The "cookie way"
Basically same as above, but the config data is stored as a serialized array in the cookie.
Benefits for this option: No need for setting up PMA tables, works out of the box. Performance should be equal; what is saved on not querying the SQL-table is lost on unserializing and submitting cookie data.
Drawback: If the cookie is lost, the profile is lost. No use accross different browsers.
We could implement both ways and make the 2nd the default to give all users that feature; we may also offer a "export my profile" setting which stores a profile inside the file system of the webserver and reload it in a checkbox.
Choosing a different CSS layout could also be part of this new functionality, but we'd than have to make the CSS file static and split up for left/right frame. This would also make it easier for CSS-designers to work on non-PHP code.
Opinions? :-)
Regards, Garvin.
-
Alexander M. Turek -
Garvin Hicking -
Marc Delisle -
Michal Čihař