2015 04_Meeting_IRC_Log

12:00 < ibennetch> Welcome to the monthly meeting for phpMyAdmin developers. The log will soon be posted to the wiki at wiki.phpmyadmin.net
12:00 -!- udan11 [~udan11@188.247.227.245] has quit [Remote host closed the connection]
12:00 -!- udan11_ is now known as udan11
12:00 < ibennetch> First item is the git history, Marc would like to remove unmaintained branches
12:01 < zixtor> I don't have a problem with this proposed deletion for the stated benefit of clarity..
12:01 < Marc9> Yes, I'm pretty tired on this long selector on github
12:01 < ibennetch> Since we have the tag available, I don't object.
12:02 < Marc9> Also it sends the wrong message, especially talking about MAINT
12:02 < smita786> Yeah I as well see no issue with deletion
12:02 < zixtor> Yeah, and as said we can still avail tags if we ever need to test something against older branches.
12:02 < Marc9> and Michal said he does not mind
12:02 < ibennetch> Okay, sounds like there are no true objections. Michal and myself both are not fond of the idea bout don't seem to object, so Marc can you take care of this?
12:02  * Marc9 will
12:03 < ibennetch> Okay, great. Thakns. Moving on, tags for pre-releases
12:03 < Marc9> Seeing a MAINT branch for something that is no longer maintained, is not good IMO
12:03 < ibennetch> Right
12:03 < ibennetch> I don't see a need to tag alpha or beta releases
12:04 < Marc9> Right now, the tags are inconsistent;
12:04 < Marc9> for some release there are pre-release tags
12:04 < Marc9> ibennetch so you see a need for release candidates tags
12:04 < Marc9> ?
12:05 < zixtor> I don't see a problem with this proposition either..
12:05 < ibennetch> Oh, no I just didn't want to type all of that out :)
12:05 < Marc9> ok
12:06 < ibennetch> Better to say what I mean: I don't see a need to tag alpha, beta, rc, or other releases that aren't true released versions.
12:06  * Marc9 thinks the same
12:07 < ibennetch> Okay, great. Should we also remove the old tags that match (the existing old alpha, beta, and rc tags)?
12:07 < ibennetch> I think so
12:07 < smita786> yeah I guess we should
12:07 -!- _dstorm [~Death.Sto@49.205.85.242] has joined #phpmyadmin
12:07 < _dstorm> Hi all
12:07  * Marc9 will remove these old non-release tags
12:07 < ibennetch> Hello _dstorm
12:07 < ibennetch> Thanks Marc9
12:07 < Marc9> pre-release rather
12:08 < ibennetch> Okay, next item is support for 4.3
12:08  * Marc9 is in favor of my proposal ;)
12:08 < Marc9> Hi _dstorm
12:08 < zixtor> I agree.
12:08 < _dstorm> I am in favor of it
12:09 < smita786> me too in favor
12:09 < ibennetch> _dstorm: so far we have gotten through the first two items, removing release branches and removing tags for alpha, beta, and rc releases. No one objected to this.
12:09 < _dstorm> No objection from me as well
12:09 < ibennetch> In fact, on further review, that seems to me what the tags are meant for, so I am more in favor of the first proposal than I was at first.
12:10 < ibennetch> So I believe we're moving on the support for 4.3
12:11 < Marc9> ibennetch, this is what we were discussing, right?
12:11 < ibennetch> Currently we're supporting 4.2.x until July 2015, 4.0.x until January 2017, and 4.4.x is current.
12:12 < ibennetch> Fine by me as well.
12:12 < ibennetch> Seems everyone's okay with the 4.3 timeline, so moving on to xy compression
12:13 < smita786> yeah
12:13 < _dstorm> *xz
12:13 < ibennetch> Marc9: yes we were on it already, I'm just experiencing lag between my brain and keyboard. Same thing for the xy/xz comment :) I thought the right thing but the wrong words came out
12:14 < ibennetch> I don't have a strong feeling about xz compression. Especially since several people have not been able to get it working.
12:14 < Marc9> udan11, what's your experience with this? does this compression work "way better" ?
12:14 < _dstorm> what is the performance overhead of xz compression?
12:15 < Marc9> ibennetch, udan11 sent updated instructions in the pull request
12:16 < ibennetch> I did see that but haven't had a chance to try myself and haven't seen anyone else have success yet with the proposed patch.
12:16 < zixtor> I think we can wait for it until it becomes straight forward to install in first place..
12:17 < _dstorm> Wiki says "xz compresses/decompresses single files as input, and does not bundle multiple files into a single archive."
12:17 < Marc9> Looking at our compressed kits, .tar.bz2 is 7.6 MB and .tar.xz is 5.6 MB
12:18 < ibennetch> I believe I made a comment in the original tracker item suggesting that until this is a standard PHP module that I don't really see a point. I know that xz is better than most alternative compression methods, but until it's more common in PHP installations I wonder if anyone will use it.
12:18 < udan11> I don't have much experience with xz compression. I am still researching. Afaik, it compresses better, but it requires a custom module which is not always available.
12:19 < Marc9> ibennetch, and then when it becomes standard, it will be years before it's in distros then years before ISPs have it
12:19 < Marc9> zixtor, good point
12:19 < Marc9> Did someone contact the author to see if this module has been proposed to be part of PHP ?
12:20 < ibennetch> I feel if someone (1) knows about and wishes to use it and (2) has the technical ability to get the module working on their server, then the probably are using a cron script and mysqldump and can just pipe the output through the command line xz compression anyway.
12:20 < ibennetch> Marc9: that is a good thought
12:20 < udan11> The author is dead.
12:20 < ibennetch> That is unfortunate
12:20 < _dstorm> Does user need some other tool to decompress xz files?
12:20 < Marc9> dead as in dead ?
12:20 < udan11> Payden has died last year in september.
12:20 < Marc9> _dstorm, we also need to compress them
12:21 < _dstorm> Yeah, that too.
12:21 < ibennetch> _dstorm: there are several utilities that will do so, but none of the standard tools on my system will work with xz files
12:22 < _dstorm> I am thinking from users perspective. How much effort users will have to do to compress/decompress xz files
12:22 < Marc9> So maybe we could wait to see if someone continues payden's work
12:22 < _dstorm> to upload and download data
12:24 < ibennetch> We should try to move on from this topic soon; are there any objections to Marc's suggestion to wait a bit?
12:24 < ibennetch> We can see what happens with the module in a few months and revisit this then?
12:24 < _dstorm> Yeah, we should wait a bit.
12:24 < smita786> on my ubuntu system, standard archive manager is able to compress/decomress xz files
12:25 < ibennetch> thanks smita786
12:25 < _dstorm> thanks smita786
12:25 < ibennetch> Okay, let's table that item for a few months and revisit it later this year.
12:25 < ibennetch> Moving on to the voice commands.
12:25 < udan11> I will look into it. Maybe I can continue work on it.
12:26 < ibennetch> I made my statement on the mailing list; I don't desire to include this.
12:26 < ibennetch> Thanks udan11
12:26 < Marc9> I also don't see the point of running phpMyAdmin with voice commands
12:27 < smita786> yeah I agree with Marc
12:27 < zixtor> I tend to agree with Issac on voice commands limited utility..
12:27 < Marc9> Also, the potential for errors is great
12:27 < _dstorm> Problem would increase with different languages
12:28 < Marc9> _dstorm yes
12:29 < ibennetch> So we can close this voice command RFE?
12:29 < Marc9> yes, with the argument of limited usefulness
12:29 < _dstorm> I think so
12:29 < zixtor> Yes, sure, seems quite out of scope..
12:29 < ibennetch> Marc9: Do you mind closing the tracker item and making the comment?
12:29 < Marc9> OK
12:30 < ibennetch> Thanks. Next: Plain English configuration options
12:31 < Marc9> Yes. I always found clumsy to be using script names here
12:31 < _dstorm> Its worth implementing
12:31 < ibennetch> I have a question; what happens if the user is not using the English version?
12:32 < _dstorm> configuration would be english anyways
12:32 < Marc9> yes, we already have other English values in the config
12:32 < Marc9> also, it would be in a dropdown, non-translatable
12:33 < Marc9> (I mean, in Settings and setup)
12:33 < ibennetch> As long as we all agree about keeping it in English, then I agree. I wouldn't want to get in to looking for translated strings here
12:33 < Marc9> we already have content-id, id-content, etc
12:34 < Marc9> ibennetch do you feel this could be a good replacement for your GSoC ideas list ?
12:34 < ibennetch> Seems everyone is in agreement with this proposal.
12:34 < ibennetch> Can we discuss in the tracker what the best names for each item are so as to keep the meeting moving?
12:34 < ibennetch> Yes Marc9 I think that it should fill approximately the same amount of time.
12:35 < Marc9> ibennetch we could continue the discussion in the tracker itself
12:36 < Marc9> who will ask the applicants?
12:36 < ibennetch> I'll ask the students to modify their timelines accordingly.
12:36 < ibennetch> RFE Export non permanent settings to PHP
12:36 < Marc9> I don't really see the point on this one
12:37 < Marc9> for me "experiment with settings and would like to make some of them permanent" is not a good justification
12:38 < smita786> yeah I agree
12:38 < zixtor> If I understand correctly, in case of no pmadb, it is to keep interface settings and config.inc.php settings in sync?
12:39 < Marc9> zixtor, probably, but we already offer other ways to save these settings
12:39 < zixtor> I mean to transfer interface settings into php?
12:39 < zixtor> but in php they can be in sync with config.inc.php
12:39 < ibennetch> I don't see a problem with having a link to "Download user settings as config.inc.php"
12:40 < Marc9> we already have a way to export/import as file
12:40 < ibennetch> But much more than that (keeping the two in sync, for instance) is asking a lot
12:40 < ibennetch> I thought that was only JSON?
12:40 < ibennetch> I haven't looked, I admit
12:40 < ibennetch> 20 minutes remaining
12:40 < Marc9> but the user can experiment, save file #1, experiment, save #2, import when he wants
12:42 < Marc9> Our official guideline is to use the configuration storage
12:42 < ibennetch> I just did download a JSON file, which would require some work to put in to a config.inc.php. I think it's reasonable to also offer a direct download of a file to plug in to config.inc.php.
12:42 < ibennetch> Right, but what if they wish to make their configuration storage in to their config.inc.php?
12:43 < zixtor> Yeah, but not all users use configuration storage
12:43 < ibennetch> I agree that in Olaf's case it's rare for a user to customize their setup with no configuration storage configured, but think we can provide a way to "export" their configuration storage data to a config.inc.php.
12:44 < Marc9> Well, this user could use the /setup interface to build a proper config file
12:44 < zixtor> Agreed, we should allow to download it as config.inc.php and just overwrite the existing one
12:44 < ibennetch> Hm, that is a good point as well
12:45 < ibennetch> To be clear, I'm not thinking about replacing config.inc.php on the server, but rather letting the user create one locally. But then, that's a direct replacement for /setup/ as Marc points out.
12:45 < zixtor> I mean if user wishes to overwrite by copying.
12:45 < Marc9> The /setup interface permits to play with config.inc.php, download, etc
12:45 < zixtor> Marc9: yes that seems sufficient as well
12:45 < Marc9> So, why duplicate /setup ?
12:47 < Marc9> If you agree, I could suggest this to Olaf
12:47 < zixtor> Ok, please do.
12:48 < smita786> I agree as well
12:48 < ibennetch> I appreciate Olaf's suggestions but in this case I think it's an edge case that's not likely to be very common.
12:49 < Marc9> Done
12:49 < ibennetch> RFE allow changing the keyboard shortcut for console
12:49 < ibennetch> Any comments about this?
12:50 < zixtor> I don't see a problem with this.
12:50 < ibennetch> I think the current alt-ctrl-c is suitable and don't see a need to add a configuration directive for it.
12:50 < Marc9> I don't see the need for this to be configurable
12:51 < Marc9> zixtor, do you mean it should be configurable?
12:52 < ibennetch> About 8 minutes remain in the scheduled time.
12:52 < zixtor> Marc9: I don't have strong opinion for it, so I am okay if we decide against it..
12:52 < _dstorm> Making it configurable will have lot of challenges like how will you define multi key combinations in configuration and listen those keys in javascript
12:53 < zixtor> If we wanted to, we could allow some preset options
12:53 < ibennetch> _dstorm: yes, I was considering how we could account for those combinations.
12:53 < Marc9> I suggest, let's close this RFE and see if it comes back
12:54 < ibennetch> I didn't get too far :)
12:54 < zixtor> But as others suggest, its not quite desirable, so I think we can close it..
12:54 < ibennetch> I'm fine with closing it and seeing what happens
12:54 < ibennetch> RFE display binary as hex/string
12:55 < ibennetch> I guess we should bring this back
12:55 < Marc9> I suggest to postpone this one to the next meeting
12:55 < Marc9> and talk about mod_security
12:55 < ibennetch> I'm okay with that
12:56 < zixtor> Looking at the user's reasoning, it seems like we should allow it
12:56 < Marc9> zixtor, I feel the same
12:56 < zixtor> Ok sure
12:56 < _dstorm> Lets postpone it then.
12:56 < smita786> Yeah I also think we should bring it back
12:56 < ibennetch> Then I think we have an agreement that it should come back, but perhaps we need to dicuss issues related to it further in the tracker
12:56 < _dstorm> I have concerns with editing it in string form
12:56 < ibennetch> *discuss*
12:57 < ibennetch> Because the reason it was removed was to protect the users
12:57 < ibennetch> I think the mod_security thing is outside of our scope. It's an old rule set causing problems, and I don't see a point to us changing a library to accomodate.
12:57 < _dstorm> We can display it in string but then we should disable inline editing for it
12:57 < ibennetch> Even though it's just renaming
12:57 < zixtor> About .cookie, I think it's not quite our problem to handle.
12:58 < Marc9> ibennetch, also if someone is running an old ruleset, it's their problem
12:58 < Marc9> 5 years old
12:58 < ibennetch> About two minutes to go.
12:58 < Marc9> and the user knows the solution ;)
12:58 < _dstorm> Well if renaming solves this issue I dont mind renaming it
12:59 < ibennetch> _dstorm: can you make that comment in the tracker so whoever fixes it can see that comment about disabling inline editing?
12:59 < _dstorm> Sure.
12:59 < ibennetch> Renaming it would fix the problem, but this is the first report of trouble for an issue that's been _fixed_ for about five years.
12:59 < Marc9> renaming it will cause problems when upgrading this library
12:59 < ibennetch> So I'm split on whether this is our problem
12:59 < Marc9> because we have an old jquery.cookie.js
13:00 < Marc9> but the new one has the same name
13:00 < _dstorm> In that case, lets keep it as it is
13:00 < Marc9> I agree
13:00 < zixtor> Indeed
13:01 < Marc9> Thanks everyone for your excellent participation
13:02 < ibennetch> Thank you, very much progress was made today.
13:02 < ibennetch> This ends the official meeting.