2015 08_Meeting_IRC_Log

Michal Čihař edited this page Apr 14, 2016 · 2 revisions
<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 http://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 - http://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 http://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
Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.