2015 05_Meeting_IRC_Log

08:49 -!- Hugues_ [52eacbde@gateway/web/freenode/ip.82.234.203.222] has joined #phpmyadmin
08:49 < Hugues_> Hi everyone.
08:49 < ibennetch> I can run the meeting and post the log
08:49 < ibennetch> Hello Hugues_
08:51 -!- nisargjh|cloud is now known as nisargjhaveri
08:52 < Marc9> Hi Hugues
08:52 < Marc9> Hi nijel
08:52 -!- Voovode [~Alex@tenatena.static.otenet.gr] has quit [Read error: Connection reset by peer]
08:54 < Hugues_> :)
08:55 < ibennetch> The monthly phpMyAdmin developer meeting will begin in 5 minutes
08:56 < Marc9> ibennetch thanks for taking care of these tasks
08:57 < ibennetch> :)
08:59 -!- madhuracj [~kvirc@112.134.80.226] has joined #phpmyadmin
08:59 < Marc9> Hi Madhura
09:00 < ibennetch> The monthly phpMyAdmin developer meeting will begin now. The meeting is logged and posted to wiki.phpmyadmin.net. Welcome.
09:00 < ibennetch> Our first item is the caching RFE
09:00 < madhuracj> Hi Marc
09:00 -!- nijel [~nijel@185.47.222.168] has quit [Read error: Connection reset by peer]
09:01 < ibennetch> Any discussion of this?
09:01 < Marc9> Obviously I am in favor ;)
09:01 < ibennetch> :)
09:01 < madhuracj> I'm also in favor even though I can think of new things to cache right now
09:01 < madhuracj> cant*
09:02 < Hugues_> I'm in favor too.
09:02 < ibennetch> It seems useful to improve this. Are you interested in working on it Marc9 ?
09:02 < Marc9> At least, we could test if it helps to use memcached
09:02 < Marc9> Yes I am interested
09:03 -!- nisargjhaveri is now known as nisargjh|cloud
09:03 < Hugues_> More than test, it would be useful to have performance measures (link to next point).
09:03 < ibennetch> In that case I would say go ahead and see what you can find and improve. Seems like a useful enhancement.
09:03 -!- nisargjh|cloud is now known as nisargjhaveri
09:03 < Marc9> Hugues good point
09:03 -!- nijelmobile [~yaaic@213.29.26.3.dial-up.cz] has joined #phpmyadmin
09:03 < ibennetch> I guess we can move ahead to the next item?
09:04 < ibennetch> Hello nijelmobile
09:04 < Hugues_> Let's move.
09:04 < nijelmobile> hi,  my network connection sucks today, using phone...
09:05 < ibennetch> Performance and profiling. This seems like something useful for debugging and developer use, of course I don't think we need to profile every user's entire session.
09:05 < ibennetch> I don't know about any external profiler that would help here -- it probably exists, I just don't know about any
09:06 < Marc9> First, is there a general feeling that version 4 is slower than 3?
09:06 < Hugues_> Indeed, there are some. Like xdebug.
09:07 < madhuracj> @Marc9 It's been a long since I used version 3. Probably need to go back and compare them side by side
09:07 < ibennetch> I don't have that feeling, but haven't used 3 in some time so it's hard to compare. I think the AJAX loading of 4 makes it seem slower sometimes, rather than waiting for an entire page to load we're looking at a spinner.
09:07 < Hugues_> And so I'm not sure that we should implement somethink about this. Even if it would be useful... But I  think that we have to see the benefit regarding to the effort to implement it.
09:07 < ibennetch> This seems slower even when it's actually the same amount of time.
09:07 < Marc9> I tend to favor using an external profiler, rather than adding hooks
09:08 -!- nijel [~nijel@185.47.222.168] has joined #phpmyadmin
09:08 < Hugues_> Agree with Marc.
09:08 < madhuracj> Agreed
09:08 < nijel> Using external profiler sounds better indeed
09:09 < Hugues_> Maybe, the day will use a framework like Zend or Symfony, we could think about this.
09:09 < Marc9> So, for example, someone could use xdebug to produce profiling data for a known task, and compare version 3.5 to 4.4
09:09 < madhuracj> I would like to configure xdebug and give it a try to see if version 4 is slower than 3
09:09 < Marc9> Madhura thanks for volunteering
09:10 < madhuracj> May be then we can decide whether any action is required
09:10 < Hugues_> Maybe the tests should be done on some defined pages.
09:10 < Marc9> I suggest using a sample database like sakila and some known tasks
09:10 < Hugues_> (I hope this is not linked to multibytes management...)
09:10 < nijel> yes, checking things like browsing table, editing record or table structure...
09:10 < madhuracj> Probably choose a set of frequenly used functionalities
09:11 < Marc9> Hugues it might be, but the profiling report will tell us
09:11 < Hugues_> I agree. :)
09:11 < ibennetch> Any more discussion on this? If not we can move on to double-click renaming
09:12 < Hugues_> Who would be in charge of this part ?
09:12 < Hugues_> Ah, Madhura. Thanks.
09:12 < madhuracj> :)
09:13 < ibennetch> About double-click renaming, as a user this is not something I would use.
09:13 < Marc9> Double-click renaming feels to me more like a non-essential feature
09:14 < ibennetch> I'm more likely to accidentally double click something than intend to rename my tables often.
09:14 < ibennetch> I feel this is a rare need and better handled by our existing means.
09:14 < madhuracj> I'm also not in favor of this feature
09:14 < Hugues_> Yes... I don't think that table and field's names are really ofter changed.
09:14 < nijel> I agree with Hugues_, it's not really something frequently done
09:15 < Hugues_> And I often double-clic to copy/paste...
09:15 < Marc9> Also, it would have to be implemented in both panels
09:15 < ibennetch> Marc9: thanks for helping with updating the tracker as we go along
09:15 < Hugues_> It would be disturbing indeed.
09:15 < ibennetch> Okay, so no one seems to be in favor at this time.
09:15 < Marc9> and in the main panel, we already have the click on column headers to sort, etc
09:16 < ibennetch> yes, click/double click/right click/alt-click is quite overloaded already :)
09:16 < ibennetch> Okay then, "Select from previously used table or column names"
09:16 < madhuracj> Looks like an edge case to me
09:17 < Marc9> For this one, I believe that copying/pasting an on-screen text is enough
09:17 < ibennetch> I'm having trouble figuring out what the user wants, is this in the SQL window?
09:17 < Hugues_> I don't really catch the need here.
09:17 < Marc9> Ibennetch it's in the table creation dialog
09:18 < ibennetch> Oh, okay. Then the browser autocomplete should suggest previously used names :D
09:18 < Marc9> ibennetch good point
09:18 < ibennetch> I see how it would help this user, but don't think we should do this.
09:19 < Hugues_> Really ?
09:19 < Hugues_> Shouldn't we fill the autocomplete dictionary?
09:20 -!- nijelmobile [~yaaic@213.29.26.3.dial-up.cz] has quit [Quit: AtomicIRC: The nuclear option.]
09:20 < Marc9> Hugues, this is not for the SQL query box with codemirror
09:20 < ibennetch> Hugues_: I think you're interpreting my two statements as being connected, but I didn't mean that.
09:20 < ibennetch> I mean "I see how implementing this feature would help this user, but don't want to implement it" rather than "we shouldn't allow the browser to autocomplete"
09:20 < ibennetch> I _think_ that's the misunderstanding?
09:21 < Hugues_> Thanks Marc9 , I see my mistake.
09:21 < ibennetch> Great, so no one thinks we should implement this one, either.
09:22 < ibennetch> Don't group tables
09:22 < ibennetch> in the tree if the result has only one group"
09:22 < Hugues_> No... Copy/paste is not a big deal and can solve this issue.
09:23 < ibennetch> I think it makes sense to not group if there is only one table/database -- but I don't recall whether this is easy to do in the navigation logic
09:23 < Hugues_> Don't group are open the group by default ?
09:23 < Marc9> about having just one group, I don't see a problem here
09:23 < Hugues_> Don't group or open the group by default? (Sorry for the mistake...)
09:24 < Hugues_> If we don't group, where would be displayed the DB name?
09:24 < Marc9> Hugues_, Olaf does not want to have a group here
09:25 < Marc9> He would like to just see the table names without grouping
09:25 < nijel> don't group if there is just one group
09:25 < Marc9> The DB name is already displayed
09:27 < Marc9> Not grouping here would be inconsistent and we would get a RFE to bring it back
09:27 < madhuracj> I'm undecided on this. I see his point. But wouln't this be confusing where at one place it is grouped and another place it is not
09:27 < Marc9> madhuracj exactly
09:27 < ibennetch> ^^^ this. What madhuracj said is exactly what I think also
09:27 < Hugues_> I agree.
09:28 < Marc9> another won't fix ;)
09:28 < nijel> would not be better to provide easy way to disable groupping through user prefs?
09:29 < Marc9> nijel but he still wants grouping in other cases
09:30 < ibennetch> "dear Olaf, I secretly agree with you but don't want to fix it in order to maintain a consistent user interface for less experienced users"
09:32 < ibennetch> Okay, having thought about it for a few minutes, I propose that we fix it as suggested by Olaf and add a note to the documentation that "when enabled but only one "grouped" database/table is present, grouping is temporarily removed for that database" or something like that.
09:32 < ibennetch> I think it makes the interface cleaner if we implement his suggestion.
09:32 < nijel> I agree with ibennetch
09:33 < Hugues_> If not too expensive, OK.
09:34 < ibennetch> So just to be clear that's three yes answers, and what about the rest?
09:35 < madhuracj> I agree with Hugues. Let's see after inspecting the underlying code as well
09:35 < ibennetch> Good point about checking the cost
09:36 < Marc9> I have no objection
09:36 < ibennetch> Okay, thanks. Moving on to bringing back "Display binary as hex/string"
09:37 < Marc9> Madhura did you have a look at implementing this?
09:38 < ibennetch> From a user perspecitve I definetely think we should do this. From a project standpoint, I'm not sure how difficult it actually is
09:38 < madhuracj> Briefly.
09:38 < madhuracj> I had a look at the commit that removed it and was wondering whether it contained additional things
09:39 < ibennetch> I think Chirayu can probably comment on the code although I don't think he's here now.
09:39 < madhuracj> I thought Chirayu would know better about this
09:39 -!- Irssi: #phpmyadmin: Total of 38 nicks [1 ops, 0 halfops, 0 voices, 37 normal]
09:39 < Marc9> It's a too-part commit that removed a feature to add another one
09:39 < Marc9> I was expecting the presence of Chirayu at the meeting
09:40 < madhuracj> Anyways, I'm in favor of this RFE
09:40 < ibennetch> Are there any objections outright to bringing this back? Aside from concerns about messing up data, etc?
09:40 < Marc9> Yes, I don't think we have a choice here, the user has a valid point
09:40 < ibennetch> If not, I propose we accept it, ask Chirayu for input on the mailing list, and see what happens.
09:41 < Hugues_> I agree, this is quite useful even for us at work.
09:42 < ibennetch> Okay, it seems we all realize this is a good idea to bring back, it's just a matter of figuring out whether it's possible and actually doing it.
09:42 < ibennetch> Marc, could you email the list and ask Chirayu for input, either on list or in the tracker directly (whichever you think is better)?
09:42 < Marc9> will do
09:43 < ibennetch> thanks
09:43 < ibennetch> Group databases and tables by regex
09:43 < ibennetch> This seems like it would be very complex to do, which is what Madhura also found when examining it. I'd say no.
09:44 < Marc9> I would also say no, especially since it was asked a long time ago
09:44 < madhuracj> I thought its benefits are not worth the complexity it brings
09:45 < Hugues_> It will lead to new performance issues.
09:45 < Hugues_> Here, I'm not convinced of the benefit.
09:45 < ibennetch> Okay, great.
09:45 < ibennetch> One more: add a configuration directive for logo_left
09:46 < ibennetch> The user is implementing a custom theme and wants to make the logo a user-configurable option.
09:47 < madhuracj> I feel we already have zillions of configurations and I am not in favor
09:47 < Hugues_> I understand the need, but so... why shouldn't we provide a full theme tool?
09:48 < Marc9> Hugues, let me guess ... lack of manpower?
09:48 < ibennetch> I definetely don't want more configuration options, either. I think this is beyond the scope of what themes were meant to do.
09:48 < Hugues_> Yes, that the point !
09:48 < Hugues_> If we start with this, we'll be asked more graphic options.
09:49 < Marc9> I don't see a valid reason to make this configurable
09:50 < Marc9> Hugues I understood that you were proposing such a tool
09:50 < Hugues_> So let's say "no"?
09:50 < Marc9> We can explain that we feel this is an edge case
09:51 < ibennetch> I agree that we can say no to this
09:52 < Marc9> ibennetch can you reply in the PR with the explanation and close it?
09:52 < ibennetch> Sure
09:52 < madhuracj> Hugues, can you propose the theme tool in more detail as a RFE or a GSoC idea .
09:53 < ibennetch> I believe that's it for the agenda, then, and seven minutes early, too :)
09:53 < Hugues_> Oh... That wasn't the aim of the question, but if you think this is a good idea, yes, I can do this.
09:53 < madhuracj> Yes, I am interested
09:53 < Hugues_> I'll add this as a RFE.
09:54 < madhuracj> Thanks
09:54 < ibennetch> Okay, then I declare the official meeting over. Thank you all for coming
09:54 -!- Irssi: #phpmyadmin: Total of 38 nicks [1 ops, 0 halfops, 0 voices, 37 normal]
09:54 < Hugues_> Thanks.
09:54 < Marc9> Bye all and thanks ibennetch for running the meeting
09:55 < Hugues_> See you.