Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
08:00 < ibennetch> Good morning/afternoon/day/evening/night; it's time for the monthly phpMyAdmin developer meeting. The log will be posted to the wiki shortly after the end of the meeting. 08:00 -!- Irssi: #phpmyadmin: Total of 38 nicks [1 ops, 0 halfops, 0 voices, 37 normal] 08:00 < Marc9> Is madhuracj there? 08:01 < ibennetch> Marc has a proposal about 4.5.1. 08:02 < Marc9> A bugfix freeze 08:02 < ibennetch> For a week before releasing. I think this is a good idea. 08:02 < nijel> Freeze looks like a good idea to me. 08:02 < ibennetch> I normally work with/ test on master anyway, as I bet most developers do, so I'm not sure how much extra testing we'll get, but this is the responsible decision. 08:03 < Marc9> I will concentrate my testing on this frozen branch 08:03 < Marc9> Since we no longer have rc for bugfix releases 08:04 < ibennetch> Sure, when there's a freeze that's a good idea to concentrate testing. 08:05 -!- zixtor [74cb488e@gateway/web/freenode/ip.126.96.36.199] has joined #phpmyadmin 08:05 < ibennetch> So it looks like no one objects to that plan. Shall we postpone the contractor work repartition discussion until more people arrive? 08:05 < Marc9> Hi zixtor 08:05 < ibennetch> We could discuss GSoC 2016 for a bit 08:05 < ibennetch> Hello zixtor 08:05 < zixtor> Hi Marc and all 08:05 < Marc9> ibennetch yes let's postpone, we need at least the two contractors :) 08:05 < ibennetch> :) 08:05 < ibennetch> So I would love to do GSoC again 08:05 < zixtor> right 08:06 < Marc9> me too but for what goal? 08:06 < ibennetch> I have some concerns about finding enough tasks to put together a feature improvement project like I did this past year, so personally I may not have a chance to mentor -- but I think the project should attempt to participate 08:06 < ibennetch> Well, that's a good question :) 08:07 < nijel> I'd also like to participate in GSoC, IMHO it's really good for attracting new people to the project. On the other side, we should really start preparing the projects now as it's getting harder and harder to have reasonable ones... 08:07 -!- dstorm [~email@example.com] has joined #phpmyadmin 08:07 < zixtor> I too feel, feature based GSoC project would be difficult to set up. 08:07 < Marc9> Hello dstorm 08:07 < dstorm> Hi Marc 08:07 < ibennetch> Since we have two contractors working through the issue tracker there are fewer issues, but the OOP and refactoring is still relevant 08:07 < ibennetch> Hi dstorm 08:08 < Marc9> zixtor I believe we could build one list of small features, but do we want to block contractors from working on them? 08:08 < ibennetch> Automated testing 08:08 -!- SPF|Cloud [uid11755@wikipedia/Southparkfan] has joined #phpmyadmin 08:08 < zixtor> Marc9: yeah contractors are a bigger factor to consider this time :) 08:08 < Marc9> ibennetch one contractor expressed his interest for the refactoring 08:09 < Marc9> I don't think we can count on getting original proposals from students 08:09 < zixtor> even with OOP and refactoring, it would be difficult to set up a project without accounting for the contractors' work 08:09 < Marc9> zixtor what do you mean? 08:09 < ibennetch> I agree about the limited original proposals 08:09 < nijel> zixtor: I don't think it's bigger factor, AFAIK it still one fulltime contract in total... 08:10 < Marc9> nijel would you be comfortable with freezing a few feature requests for a student? 08:11 < nijel> Marc9: I don't see problem with that 08:11 < Marc9> "a few" -> enough for 12 weeks 08:11 < zixtor> nijel: Marc9: I mean to decide on some script or components for GSoC work, the contract refactoring plan would need to be considered 08:11 < ibennetch> I think we should apply but we should probably expect to have fewer projects than last year. 08:11 -!- Warped [~Warped@unaffiliated/warped] has joined #phpmyadmin 08:11 < Marc9> ibennetch right 08:12 < zixtor> I agree that we should apply 08:12 < nijel> looking at this year, we still have synchronization and error reporting server ideas open... 08:13 < Marc9> not sure we should leave synchronization there 08:14 < zixtor> nijel: Will there be issues left with error reporting server by next GSoC? 08:14 < nijel> indeed it's quite complex task... 08:15 < nijel> zixtor: probably yes - I don't think Smita has much time for that and for myself I find more important to work on our codebase than on the server... 08:15 < ibennetch> Are we ready to move on to the next topic? 08:15 < Marc9> yes 08:15 < ibennetch> Optimize browse space 08:15 < ibennetch> Issue 11507 08:16 < Marc9> I only see the "sort by keys" moving issue 08:16 < ibennetch> There is quite some space used here; in the first picture the notice about using the bookmark and the query time and the query itself... 08:17 < nijel> ...also lot of spacing around the SQL query 08:17 < Marc9> About the notices, they could be regrouped but what about the background color? 08:17 < ibennetch> I would say to leave this open and if someone wants to start improvements, they can. 08:18 < Marc9> ibennetch I would like a decision about "sort by keys" 08:18 < zixtor> I agree to move "sort by keys" 08:18 < ibennetch> The problem about moving things around is that things aren't related -- we currently have one line per item, a paragraph if you will, and grouping things on one line helps with spacing but not readability 08:18 < Marc9> ibennetch and I would prefer something more concrete than "optimize" 08:19 < Marc9> it's true that "filter rows" is somewhat related to row navigating 08:19 < Marc9> with ibennetch's comment I no longer think we should move "sort by keys" 08:20 < zixtor> To me they are all just like filters on the table displayed below 08:20 < zixtor> so no problem for me with moving 08:20 < Marc9> sorting does not filter 08:21 < ibennetch> We could move sort by key to the right of filter rows, it all is sort of about how the data is displayed even though it's filtering vs sorting. 08:21 < nijel> the navigation bar is also shown at bottom, while to sorting is not 08:22 < ibennetch> What about changing the style of the bookmark notice -- if we make that much smaller we could get some space back. 08:22 < zixtor> Marc9: indeed it doesn't. By filter I didn't mean a strict filter on static result :) 08:22 < ibennetch> nijel is right about there being a lot of space around the SQL query, we should be able to make that take up less space also 08:23 < Marc9> ibennetch, so this space removal could be the priority 08:24 < nijel> okay, let's make separate issue for that (as we seem to agree that it's good idea) 08:24 < ibennetch> Right 08:24 < ibennetch> I'm also not sure whether we need the bookmark notice at all. 08:25 < Marc9> ibennetch we need it IMO 08:25 < ibennetch> oh, it's the default -- yes we do 08:25 < ibennetch> Yep, that's my mistake. 08:25 < Marc9> about sort by key ? 08:26 -!- Warped [~Warped@unaffiliated/warped] has quit [Quit: ChatZilla 0.9.92 [Firefox 41.0.1/20150929144111]] 08:26 < nijel> Marc9: having it on separate line is IMHO wasting space 08:26 < Marc9> (the filter rows input box could be shortened) 08:26 < ibennetch> I think we should move it. 08:27 < Marc9> ok to move then 08:27 < nijel> as for the spacing around SQL query, please review: https://github.com/phpmyadmin/phpmyadmin/pull/11573 08:28 < Marc9> after moving sort by keys and applying Michal's PR, this issue would be closed? 08:29 < ibennetch> I think so yes 08:30 < nijel> I think yes, but once we do it we should ask reporter as well :-) 08:31 < Marc9> nijel sure 08:32 < Marc9> how about replacing ascending/descending with ASC/DESC ? 08:32 < ibennetch> Okay, then how about Packagist? 08:32 < Marc9> these are keywords 08:32 < ibennetch> Oh, not yet about Packagist 08:32 < Marc9> almost :) 08:32 < zixtor> ASC/DESC fine for me 08:32 < Marc9> this also reduces space 08:33 < Marc9> I'll do the sort by key thing 08:33 < Marc9> that's for master 08:34 < nijel> okay 08:34 < ibennetch> I'm indifferent about ASC/DESC. I like having it fully spelled out but if space is an issue then the keyword is okay. 08:34 < ibennetch> On my screen it doesn't seem to be an issue, I'm wide enough, but there are more users than just me :) 08:34 -!- udan11 [~firstname.lastname@example.org] has joined #phpmyadmin 08:34 < ibennetch> Hi udan11 08:34 < udan11> Hi 08:35 -!- glowdemon1 [email@example.com] has quit [Ping timeout: 250 seconds] 08:35 < udan11> Sorry for being late. Busy with uni. 08:36 < ibennetch> No worries. We're nearly done working through the Optimize Browse Space issue at the moment. Trying to make more efficient use of the space we have 08:37 < Marc9> aren't we done with optimize space? 08:39 < nijel> I think we've exhausted this topic 08:39 < ibennetch> We were on the ASC/DESC which is part of optimizing, but now we're ready for packagist :) 08:39 < ibennetch> nijel: has nicely summarized it at https://github.com/phpmyadmin/phpmyadmin/issues/11508 08:39 < Marc9> nijel a quick question about tags: what would replace the QA and MAINT tags? 08:40 < Marc9> (I understand about replacing RELEASE tags) 08:41 < nijel> Marc9: not sure, I didn't look at what is usually used elsewhere 08:41 < udan11> I believe we can keep them as they are now 08:41 < nijel> the current naming comes from some ancient PEAR standard for CVS and is mostly reasoned by limits CVS had on tag names 08:42 < udan11> They will be considered development branches. 08:42 < Marc9> Suggestion #1 looks the best to me 08:43 < Marc9> Keep current release process and tagging and promote own composer repository - harder to setup by users, but we can use generated tarballs instead of git snapshots in own repository. All this needs is a documentation. 08:43 < nijel> but having branch named like 4.5.x would make it quite clear and readable 08:44 < Marc9> nijel I agree with such naming, but you said it's not enough 08:44 < dstorm> I agree here with nijel 08:44 < ibennetch> I agree, I'm okay with changing our tag naming scheme but I'm not sure it's enough for Packagist 08:47 < udan11> Marc9, it is enough, but not ideal. Locales and documentation won't be included. 08:47 < ibennetch> I'm not fond of incorporating all the generated files in to the repository just to make Packagist/Composer happy. 08:47 < Marc9> If we have a different repo just for composer, wouldn't it be difficult to keep it in sync with the existing one? 08:47 -!- dstorm [~firstname.lastname@example.org] has quit [Read error: Connection reset by peer] 08:47 -!- dstorm [~email@example.com] has joined #phpmyadmin 08:49 < nijel> the composer repository is json file listing releases (https://www.phpmyadmin.net/packages.json), it's generated in a same way as our website 08:50 -!- udan11 [~firstname.lastname@example.org] has quit [Read error: Connection reset by peer] 08:50 < Marc9> ah, it's not a git repository then? 08:50 < Marc9> sorry for the confusion 08:51 -!- udan1107 [~email@example.com] has joined #phpmyadmin 08:51 -!- udan1107 is now known as _udan11 08:51 < nijel> well we could create git repository with content of release files as well (that's what in https://github.com/wp-cloud/phpmyadmin) 08:52 < nijel> I forgot to mention this option in the summary 08:52 < _udan11> We could create another repo with locales and documentatiob only (what is missing) from current repo and add it as an dependency. 08:53 < Marc9> What I don't like is that some users would be tempted to send pull requests against this one 08:54 < Marc9> (for issues, we have the ability of not activating them, but for PR I'm not sure) 08:55 < Marc9> PR are active on https://github.com/wp-cloud/phpmyadmin 08:59 < ibennetch> So we're having trouble arriving at a decision here 08:59 -!- glowdemon1 [glowdemon1@d51A53F8B.access.telenet.be] has joined #phpmyadmin 09:00 < ibennetch> Do we know how many people actually use the Composer version? 09:00 < Marc9> 6376 installs 09:00 < ibennetch> I don't like distributing it without locales and documentation. 09:01 < Marc9> This would be suggestion #2? 09:02 < Marc9> That's why I prefer #1 09:02 < ibennetch> Correct 09:02 < Marc9> We are talking about making changes in https://packagist.org/packages/phpmyadmin/phpmyadmin correct? 09:02 < ibennetch> I don't mind changing tags, but users should get the full install with their language 09:03 < ibennetch> I'm not clear about option 1, actually; I don't really see the shortcoming of it 09:03 < Marc9> I don't like #3 because git repo would have all the generated content 09:04 < Marc9> nijel what do you mean "harder to setup by users" ? 09:04 < ibennetch> I dislike #3 for the same reason. 09:04 < nijel> Marc9: see https://github.com/phpmyadmin/phpmyadmin/issues/11508#issuecomment-146219018 09:06 < Marc9> I don't understand, sorry 09:07 < ibennetch> So if I understand correctly, it means the user has to specify the repository URL on the command line instead of using the default one. 09:07 < ibennetch> composer create-project phpmyadmin/phpmyadmin --repository-url=https://www.phpmyadmin.net/packages.json 09:07 < ibennetch> instead of composer create-project phpmyadmin/phpmyadmin 09:07 < ibennetch> This seems like a minor inconvenience for them, frankly. 09:08 < nijel> that's how I understand it (I really didn't try), maybe _udan11 can clarify it 09:08 < Marc9> Can't this be set up in the definions on https://packagist.org/packages/phpmyadmin/phpmyadmin ? 09:08 < ibennetch> I wouldn't even mention the possibility to modify composer.json since that seems to require updating when the version changes 09:08 < Marc9> definitions 09:08 < nijel> Marc9: AFAIK it can't be specified on the packagist repository 09:09 < _udan11> We could ask Packagist.org's maintainers to add a new feature that lets us merge our repo with theirs 09:10 < _udan11> (create a issue) 09:11 < Marc9> I'm not a composer user, but do composer users agree with ibennetch's remark that it would be a minor inconvenience? 09:12 < ibennetch> Also, if we're able to do this does it really fix the problem with generated locale/documentation files? 09:13 < nijel> yes, our composer repo lists the files we've released, no git snapshots 09:13 < Marc9> Is it correct that https://packagist.org/packages/phpmyadmin/phpmyadmin be in nijel's name? Do we have a choice here? 09:14 < nijel> Marc9: it can have more maintainers, I just need to know usernames to add (you need to register there first) 09:15 < Marc9> (could we have a "phpMyAdmin team" account ?) 09:15 < Marc9> No answer for "minor inconvenience" ? 09:15 < ibennetch> It sounds to me like the best choice is to approach Packgist.org asking about adding a new feature to merge our repo with theirs. If the answer is no, then we just document the extra --repository-url option for checking out. If so, then we're in pretty good shape. 09:16 < nijel> Marc9: not sure, I've logged in with Github there, but it's probably possible to create separate account there as well... 09:16 < nijel> as for the inconvenience level I have no clue, I don't use composer either... 09:17 -!- Warped [~Warped@unaffiliated/warped] has joined #phpmyadmin 09:17 < Marc9> I agree that we can ask packagist.org but in case they say not or do not reply, we could ask on the issue 11508 itself about this minor inconvenience 09:18 < ibennetch> Okay, who can ask packagist about this feature request? 09:19 < nijel> _udan11: can you please do that? you seem to have best composer knowledge here... 09:19 < _udan11> Yes. 09:19 < ibennetch> Thanks 09:20 < _udan11> As soon as I get home. 09:20 < ibennetch> Can everyone hang out for a few more minutes to finish Marc's issue closing proposal? 09:20 < Marc9> I can 09:21 < _udan11> Yes, sure 09:21 < ibennetch> 6137 is about making a smaller distribution. 09:21 -!- madhuracj [~firstname.lastname@example.org] has quit [Ping timeout: 240 seconds] 09:22 < ibennetch> I disagree about moving files; I think we should respond about which files can be safely removed (such as un-used languages), and I'm unaware enough to know what to say about removing plugins. 09:22 < ibennetch> It seems to me that removing any porition (for instance, pdf generation) won't help much with size. 09:22 -!- glowdemon1 [glowdemon1@d51A53F8B.access.telenet.be] has quit [Ping timeout: 240 seconds] 09:22 < ibennetch> Oh, h/shee can also remove unneeded themes. 09:23 < ibennetch> he/she 09:23 < Marc9> If someone only wants english, the 7z is 5.6 MB 09:23 < nijel> ibennetch: tcpdf has 2.6 MB and can be safely removed IMHO 09:23 < ibennetch> That would help 09:23 < Marc9> nijel, removed from what exactly? 09:24 < Marc9> you mean have more download kits? 09:24 < nijel> by user if he wants to strip down the size 09:24 < ibennetch> It's a bit of an odd request; it's reasonable to expect a large install to be customizable (for instance, Windows can be installed without IIS or LibreOffice without Base), but for 19MB it seems silly 09:24 < nijel> I was more thinking about providing documentation how to strip down rather than another set of images 09:25 < Marc9> nijel ok 09:25 < ibennetch> Right, that's what I was thinking too. We don't want even more download options. 09:25 < ibennetch> Okay, maybe we can come up with some documentation about this, would we put it in the FAQ, wiki, or only reply to this ticket? 09:26 < Marc9> in the FAQ + reply on the ticket 09:26 < nijel> I agree with Marc9 here 09:27 < ibennetch> Okay, any one wish to handle this? 09:27 < ibennetch> I could work on it but not this week, and maybe not next week. 09:27 < Marc9> I suggest that we first write in the ticket suggestions for file removal, like tcpdf (they will be conditional) 09:28 < Marc9> ibennetch I would prefer you handle this, as this is doc 09:28 < ibennetch> If we remove tcpdf and someone clicks on a link requiring that, I suppose they'd get a nasty PHP error message 09:28 < Marc9> ibennetch *they* removed tcpdf :) 09:29 < ibennetch> Yes, quite righ! 09:29 < ibennetch> right 09:29 < nijel> ibennetch: it should be handled gracefully (it used to work, but I didn't test recently) 09:30 < ibennetch> Okay, let's move on then 09:30 < Marc9> ibennetch will you handle this? 09:30 < ibennetch> 6369 is Multi-query persistent console with tabbed results 09:30 < ibennetch> Yes Marc9 09:31 < Marc9> This beefed-up console would be too much IMO 09:31 < Marc9> as phpMyAdmin is UI-oriented 09:31 < ibennetch> Yeah that's my feeling also 09:31 < nijel> I agree with closing this one 09:32 < ibennetch> We could improve Console if there are specific ways that would help, but this large change is not what we're targetting 09:32 < ibennetch> Last one - 6353 Kill queries if phpMyAdmin session is expired option 09:33 < nijel> Okay to close as well, I don't see how we could do this... 09:33 < ibennetch> Agreed 09:34 < Marc9> and as nijel said, the session problem is solved 09:35 < ibennetch> Okay. I haven't seen madhura so I think we're through the agenda except for the contract developer discussion. 09:36 < Marc9> Better move that to team@ 09:37 < ibennetch> If there are no objections I think we should wrap the meeting up. Thank you all for attending and for staying late! 09:37 < nijel> there is still time to discuss this next month (I'll start in December...) 09:37 < ibennetch> True 09:38 < Marc9> I wrote to team@ because Madhura might still be absent next month 09:40 < ibennetch> Seems like something we can work out on team@ 09:40 -!- HRJ_ [uid60545@gateway/web/irccloud.com/x-jwmglglojgpdjukt] has joined #phpmyadmin 09:40 < nijel> okay :-) 09:42 < ibennetch> Marc9: can you start discussion on team@ and I'll add it to the agenda for next month in case it needs further IRC discussion? 09:43 < Marc9> ibennetch sure
Clone this wiki locally
Press h to open a hovercard with more details.