2015 08_Meeting_IRC_Log

<Marc99> Beginning of team meeting
<Marc99> 1. Add support for xz compression
<Marc99> Has anyone seen progress on this module?
<dstorm> no
<zixtor> Sorry, I am not aware of any progress about it.
* Hugues_ (020c6f93@gateway/web/freenode/ip.2.12.111.147) vient de rentrer
<Hugues_> Hi.
<Marc99> Hello Hugues_
<Hugues_> How are you?
<Marc99> So the idea was that this module not being maintained anymore, it's unclear we should use it
* Marc99 is fine
<Hugues_> Oups, already started. Which subject are you talking about please?
<Marc99> item 1
<zixtor> Looking at April meeting log, it seems nobody committed to seriously pursue xz progress, or maybe I am missing some
* nijel (~nijel@185.47.222.168) vient de rentrer
<nijel> Hi, sorry for being late
<Marc99> The big point being that this module is not officially in PHP
<Marc99> Hi nijel
<ibennetch-mobile> I was just wondering myself if we should have someone reach out to the author
<Marc99> The author is dead
<zixtor> yeah
<Marc99> as in physically dead
<ibennetch-mobile> Ah, yes – I remember that now. Thanks.
<dstorm> I don't think that we should use it. What if it breaks with new versions of php?
<Marc99> until the PHP community decides to implement this, I would abandon the idea of using this older module
<nijel> I agree to ignore it until there is native support in php
<ibennetch-mobile> Yeah that makes the most sense.
<Marc99> OK
<Marc99> 2. proposal to close issues
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/5250
<dstorm> I am fine with closing it.
<nijel> I've commented few ones which I think should stay open, for rest I agree with closing.
<Marc99> I believe we should look at them one by one in this meeting
* smita786 (4a7d3f21@gateway/web/freenode/ip.74.125.63.33) vient de rentrer
<Marc99> hello smita786
<smita786> Hi Marc
<nijel> Hi smita786
<Marc99> so anyone against closing this one?
<smita786> Hi Michal and team
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/5376
<ibennetch-mobile> I would be OK with adding it, but there hasn't been a lot of interest and no developer has he been able to work on it. I'm OK to close.
<ibennetch-mobile> sorry, my comment was for the previous issue.
<ibennetch-mobile> 5376 I have no opinion on.
<zixtor> I am also okay with closing 5376
<Marc99> 5376 not much interest on this one
<Marc99> tell me if I'm too fast :)
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/5612
<dstorm> I am ok to close it
<ibennetch-mobile> I have concerns about licensing and interoperability. Unless the workbench folks give permission and share and implementation details, I don't think we should do 5612
<Hugues_> 5376, can't it be solved before the import by modifying the file? Would say: OK to close.
<ibennetch-mobile> The speed is good; I just type too slow for the first issue ;)
<cariveri> Hi. does any one know where phpmyadmin might log errors to?
<Marc99> 5612 I suspect users of workbench and of phpMyAdmin are two distinct groups, more or less
<Hugues_> Hum, I don't know if they are the same.
<Marc99> cariveri for support visit https://www.phpmyadmin.net and click on Support
<Hugues_> But the idea doesn't seem so bad.
<Marc99> I agree with ibennetch-mobile
<nijel> idea doesn't sound bad, but I don't see much users for this and the code will be probably quite hard to implement (given there is no documentation)
<dstorm> I believe if someone is using workbench to create diagram then he can use the same to create the database.
<Marc99> Hugues_ we have to prioritize so implement ideas that seem good, not just "not bad"
<Marc99> dstorm good point
<Marc99> no strong feeling to keep this one?
<ibennetch-mobile> No
<dstorm> No
<nijel> no
<Hugues_> dstorm,s argument is OK to me.
<Hugues_> No
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/5827
<dstorm> Adding to my argument, they can export SQL from it as well.
<Marc99> nijel got a point here
<Marc99> did you mean "pointing" ?
<nijel> yes, already fixed that ;-)
<Marc99> did you mean "arbitrarily adding any database"?
<Hugues_> I agree with the feature and the nijel's answer!
<nijel> no, only tables, adding whole database with all tables is IMHO too much ...
<Hugues_> Why database?
<Hugues_> Only the tables of other DB. Not the whole DB.
<zixtor> Another point mentioned is that we already have same ability in Relation View, so not much use to duplicate and clutter in designer
<Marc99> I thought that the designer was already showing all FK relations
<Marc99> zixtor right but there is a general overlap between relation view and designer
<nijel> I thought it shows only ones in current database, but I might be wrong....
<Marc99> nijel I see your point, I misunderstood
<zixtor> Marc99: indeed but I still see it as additional duplication ;)
<Marc99> so you meant "Automatically include all tables of other databases where foreign keys of current database are pointing" ?
<Marc99> zixtor true
<Marc99> so let's keep this one open
<ibennetch> Right now I think we have Relation view and Designer as two different ways to accomplish the same thing. We probably should add this somehow to designer since Relation view can do it. I don't think suggesting people use Relation view for that part is the best solution.
<ibennetch> [Also, I'm no longer mobile :) ]
* ujjain a quitté (Read error: Connection reset by peer)
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/5881
<Marc99> see my comment about it not being popular
<zixtor> fine for me to keep open 5827
* ibennetch-mobile a quitté (Quit: Colloquy for iPhone - https://colloquy.mobi)
<ibennetch> Not popular is an understatement :) Okay with me to close
<nijel> I agree - also nobody additional has asked for this feature in almost 6 years
<dstorm> I am fine with closing it.
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/6098
<ibennetch> I'm okay with this.
<Marc99> okay to do what?
<ibennetch> I like having several themes available.
<Marc99> there is a canyon-something theme possibly coming
<ibennetch> I was vague -- I'm okay with fixing up Paradice
<Marc99> but we usually rely on the community for themes
<ibennetch> (My fault for not being more clear)
<Marc99> Also, Paradice made more sense, before pmahomme
<Hugues_> But would the community "fix" the theme?
<ibennetch> True, but there hasn't been a lot of 4.0 compatible themes.
<dstorm> I guess we would be fixing it for phpMyAdmin 4.4 or above and not for 3.5
<nijel> I don't think we should be more active in maintaining contributed themes, maybe just leave it open for newbies (see last point of meeting)
<Marc99> Hugues_ in the past, the Paradice developer submitted updates
<ibennetch> Do we know about how long the theme fixup took earlier this year?
<ibennetch> (a few hours, days, etc?)
<Marc99> I don't mind leaving this one open (but I just renamed it)
<nijel> ibennetch: I think Madhura will know
<Marc99> (don't forget we have an issue about developing a theme tool)
<ibennetch> Anyway, I'm okay with keeping it open for now and moving on with the meeting, if that's what you wish
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/6179
* udan11 (~udan11@92.80.172.14) vient de rentrer
* udan11 (~udan11@92.80.172.14) est parti
* udan11 (~udan11@92.80.172.14) vient de rentrer
<Marc99> hello Dan
<udan11> Hello
<udan11> sorry for being late
<nijel> 6179 - the performance penalty is too big, close
<zixtor> I agree
<ibennetch> I get the user's point but I agree with nijel (and Marc) -- I vote to close
* Marc99 agrees by default to close since I proposed them :)
<Hugues_> I disagree. :/
<Hugues_> I vote to keep it open.
* _dstorm (~dstorm@14.140.151.110) vient de rentrer
<Hugues_> This might be a configuration variable.
<Marc99> Hugues_ but suppose a vendor sets it to true, we'll have performance reports
<Marc99> (a vendor or an ISP)
<Hugues_> Can't we inform about the performance issue with large DB number?
<Marc99> experience shows that people are reluctant to RTFM
<zixtor> :)
* dstorm a quitté (Ping timeout: 256 seconds)
<Marc99> So we have: close = 3, open = 1, correct?
<Hugues_> Yes, I think so.
<ibennetch> The configuration directive would be okay with me for performance
<Hugues_> Thath's what I was checking. :)
<Marc99> other opinions/votes?
<ibennetch> But I still don't really think it's worth the time to implement.
<Marc99> close=3, open=2
<udan11> can't we have multiple configurations level?
<udan11> like 1 = enabled any time
<smita786> I also like the idea of having config option
<udan11> 2 = enabled only if database number is < 50
<udan11> 0 = disabled completely
<smita786> with warning that it might affect performance
<Hugues_> I like the idea. :)
<Marc99> udan11 it's also a matter of the number of tables
<udan11> database + table number < 50
<udan11> :)
<udan11> by default, it would be 0 or 2
<Hugues_> What's important? Number of entities, right?
<nijel> thinking more about it, why it is actually a performance problem? it's stored in same IS table as list of tables, so getting both should be matter of one SQL query...
<bansod_deven> I like udan11 's idea, too.
<Hugues_> nijel: I didn't want to talk about this, because I don't know/remember the query, but I agree.
<Marc99> nijel well we did not achieve a good performance but by letting this open, the implementer might find some way
<udan11> maybe some caching can be done too?
<Hugues_> Maybe the performance issue is linked to display.
<Marc99> no the performance hit was on the MySQL server
<Marc99> issue reopened :)
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/6295
<Marc99> too limited use case
<ibennetch> I thought this was an okay idea, but Madhura hinted that it might be too much work. He knows better than me so closing it is okay.
<nijel> I think showing MySQL error to user should be good enough in this case
<ibennetch> yeah, it's the same error they'd get on the command line anyway.
<Marc99> other opinions?
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/9419
<Hugues_> I agree to close it.
<Marc99> 9419 we got a late comment by Michal so we can keep it open
<Hugues_> OK.
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/9548
<ibennetch> I agree to keep 9419 open.
<nijel> can be closed IMHO
<Marc99> 9548 I never imported in XML anyway
<_dstorm> I agree to close it
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/9673
<Marc99> recent comment by Michal, let's keep it open
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/9887
<Marc99> let's keep it open (comment by Michal)
<nijel> ...again disruptive comment from Michal ;-)
<ibennetch> ha
<zixtor> well it's facilitating
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/10694
<udan11> I think this one is invalid.
<Marc99> udan11 not being able to reproduce
<udan11> I had no issues configuring mod_proxy.
<nijel> most like server setup problem, close
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/10920
<Marc99> no feedback
<Marc99> (I mean in the ticket)
<nijel> yes, close
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/11377
<Marc99> random segfault is not our business
* dstorm (~dstorm@14.140.151.110) vient de rentrer
<ibennetch> Well, if it's caused by our code we should fix it, but there aren't other reports of this from other users.
<nijel> segfault is clearly a PHP bug, even if we would be doing something wrong
<Marc99> nijel agreed
<udan11> I guess some cheap hack could be used to patch it, once we track down the problem
<Marc99> udan11 it's random
<ibennetch> It's a good point; I was thinking of other times we work around PHP bugs but maybe it's okay to close this.
<Marc99> https://github.com/phpmyadmin/phpmyadmin/issues/11381
<Marc99> font size means font size, right?
<Hugues_> Ahah, yes.
<Hugues_> What's the point?
<nijel> I think we should work towards default theme being usable on high DPI screens, these will get more usual...
<ibennetch> nijel: that's a good suggestion.
<Marc99> nijel but a browser zoom does the job, right?
<Hugues_> Is he talking about OS font size or browser font size?
* _dstorm a quitté (Ping timeout: 245 seconds)
<dstorm> I agree with nijel
<udan11> Marc99, sort of
<udan11> icons will look bad
<ibennetch> I agree with Marc99 though that browser zoom should help here.
<nijel> browser zoom will sort of work, but you will get ugly icons
<Marc99> nijel, yes but this is another problem
<Hugues_> I don't have a 4K display, but I got no issue zooming to more than 263%.
<ibennetch> Yes, icons look bad, but unless we create the theme with bigger icons, this feature request won't help with that.
<Marc99> talking about the font size drop-down
<dstorm> Maybe we should move towards SVG icons
<Marc99> should icon resize when the font size drop-down is used?
<Marc99> I say nope
<Hugues_> Agree about the icons quality. Maybe we should thing about icons like fontawesome.
<ibennetch> Having the font size drop down change the icon size won't make them look any better than browser zoom, unless we make icons vector or just larger in the theme.
<Hugues_> Those which are resizable.
<nijel> but the font size dropdown is definitely not a solution to this
<udan11> use fontawesome for icons and then "Font size" would be the right name for it :D
<Marc99> ok to close?
<ibennetch> Maybe we should rename this feature request to something like "icon support for large displays"
<Marc99> ibennetch I would say create another issue for that
<ibennetch> Okay, that's fine.
<ibennetch> I can create the new ticket.
<Marc99> Minimum disclosure mode
<Hugues_> Should we talk about using SVG icons?
<Marc99> Hugues_ another meeting perhaps
<ibennetch> A lot of the proposed changes are SQL level things; a user with SQL access can list databases, show processes, etc.
<ibennetch> Hiding server name, client version, used extensions, etc is another matter and may be okay.
<Marc99> I am also in favor of a minimum disclosure mode
<ibennetch> Not sure I see a point, and this is quite an old request, but there may be something to work onhere.
<ibennetch> It has been one hour but I'm okay to stay for a few more minutes.
<Marc99> I can also stay
<nijel> I can stay as well
<Marc99> other opinions on this mode?
<dstorm> I think we should keep it open. Some hosting providers might want to hide few details from the user.
<nijel> as for the minimum disclosure mode, I'm not sure if we can really limit the information user can get
<Hugues_> I had like to see a mockup...
<Marc99> nijel it would be mostly on the main page, but some info can obviously be fetched by other means
<nijel> but stuff like using verbose server name sounds more like something what should be default
<Marc99> nijel yes
<Marc99> moving on?
<nijel> ok
<Marc99> mailing lists on sf.net: hide them all?
<nijel> okay for me
<dstorm> Yes
<Marc99> I am grateful for the new lists!
<ibennetch> It's okay to delete them. I'll even do it. I left them (though closed to new posts) in case something went wrong with the migration, but now it's fine by me to close it.
<Hugues_> Are the mails available somewhere else?
<ibennetch> (or you can do it or whatever, doesn't matter)
<Marc99> Hugues_ they were transferred
<Hugues_> OK to remove so. :)
<Marc99> Newbies issues
<nijel> Hugues_: yes, the archive is at https://lists.phpmyadmin.net/pipermail/developers/
<Hugues_> I completely agree with the newbie issue idea!
<ibennetch> I suggest a "newbie" tag in the tracker.
<dstorm> I agree with newbie issues.
<Marc99> I agree to but I would put a time limit on this
<ibennetch> Which is probably exactly what you meant anyway, but it's a good idea.
<nijel> great, now we just need to find issues ;-)
<nijel> we can basically tag anything what we think does not need deep knowledge of our codebase
<Marc99> there is also the urgency matter
<Hugues_> And so add link to https://wiki.phpmyadmin.net/pma/Junior
<nijel> it can still be fixed by us, but it's just that new people have some things to look on without going through all the bugs...
<Marc99> nijel we should not fix an issue tagged "newbie"
<Hugues_> Agree with new tag.
<Hugues_> Why?
<Marc99> to let newbies have something to do
<Marc99> I mean, if it's urgent, don't tag newbie
<nijel> I don't want these bugs to live forever if nobody takes them...
<Marc99> nijel that's why I suggested a time limit
<nijel> indeed it should be low priority stuff
<Marc99> after the limit expires, we untag
<udan11> https://github.com/phpmyadmin/phpmyadmin/issues/6315 should this be closed too?
<Hugues_> Agree with easy and not-emergency issues.
<udan11> because #1653 is
<Marc99> udan11 done
<Marc99> about time limit?
<Hugues_> 1 month?
<Marc99> maybe just before a GSoC the limit could be longer because there will be more newbies
<nijel> I don't think we need a limit, some of the issues can live for really long
<Hugues_> It might be a mess to check it.
<Marc99> I'm fine with 1 month, and longer before GSoC selection
<Hugues_> How long before GSoc?
<Marc99> We can try without a limit, anyway we have a backlog of years
* cariveri a quitté (Ping timeout: 264 seconds)
<nijel> If add now tag to issue open in 2012, what exactly should happen in a month?
<Marc99> nijel my idea was that in a month we untag
<dstorm> Why do we want to untag
<ibennetch> About the high resolution display feature request: https://github.com/phpmyadmin/phpmyadmin/issues/11392 is the new issue.
<Marc99> dstorm so that the issue is fixed by the team
<dstorm> team can fix issue without untagging if that issue has stayed open for long.
<Marc99> dstorm well the newbie tag on a closed issue won't help newbies
<Marc99> ibennetch thanks
<nijel> I also see no need to remove tag ... once somebody starts working on that assigns himself the issue what makes it quite clear that it is worked on
<Hugues_> after 1 month, don't untag, solve it ourself if we have time.
<dstorm> they have another filter issue:opened to limit
<nijel> also closed newbie tagged issues won't appear on search (unless you ask for that)
<Marc99> anyway the first step is to fine newbie issues
<Marc99> to find
<udan11> #11392 :)
<Marc99> other opinions on the newbie  tag?
<Marc99> let's start simple, just a tag and we leave them to newbies
<Hugues_> Agree.
<udan11> #6337 theme-related too
<Marc99> can we end the meeting?
<Hugues_> OK for me.
<ibennetch> Yes.
<Marc99> END OF MEETING