2015 07_Meeting_IRC_Log

09:00 < ibennetch> Hello, and welcome to the monthly meeting of the phpMyAdmin developers. Let's jump right in.
09:00 < nisargjhaveri> Hi Marc.
09:00 < nisargjhaveri> Hi everyone
09:00 < ibennetch> First up, the human readable URL proposal.
09:00 < Marc9> About this, I wonder what's the point, taking into account that we need a valid token
09:01 < Marc9> which is quite unhuman!
09:01 < zixtor> Still the hash microhistory part is quite annoying and can be well traded for HTML5 API
09:01 < zixtor> which would clean URL quite a bit
09:02 < ibennetch> I have to confess I'm not familiar with this HTML5 API, but it sounds like a good thing to implement.
09:02 < nijel> I agree with zixtor here, using HTML5 history api would be much cleaner
09:02 -!- Warped [~Warped@unaffiliated/warped] has joined #phpmyadmin
09:02 < Marc9> zixtor, should this be another feature request
09:02 < zixtor> Marc9 I think this is one part of this RFE we are discussing
09:03 < ibennetch> According to FAQ 4.8 we can already pass things like pma_username, db, and table as URL query strings.
09:04 < Marc9> ibennetch I'm not sure this is still working
09:04 < nijel> as for human URLs, I think it could work even with token stuff, we already bypass some parameters even with missing token
09:04 < zixtor> It is working I think
09:04 < ibennetch> Yeah, it still does seem to work; I tested it earlier
09:05 < Marc9> ok
09:05 < ibennetch> THought I didn't fully test it, at least pma_username and db work here :)
09:05 < zixtor> Also, would index.php/ be a good looking solution? If we are talking of prettier URLs
09:06 < nisargjhaveri> Also, about token, I don't know how exactly it works. But, can't we use any other passing mechanism, like cookie for it?
09:07 -!- chealer [~pcloutier@pdpc/supporter/student/chealer] has joined #phpmyadmin
09:07 < ibennetch> Of course the problem with FAQ 4.8 is that you're putting your username and password in the URL :\
09:07 < nisargjhaveri> And, index.php/ is not a really good solution. But I am under impression that most users have access to rewrite rules.
09:07 < zixtor> Personally, I would be content with just HTML5 API and would not go any more prettying
09:07 < Marc9> Nisarg I don't believe that we found a secure solution to avoid passing a token
09:07 < nijel> nisargjhaveri: we can not use cookie for that, that would not prevent csrf
09:08 < nijel> what might be better approach though is to require it only for POST requests and make all GET requests read only...
09:08 < Marc9> nijel this would require massive changes
09:09 < chealer> hi
09:10 < zixtor> Currently we primarily use GET requests I think in ajax..js for non-form stuff
09:10 < Marc9> zixtor what about all our links?
09:11 < nijel> Marc9: indeed, but would make lot of things easier... also per RFC 7231, the POST method should be used for any context in which a request is non-idempotent
09:11 < zixtor> Yeah right, for links we use GET requests
09:11 < chealer> in particular if $_GET is used
09:11 < ibennetch> I agree with zixtor that right now we should go to the HTML5 API but not do any more prettying. We can't require a user to have rewrite rule access, and need to prevent CSRF. We could try to move towards nijel's proposal of read-only GET requests, but I'm not sure it's worth the effort at the moment.
09:12 < zixtor> ibennetch: rightly put
09:12 < Marc9> so we keep this RFE open
09:13 < zixtor> can we open an RFE for nijel proposals
09:13 < nijel> zixtor: I will do that...
09:14 < ibennetch> Also, the URL doesn't always seem to match the current page; I'm not sure if that's related to the microhistory or not because I do see, for instance, tbl_sql *somewhere* in the URL when I'm on the SQL tab.
09:14 < ibennetch> But it's so far back in the URL that I'm not sure what page I'm actually on just by looking at the URL.
09:14 < ibennetch> Which would be interesting to improve
09:15 < zixtor> ibennetch: thats because of microhistory
09:15 < ibennetch> Great, thanks nijel for opening the second proposal.
09:15 < Marc9> ibennetch I mostly do not look at the URL :)
09:15 < ibennetch> Thanks zixtor
09:15 < ibennetch> Marc9: :)
09:15 < ibennetch> Okay, we seem to agree about this so let's move on to the pivot table
09:16 < Marc9> For this one I wrote "probably out of scope"
09:16 < zixtor> Looking at the PivotTable.js example posted by Madhura, I agree it is out of our scope, not required of us, plus the data handling limitation.
09:17 < Marc9> plus the 11 years delay ;)
09:17 < ibennetch> We try to allow users to visualize their data, but we're not a full-out data analysis tool. I agree that it's beyond the scope
09:17 < ibennetch> ha
09:17 < nijel> I also think it's out of scope
09:17 < ibennetch> Okay, great. Then about "Unite structure and relation view"
09:18 < ibennetch> I'm happy with the current system, actually.
09:18 < zixtor> I find the current tab improvement good enough :)
09:18 < Marc9> I remember when we had long vertical pages and would like to avoid that
09:18 < ibennetch> I like the tab that Madhura added and personally don't need to see the relation edit display under the table structure.
09:19 < ibennetch> One way we could improve this is to show a read-only list of existing relations under the Information area.
09:19 < ibennetch> In an expandable box like Indexes
09:19 < ibennetch> Then refer the user to the Relation View tab to edit or create them.
09:19 < Marc9> ibennetch yes but maybe users would expect this to be editable
09:21 < ibennetch> It seems no one is in favor of this, so shall we reject it and move on?
09:21 < ibennetch> Auto-updater
09:21 < zixtor> agreed
09:21 < nijel> okay
09:21 < Marc9> yes, let's reject
09:21 < ibennetch> The problem with the auto-updater is the direct filesystem access it requires.
09:22 < zixtor> I am in favor of providing this feature for users having write access.
09:22 < nijel> I think it's good idea to have something like this, even if it won't work in all cases
09:22 < nijel> see for example Piwik's documentation on this topic: https://matomo.org/docs/update/
09:23 < nisargjhaveri> Auto-updater would be nice to have!
09:23 < chealer> I agree with nijel. it has to be a best effort, we can never cover all scenarios
09:24 < Marc9> Can we imagine that the UI would make a test to see if filesystem is writable, then offer the auto-update if so?
09:24 < ibennetch> I don't feel strongly about this -- it would be nice, but only for a certain set of users.
09:24 < ibennetch> Yes, Marc9 I think that's reasonable.
09:24 < chealer> what's important is not to try something unsure and fail cryptically. ideally, don't even offer upgrading if we can detect it won't work.
09:24 < chealer> ...exactly as Marc9 said. I think that should be possible.
09:25 < Marc9> I'll reopen this RFE
09:25 < ibennetch> I could volunteer to write up a proposal of how this should work, in the wiki I suppose.
09:26 < ibennetch> If that would be helpful.
09:26 < Marc9> ibennetch, better use the current RFE
09:26 < chealer> ...and it's important to be honest about the possibilities and shortcome in marketing material.
09:26 < ibennetch> There we can discuss the various ways it could fail and prevent them :)
09:26 < Marc9> 1458
09:26 -!- madhuracj [~kvirc@123.231.124.214] has joined #phpmyadmin
09:26 < ibennetch> Okay, let's go on to the Users vs Accounts terminology.
09:26 < ibennetch> Hello madhuracj
09:26 < madhuracj> Hello everyone
09:27 < Marc9> Hi Madhura
09:27 < chealer> I only found an auto-updater in Wordpress, but I was surprised to see how well it works. I would never keep our WordPress nearly as up-to-date as it is if it wasn't for the auto-updater.
09:27 < zixtor> chealer: agreed, would keep many users up to date
09:28 < chealer> It works perfectly here (but then, I have a single install, and it's on our server).
09:28 < zixtor> lets move to next
09:28 < Marc9> Users vs account was initiated by chealer
09:28 < Marc9> As a reminder, the menu tab was Privileges
09:28 < Marc9> I suggest "User accounts"
09:29 < zixtor> long reading ;)
09:30 < Marc9> Note that bug 4973 is about two issues
09:30 < zixtor>  if I get it correctly, an Account is uniquely identified with User plus applicable Host. So I agree that we should use the word "Account" in the UI.
09:30 < Marc9> let's concentrate for now on the terminology issue
09:30 < zixtor> But I don't fully get the Anonymous user related point made in the RFE.
09:30 < chealer> thanks marc. I see there are 2 tab. the general one is titled "Users" here. but for a specific schema, the tab is titled "Privileges".
09:30 < ibennetch> I'm okay with changing to "User accounts" for the "Users" tab
09:31 < Marc9> chealer, here Privileges is the appropriate menu
09:31 < ibennetch> I'm not as sure about the specific table or database tab; as I think Privileges is a good description of what it shows (privileges on that object).
09:31 < Marc9> it's the privileges on some db
09:32 < Marc9> so, "User accounts", then under it, "Overview" and "Groups" ?
09:32 < chealer> Marc9: hum, I see a "Users" tab on demo.phpmyadmin.net, after I click the house for example
09:33 < ibennetch> I worry a bit about the size of the text.
09:33 -!- SPF|Cloud [uid11755@wikipedia/Southparkfan] has quit [Quit: Connection closed for inactivity]
09:33 < ibennetch> "User accounts" would be our longest tab here
09:34 < Marc9> chealer what's your point?
09:34 < chealer> ibennetch: I agree, I think "Accounts" would be OK even if "User accounts" is a bit clearer.
09:34 < ibennetch> On that page, we can talk about "Remove selected user accounts" or "User accounts overview", but I'm hesitant about changing the tab name
09:36 < ibennetch> For the tab only, I think "Users" is clear enough what is meant. Accounts just doesn't seem quite as clear, even though of course we're referring to the same thing I still like Users for the tab name.
09:36 < Marc9> that's why I wanted User accounts :)
09:37 < ibennetch> :)
09:37 < Marc9> also I gave a reference to MySQL manual where they clearly talk about accounts
09:38 < ibennetch> I've just tested and the space used for "User accounts" is long, but acceptable to me.
09:38 < ibennetch> I can go along with "User accounts"
09:39 < ibennetch> And yes, I realize that MySQL is making their terminology about accounts instead of users, so we should also try to keep up.
09:39 < Marc9> maybe in a future version we can remove "User" but keeping it right now is a good transition IMO
09:39 < ibennetch> So seems there's no further comment on the "User accounts" tab, should we discuss the anonymous user portion of this?
09:40 < ibennetch> Yes, good point.
09:40 < Marc9> ibennetch, this is not part of the meeting
09:40 < ibennetch> Okay
09:40 < ibennetch> Then we're on to the configuration storage naming scheme
09:40 < ibennetch> Some variables are without spaces/underscores, some have underscores.
09:41 < ibennetch> We should standardize moving forward.
09:41 < Marc9> I would prefer underscores
09:41 < zixtor> I would prefer the underscore config names for better readability.
09:41 < ibennetch> note that I'm not proposing changing existing variables, only moving forward.
09:41 < nijel> I also agree with underscores
09:42 < madhuracj> I also prefer having underscores
09:42 < ibennetch> Okay, thanks. I'll find somewhere to document that
09:42 < madhuracj> So I'll change the new config table name
09:42 < ibennetch> Finally about the CTRL-Enter to submit.
09:42 < ibennetch> Thanks madhuracj
09:43 < ibennetch> I think the CTRL-enter thing is very unobtrusive.
09:43 < Marc9> SF seems down right now
09:44 < zixtor> We should note that browser's implicit form submission mechanism (i.e. submit on pressing Enter) doesn't work not only for textarea but for dropdowns as well. So, quite different from console or grid edit, the Insert page is a raw form similar to many other forms across PMA, like db_qbe, tbl_search, tbl_structure, tbl_change (insert page) etc... Where ever we use anything apart from input text field.
09:44 < zixtor> So we may want to make a comprehensive change across PMA if we are dealing with it
09:44 < nijel> I like to have CTRL+enter working ... but preferably in all textareas (being addicted to this behaviour from GitHub)
09:46 < Marc9> While I might not use this often, I can understand why some need keyboard shortcut for any form submission, so I'm in favor
09:46 < zixtor> Also the existing PR also does it on any type of field present in the table tr.
09:46 < Marc9> nijel, would you say that ctrl+enter looks like becoming more popular?
09:47 < ibennetch> So if I'm on a non-textarea, I can use enter or ctrl-enter to submit, right zixtor ?
09:47 < ibennetch> (in the PR)
09:47 < zixtor> Right ibennetch
09:47 < nijel> Marc9: not sure how much, but I've seen it on several websites
09:48 < ibennetch> I think that's great.
09:48 < zixtor> so this may require comprehensive change all across similar forms in PMA
09:48 < Marc9> zixtor, you mean everywhere there is a textarea or drop-down?
09:49 < zixtor> Anywhere we have non input text fields
09:49 < zixtor> because Enter works in input text fields only I think
09:50 < Marc9> Maybe it can be done at the jQuery level, quite high (body) ?
09:50 < ibennetch> I can ask Deven to look in to incorporating that in to his pull request
09:50 < zixtor> yeah we can write it at high level, but handler will be for just the form elements ;)
09:50 < Marc9> ibennetch good idea
09:51 < ibennetch> We have less than ten minutes left in the meeting
09:51 < Marc9> zixtor yes, I just wanted the need to change a lot of scripts
09:51 < Marc9> should we discuss sf-related issues here (now that some publicity has been done) ?
09:52 < ibennetch> Is there some issue to discuss?
09:53 < ibennetch> I don't mind
09:53 < Marc9> tracker moving and mailing lists
09:54 < zixtor> I am well in favor of moving mailing lists to own server maybe
09:54 < ibennetch> I'm working on the mailing lists.
09:55 < ibennetch> That way we can integrate all of our lists -- team@ info@ and devel@ and so on all in one place.
09:55 < ibennetch> Still working on exporting the existing list membership and archives, so it's in progress but slower than I anticipated.
09:55 < Marc9> yes; I have asked Olivier about old team list archive
09:56 < zixtor> nice
09:56 < ibennetch> nijel has been quite helpful through my work as well.
09:56 < Marc9> about trackers, we were discussing about whether to move existing issues or not
09:56 < Marc9> (to github issues)
09:56 < ibennetch> Four minutes in the official meeting; I can stay a bit later myself.
09:57 < nijel> I don't think we can get rid of the backlog quickly and using two trackers at the same time might be confusing....
09:57 < ibennetch> Yeah, this is a difficult issue no matter what. Ideally we would be able to automate moving the issues and leaving a link to the new issue tracker, but I think we weren't sure whether that could be automated.
09:58 < ibennetch> Even if we could clear the backlog, I think we should have historical items around -- closed as "wont-fix" for instance.
09:58 < Marc9> to remove confusion, on github this is called Issue, which is more neutral than bugs or rfe
09:59 < Marc9> I would be able to live with two systems
09:59 < ibennetch> Surely we're not the first to try this. I wonder if github has any suggestions.
10:00 < Marc9> would it be confusing to have in the Changelog, bug #1000 and issue #1000 ?
10:01 < chealer> sorry, back from the fire
10:02 < chealer> Marc9: quite likely :-|
10:02 < madhuracj> I feel it would be less confusing to only have the new issue numbers
10:02 < chealer> I guess there could be a note about it at the top, or URL-s could be used for a while.
10:03 < Marc9> madhuracj please clarify
10:04 < madhuracj> In out website we can point users to the GitHub issue tracker and only use issue numbers
10:04 < Marc9> madhuracj you mean after moving all old issues, right?
10:04 < madhuracj> If someone is refering to the old changelogs we can place a link in SF trackers pointing to the new GitHub tracker
10:04 < madhuracj> Yes
10:05 < nisargjhaveri> I think, it would be better if everything is at one place.
10:05 < Marc9> madhuracj but we did not find a way to automate this linking
10:05 < nisargjhaveri> Also, automation should be possible, at the very least some crawling should work?
10:06 < Marc9> if automation is not possible, I volunteer to do a manual linking, but only for currently open bug and rfe artifacts :)
10:07 < chealer> does GitHub allow bumping the next issue number (to SourceForge's)?
10:07 < Marc9> (that is, if the move script works correctly)
10:07 -!- gigo1980_ [~gigo1980@pD954D713.dip0.t-ipconnect.de] has joined #phpmyadmin
10:07 < nijel> automation should be possible, but would require some scripting - there is SF.net API to add comments
10:09 < Marc9> is the goal to move all artifacts, or just open ones?
10:11 < ibennetch> I have doubts about whether we'll be able to also migrate comments, and if we update all of the sf tracker items with the new URL that will be a lot of email notifications. I'm uncertain of what I think the best path should be.
10:11 < nijel> I'd move all if possible (to have everything in one place)
10:11 < ibennetch> I agree that moving everything is ideal.
10:12 -!- gigo1980_ [~gigo1980@pD954D713.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
10:13 < nisargjhaveri> I can probably help with automating whatever is possible.
10:13 < Marc9> nisargjhaveri what would be your time frame?
10:14 -!- Dragooon [~shitizgar@simplemachines/customizer/Dragooon] has joined #phpmyadmin
10:14 < ibennetch> I do suggest first asking Github if they have any tools to make this easier, but at the same time realize that's rather unlikely.
10:14 < Marc9> ibennetch I had forgotten about the email notifications
10:15 < nisargjhaveri> Marc9, Not sure. If someone else is willing, please do it. :)
10:15 < Marc9> nijel, do you believe it's possible to test the moving script, to a dummy repo ?
10:15 < nijel> I've just found this: https://github.com/cmungall/gosf2github, which also allows mapping usernames
10:16 -!- SPF|Cloud [uid11755@wikipedia/Southparkfan] has joined #phpmyadmin
10:16 < Marc9> I would like to see what happens when we move two different trackers (bug, rfe) to one issue system
10:16 < nijel> Marc9: we should definitely test it on separate repo (preferably in someones home, so it does not look official)
10:18 < Marc9> Note that the API does not grant permission to create the tickets as
10:18 < Marc9> if they were created by the original user, so if your token was
10:18 < Marc9> generated from your account, it will look like you submitted the
10:18 < Marc9> ticket and comments.
10:18 < Marc9> this is for gosf2github
10:20 < Marc9> labels look fine :) https://github.com/nijel/weblate/issues
10:20 < nijel> yes, the tickets and comments would be created by the bot, the (mapped) user is mentioned in comment text
10:20 < chealer> hehe, "newbie"
10:21 < Marc9> nijel I see
10:21 < Marc9> nijel do you want to test this newly found script?
10:22 < Marc9> Also, would we keep the old tickets in place, so that the links in older changelogs still work?
10:22 < chealer> of course, if open issues are not moved, there's a higher risk of getting duplicates (unless a warning to users can be displayed)
10:24 < Marc9> chealer we will close submission for new tickets on sf
10:25 < nijel> Marc9: I can test the script and see how it works
10:25 < chealer> Marc9: yes. I mean if I go search for an issue I am experiencing on GitHub and don't find it, I may report it even if it exists on SF. so I waste my time, and developers too.
10:25 < Marc9> nijel good; it looks more promising than the other script
10:26 -!- Dragooon [~shitizgar@simplemachines/customizer/Dragooon] has quit [Quit: My Mac has gone to sleep. ZZZzzz...]
10:26 < nijel> it would be great if somebody could look into option to add comments to sf.net trackers
10:26 < Marc9> chealer true but we already have this problem; the real problem is our backlog
10:27 < Marc9> nijel, even if this generates tons of email notifications?
10:29 < madhuracj> Only the developers will get tons of emails, right? Others will only get emails for their issues.
10:30 < nisargjhaveri> We can tell people to unsubscribe for a while? :P
10:30 < nisargjhaveri> Or if we migrate mailing lists also, can we filter it after that?
10:30 < Marc9> madhuracj I'm not sure how the tracker mailing lists work
10:31 -!- zixtor [31f9bc5e@gateway/web/freenode/ip.49.249.188.94] has quit [Ping timeout: 246 seconds]
10:32 < Marc9> I have to leave soon
10:32 < ibennetch> Users can subscribe to the entire mailing list for each of the trackers. How many people did so I have no idea.
10:32 < ibennetch> Whether project administrator can see that through SourceForge I don't know.
10:32 < ibennetch> (can see the list of users, I mean)
10:32 < ibennetch> Otherwise, people only get notifications of their issues)
10:33 < Marc9> 34 subscribers to the bugs tracker list
10:33 < Marc9> 14 for the rfe tracker list
10:34 < Marc9> bye all
10:34 -!- zixtor [31f9bdd3@gateway/web/freenode/ip.49.249.189.211] has joined #phpmyadmin
10:34 -!- Marc9 [~marc@96.127.226.40] has quit [Quit: Leaving]
10:34 < ibennetch> By Marc9 Thanks for the info
10:34 -!- nisargjhaveri is now known as nisargjh|cloud
10:34 < zixtor> Bye all
10:34 -!- madhuracj [~kvirc@123.231.124.214] has quit [Quit: KVIrc 4.2.0 Equilibrium https://www.kvirc.net/]
10:35 -!- zixtor [31f9bdd3@gateway/web/freenode/ip.49.249.189.211] has left #phpmyadmin []
10:36 -!- nisargjh|cloud is now known as nisargjhaveri
10:37 -!- nisargjhaveri is now known as nisargjh|cloud
10:38 < chealer> bye
10:39 < ibennetch> by chealer thanks for attending
10:39 -!- chealer [~pcloutier@pdpc/supporter/student/chealer] has left #phpmyadmin []
10:43 < ibennetch> Thanks to all for attending