Join GitHub today
<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.126.96.36.199) 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 (~email@example.com) 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.188.8.131.52) 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 (~firstname.lastname@example.org) vient de rentrer * udan11 (~email@example.com) est parti * udan11 (~firstname.lastname@example.org) 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 (~email@example.com) 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 (~firstname.lastname@example.org) 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
Press h to open a hovercard with more details.