2015 10_Meeting_IRC_Log

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.116.203.72.142] 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 [~dstorm@122.170.226.189] 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 [~androirc@109.166.128.102] has joined #phpmyadmin
08:34 < ibennetch> Hi udan11
08:34 < udan11> Hi
08:35 -!- glowdemon1 [glowdemon1@d51a53f8b.access.telenet.be] 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 [~dstorm@122.170.226.189] has quit [Read error: Connection reset by peer]
08:47 -!- dstorm [~dstorm@122.170.226.189] 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 [~androirc@109.166.128.102] 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 [~androirc@109.166.129.114] 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 [~kvirc@220.240.147.39] 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